AlexDen
asked on
Polymorphic TCollection or ?
I'm looking for some info and/or source on class and property editor for something like TCollection, but with an ability to accept different classes and with a full design-time support. Unfortunately, in design-time, TCollection and it's editor may operate with only one class type (ItemClass property).
Something similar to my target can be found in GLScene unit by Mike Lischke, where one can add different classes in design-time, but the code is a bit buggy and I can not find enough info to remove those bugs, or create my own editor.
Even Delphi's source code (colnedit.pas) refers to some strange TToolbarDesignWindow class which I can not find in Delphi destribution.
I would really appreciate any help with some good advice or source code sample.
Something similar to my target can be found in GLScene unit by Mike Lischke, where one can add different classes in design-time, but the code is a bit buggy and I can not find enough info to remove those bugs, or create my own editor.
Even Delphi's source code (colnedit.pas) refers to some strange TToolbarDesignWindow class which I can not find in Delphi destribution.
I would really appreciate any help with some good advice or source code sample.
Listening
hehe the code is a bit buggy..maybe mike will be along to have a look .
What, where, how...? Nothing is buggy. My code is always totally bug free ;-))
But seriously, we need to clarify some things before I can propose a solution. If you only have a TCollection class with self defined item classes then you don't need an own property editor as the one in Delphi handles this case automatically. The editor isn't the coolest one but it does its job.
Ciao, Mike
But seriously, we need to clarify some things before I can propose a solution. If you only have a TCollection class with self defined item classes then you don't need an own property editor as the one in Delphi handles this case automatically. The editor isn't the coolest one but it does its job.
Ciao, Mike
ASKER
Here is what I mean:
Suppose you define
TMyObject form TCollectionItem,
TMyObjects from TCollection,
and some contol with Objects: TMyObjects property.
In constructor of TMyObjects, I assign TMyObject to its ItemClass property.
After that, I can add TMyObject objects in design time just by hitting "Add new" button in default TCollection property editor.
After that, suppose I derive a new type TMyObject2 = class(TMyObject);
In runtime, I would add TMyObject2 objects using the Items property (TMyObjects.Add or TMyObjects.Insert functions seem not suitable since they may only return TMyObject classes).
But what should I do in design time? The GLScene by Mike Lischke looks just fine except a few bugs (they are really very small, Mike but I can not find them... yet... still trying). Its tree-like structure is even better than the simple list used in TCollection.
Suppose you define
TMyObject form TCollectionItem,
TMyObjects from TCollection,
and some contol with Objects: TMyObjects property.
In constructor of TMyObjects, I assign TMyObject to its ItemClass property.
After that, I can add TMyObject objects in design time just by hitting "Add new" button in default TCollection property editor.
After that, suppose I derive a new type TMyObject2 = class(TMyObject);
In runtime, I would add TMyObject2 objects using the Items property (TMyObjects.Add or TMyObjects.Insert functions seem not suitable since they may only return TMyObject classes).
But what should I do in design time? The GLScene by Mike Lischke looks just fine except a few bugs (they are really very small, Mike but I can not find them... yet... still trying). Its tree-like structure is even better than the simple list used in TCollection.
Alex, you should be aware that the scene editor is totally selfmade and relies of course on the structure build the scene objects. This has nothing to do with collections and will never work with them because you would need a parent-child relationship between items. This is not the intention for collections so you will always only be able to manage a dynamic list of items.
For your TMyObject2 I can tell you that you don't have to worry about what is returned. We are talking here about polymorphism which means the class returned by the Add function can safely be casted to your own class (to be safe use the "as" operator).
Ciao, Mike
For your TMyObject2 I can tell you that you don't have to worry about what is returned. We are talking here about polymorphism which means the class returned by the Add function can safely be casted to your own class (to be safe use the "as" operator).
Ciao, Mike
Listening...
comment: Have you ever looked at the Delhpi Streaming for TCollections? - Good Luck / Look !!!
aacrg. #;c)
comment: Have you ever looked at the Delhpi Streaming for TCollections? - Good Luck / Look !!!
aacrg. #;c)
ASKER
Mike, actually I am not very much interested in TCollection itself. I'm interested only in property editor for such things. And I'm OK with that kind of parent-child stuff. And I took that collection stuff only as an example (well, maybe not the best).
As to your last comment, of course I agree, but I need that kind of polymorphism in design time. In that example I can only get access to TMyObject properties.
It means that in my dreams, I would like to have a property editor with several buttons for adding different classes (or as you did it with popup menus). My case is even simplier since I will have a fixed set of classes to add, so I do not need something like Object Inspector in your case.
And Mike, in order to clerify my intensions, I am rewriting my own OpenGL components which are somehow similar to your GLScene, but with rendering in a separate thread, and without any Euler angles (quaternions only).
As to your last comment, of course I agree, but I need that kind of polymorphism in design time. In that example I can only get access to TMyObject properties.
It means that in my dreams, I would like to have a property editor with several buttons for adding different classes (or as you did it with popup menus). My case is even simplier since I will have a fixed set of classes to add, so I do not need something like Object Inspector in your case.
And Mike, in order to clerify my intensions, I am rewriting my own OpenGL components which are somehow similar to your GLScene, but with rendering in a separate thread, and without any Euler angles (quaternions only).
ASKER
Adjusted points to 85
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Ok, Mike,
I had some time this weekend and I think I understood how all that stuff works. But here are your points anyway... just for some good piece of work.
Regarding quaternions... they are essentially necessary for rotation interpolation... which is in turn necessary for smooth motion and more or less consistent physics modelling (I do not mean some serious physics here, just inertia, etc.). As for their understanding, I use QuaternionToRotation and RotationToQuaternion conversions so that quaternions are interfaced through rotation vectors. I think the same was done in Caligari TrueSpace and it looks pretty much convenient.
.... and in your code ...
unit GLSceneEdit;
TGLSceneEditorForm.TreeDra
Assigned(DropTarget.Data)
I think, should be changed to
Assigned(Target.Data)
Some other bugs do exist but they are not so essential.
I had some time this weekend and I think I understood how all that stuff works. But here are your points anyway... just for some good piece of work.
Regarding quaternions... they are essentially necessary for rotation interpolation... which is in turn necessary for smooth motion and more or less consistent physics modelling (I do not mean some serious physics here, just inertia, etc.). As for their understanding, I use QuaternionToRotation and RotationToQuaternion conversions so that quaternions are interfaced through rotation vectors. I think the same was done in Caligari TrueSpace and it looks pretty much convenient.
.... and in your code ...
unit GLSceneEdit;
TGLSceneEditorForm.TreeDra
Assigned(DropTarget.Data)
I think, should be changed to
Assigned(Target.Data)
Some other bugs do exist but they are not so essential.
Thank you Alex,
yes there are still quite a few bugs but for now I have frozen the development because I'm now in the compiler builder business.
Ciao, Mike
yes there are still quite a few bugs but for now I have frozen the development because I'm now in the compiler builder business.
Ciao, Mike