Form Completion Mode

  • Hello,

    I am considering using WPForm for form completion within an application I have developed. Unfortunately, the current implementation is far too inefficient to be functional in my situation. I am wondering if it is possible to design custom graphic objects which can override the default behavior in Form Completion Mode.

    These objects would have to present a custom editor in Form Completion Mode that could:

    1. Process key strokes while the editor was displayed
    2. Programatically move to the next form object
    3. Programatically access other objects on the form to enable/disable them or chack their values for exceptions

    For example one object that I would need to implement would be a RadioGroup. Depending on which item in the group was selected I would enable and disable relevant objects to ensure consistent data was entered. I also may need to set an error condition if mutually exclusive options were checked.

    Is any of this possible with WPForm?

    Thanks,

    Mike

  • Good luck getting an answer from the developer.

    All the things you want can be done as-is.

    Item 1> there are OnKeyPress, OnKeyDown, and OnKeyUp events for the inplace editors (the editor that appears for each field that allows the entry of data).

    Item 2> Can be tabbed through OR set focus to a particular field

    Item 3> You can easily enable, disable, or even change the properties based on certain criteria DURING form cmpletion. If you aren't even sure what that riteria will be, you can even use scripts to handle things.

    My application is one that allows the user to "build" a set of forms from individual form templates. Each report could be 1 page or several thousand. They might even have duplicates of the same form with different information. What I did was use the "formula" field (which really doesn't work for formulas) and use this to place the name of a script to execute. When focus leaves that field, it executes the script, and that script can do anything from perform functions on fields to make the visible or change their appearance.

    While WPForms is excellent, getting answers is something you pretty much have to figure out on your own.

    There is only one thing keeping me from completing my application and it may make the difference between me using WPForms or starting from scratch because I can't get help on doing it through the developer.

    JD

  • Thanks JD.

    I am seeing that support (at least via the forums) is dismal at best. Seems like this is a nice foundation of a product though. I gave in and bought the source code so I will delve into that this weekend to extend the product in a more usable direction for me. If you are interested in giving me a hand I'd be happy to share improvements/modifications.

    Again, thanks!

    Mike

  • Zitat von mmount

    Thanks JD.

    I am seeing that support (at least via the forums) is dismal at best. Seems like this is a nice foundation of a product though. I gave in and bought the source code so I will delve into that this weekend to extend the product in a more usable direction for me. If you are interested in giving me a hand I'd be happy to share improvements/modifications.

    Again, thanks!

    Mike

    No Problem, Mike.

    I did find some bugs and fixed them. They aren't a problem unless your application also allows users to insert photographs. And I can help you with using real formulas (not the formula field) when you get to that part.

    You see, it would be real easy to simply use regular windows forms (text boxes, labels, etc.) since you can allow users to dynamiclly create these, as well. But, in my case, the typical single-page form has more than 300 fields and aboth the same number of labels. WPForms helps with the scaling of this tremendously when people zoom. Otherwise, I'd just create forms like any other regular application and simply "print" the form to a printer device context. My forms progrm is for real estate appraisers. They select different government forms, photo adenda, etc, and assemble them into a report. The user might have a single page report or a thousand pages. What I do is insert pages everytime the user adds a form from a library of forms, and store the names of the individual forms into a listbox (which is saved with the report). They can navigate through the report by clicking on a page in the listbox, so they can easiy jump from page 1 to page 14 and KNOW what page 14 is (like 14 may be the Comparable Rent Schedule Analysis).

    If your application doesn't have but a few fields per form, you can also do it with standard windows controls. It's not that hard to make a program that can add controls and move controls at runtime for users. he problem comes into play when they are very close to one-another, there are a whole bunch of them, and you need to print the form.

    Anyway, I'll be glad to help. I bought the source for WPForm, too, but not for WPTools. I think I need to buy the source for WPTools so I can get the TWPCustomRichText to work properly. Seems to me it needs a little tweaking. I'm not a programmer, but I'm pretty good at figuring things out.

    JD

  • JD,

    Sounds like an interesting project. Personally, I am not interested in allowing users to modify the forms. I am just looking to be able to quickly and easily add them to the application and have them loadable and fillable by the end user. I have started a design tool that fixes alot of the problems that the "Form Wizard" created interface has. It makes it much easier and more intuitive to create a form.

    I mostly waded through source code this weekend and, unfortunately, am thinking a rewrite is needed to clean it up so it can be effectively extended. I also tried my hand at creating a new object but have thus far had no luck getting the additional properties to show up in the object inspector. The help file is apparently missing some things but my trial and error has not found the answer. I suppose I will have to wade through the inspector code to find out what it is. The object inspector can probably be the first thing to get thrown out and started over. What an unwieldy and cumbersome component that is.

    Please drop me an email when you get time: mike AT dreamndigital DOT com and we can discuss this more.

    Thanks for all your assistance,

    Mike

    • Offizieller Beitrag

    Hi,

    Currently WPForm is a bit on hold since the syncronisation with WPTools 5 has not been completed. WPTools 5 would allow nice new possibilities, such as text paths. But that makes it very difficult to implement. But it making progress - actually it is the next 'on the list' since WPReporter has its 100% status in WPTools R5.13.

    >>I mostly waded through source code this weekend and, unfortunately, am thinking a rewrite is needed to clean it up so it can be effectively extended. I also tried my hand at creating a new object but have thus far had no luck getting the additional properties to show up in the object inspector. The help file is apparently missing some things but my trial and error has not found the answer. I suppose I will have to wade through the inspector code to find out what it is. The object inspector can probably be the first thing to get thrown out and started over. What an unwieldy and cumbersome component that is. <<

    The inspector should connect itself to properties which are initialised in wpgrprops. The design of WPForm 2 was created to make the thing scriptable, this means all properties can also be addressed by name.

    But from the file format you can see that its origin is still from a time wher file sizes matters, an XML approach such as in WPTools 5 would make things easier.

    Just mail me what properties you need.

    Julian

  • Zitat


    The inspector should connect itself to properties which are initialised in wpgrprops. The design of WPForm 2 was created to make the thing scriptable, this means all properties can also be addressed by name.

    But from the file format you can see that its origin is still from a time wher file sizes matters, an XML approach such as in WPTools 5 would make things easier.

    I guess I see what you're doing and I see now why the Dream Inspector doesn't work with any of the WPForm objects - no RTTI. I went through quickly last night and published some of the properties to verify that RTTI would work. I like the Dream Inspector interface much more than the WP Inspector so I will probably add a compiler directive that allows all the objects to have published sections if I want. I don't care about compatibility with WPForm1 or the minor amount of extra overhead with RTTI on.

    The other thing top on my list is changing your object hierarchy. I'm certain that I don't see the logic of it. I found that I cannot create a custom object which extends on the features of an existing object with the exception of the TwpfgGraphic - the one object I don't really need to extend. The problem is that the TwpfCustomGraphicObject derives from it as do all other objects. Consequently, if I inherit from TwpfgGraphicText I can not register the new object because it doesn't come from the proper class. Personally, I think the TwpfgGraphic class should be the TwpfCustomGraphicObject class and all objects should inherit from it. This would have allowed me to extend existing classes and use them without buying the source code and recompiling. Additionally it would have allowed me to continue upgrading the WPForm components as you released new versions whereas now I will essentially kill the possibility of all further upgrades because I have to make so many original source code changes that would have to be integrated for every update.

    Anyway, if you are interested in seeing my changes as I make them I would be happy to share them with you and you would be welcome to integrate them into your final product if you wished to. I think WPForm could be one of those "can't live without" component sets if it were implemented a little bit differently and extended in all the right directions. That is my intention with the changes I will be making - if I can get it all cleaned up I am sure this code will end up living in almost every application I write.

    Thanks,

    Mike

    • Offizieller Beitrag

    Hi,

    thanks for the comments.

    About the properties: I am not using RTTI because I wanted a possibility to a) localize property names b) hide properties c) access properties fault tolerant (problem with floating point numbers in other controls)

    WPForm is designed to work more like a graphic program than a design IDE. The object inspector was added much later, later than the the concept of the toolbar. In WPForm you can select a current text and graphic state and start drawing. This maks it different to all products which depend on an object inspector and is another reason for the unusal concept.

    About the inheritance: The idea is that all objects are at least rectangles. This is why the TwpfgGraphic has all the features. Inheriting from shoukld not be problematic since you can stilll override DrawIt which is the key. I am not sure what changes you need to make to modify its original behavior. Note that the TwpfgGraphicText inherits from TwpfgGraphic, too.

    I know that this is a bit unsual object architecture but it makes it eays to quickly change an objects type, a rectangle can be a circle, too and, you can assign the properties of a rectangle to circle and text objects, for example background color.

    One object which is really problematic is the table. I am not sure what to do with it.

    Of course I would like to see the changes. Please send to "support at wptools de"

    Julian

  • Julian,

    I understand that you're not using RTTI in the Object Inspector. However, I would think that it would be no big deal to go ahead and publish certain properties so that a user could opt to use another RTTI based object inspector instead if they did not need localization or to hide certain properties. That was where I was going with it.

    I think you missed my point on the inheritance comment. The problem is that to create a custom control I have to inherit from TwpfCustomGraphicObject. This inherits from TwpfgGraphic. I need to just override the Draw behavior of the TwpfgGraphicText class but keep all the InplaceEditor stuff. However, because TwpfgGraphicText does not inherit from TwpfCustomGraphic I can't - instead I would have to copy all the code for it into a new class that did (or rewrite the code from scratch). Now this seems stupid to me because the TwpfCustomGraphicObject doesn't add or subtract anything from TwpfgGraphic. It just forces me to start every custom object from the extreme low level TwpfgGraphic class. My intent was to essentially rename the TwpfgGraphic class to TwpfCustomGraphicObject so all the functionality of TwpfgGraphic would be declared there instead. Then TwpfGraphic would inherit from that class (and add or subtract nothing) and all the other classes on down the line could either stay where they were or be changed to inherit from TwpfCustomGraphicObject. No functionality would change except now I could inherit a custom object from ANY derived class and not have to write each one I wanted to behave slightly differently from scratch.

    All that said - my looking further into this has been put on hold for a few weeks pending a few project beta releases. As soon as I can get back into it I will send you s'more thoughts :)

    Thanks,

    Mike

    • Offizieller Beitrag

    In the new WPForm Version 2.50 (PRO version available, STD version a.s.a.p) custom object can be derived from the TWPFGraphicText. It is also possible to use the IP procedures to use the standard text editor to edit a property: