Beiträge von mmount

Thanks - I will have a look asap.

Mike

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

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

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

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

Well, I gave up on getting an answer and bought the source code. Oddly, now that I have the source (same version supposedly) setting the LineWidth to zero suppresses the line drawing (as I would have expected before).

Ugh.

Mike

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

Hi,

How do I stop the line between each report area from printing?

Thanks,

Mike