Board index » delphi » Re: TCustomForm and TDataModule using in multithreaded environments

2006-12-07 04:16:26 AM
delphi34
Aleksander,
ok I don't understand. Designtime is intended fror use inside IDE. Runtime
are libs and classes for compiled (redistributable) binaries. Designtime are
design time objects, e.g. DesignWindow (canvas for designime), wizzards,
component and proeprty editors. These objects are useless for runtime, and
terefore are collected together and marked as designtime packages. Runtime
packages are collection of classes (procedures, functions, variables, etc.)
that are used by a running application. Corelaton between designtime and
runtime is established via IDE (OTA) registration procedures. There is a
no-brainer that TWinControl descendants have "TVisualDesignerWindow"
designer and TComponent descendants have "TNonVisualDesignerWindow"
designer. Main difference between these designers is that one can hold
visual representation of owned objects and the other one can hold only
24x24px icon representation of owned objects (behind the scenes, there is a
difference of component containter object inside designer, but this is a
different story anyway, and works perfectly inside D5-D7).
Correct me if I am wrong.
What you are telling me is that I can use a TVisualDesignerWindow designer
for a TComponent descendants. I tried to do that, but finally gave up with
no success. Then I checked 2 different frameworks of a similar type, DevEx
WebFramework and Intraweb. The first one did the same as I did. Descend from
TComponent and implement own esigner from scratch. The second one used
TVisualDesignerWindow (as you stated "bad design") and made not so optimal
but still a working solution (I checked this using TIWForm and class
function "ClassParent").
There is also a third option to use a "precompiler" which would change
source code with "ifdefs" (like compactframework RAD for 2006).
Can you explain more detailed what you are thinking about separating
designtime/runtime? Did you mean something that is allready mentioned
before?
Regards,
Frenk
 

and save their data to some file you can then load into TObject based objects
at run-time.
Again, that is exactly what Delphi/BDS does...
At design-time, it uses a TNonVisualDesignerWindow and saves its content to
a .DFM file. Then, at runtime, this content gets loaded by a TDataModule
(via linked .RES file), which is a completely *different* object. It has no
knowledge of visual representation (unlike TNonVisualDesignerWindow, which
knows how to paint itself on screen), nor should it have one, because it is not
intended to be visible. Much like your own run-time classes.
risk of repeating myself. Sorry.
Regards,
Aleksander Oven
 

forgot to mention. "TVisualDesignerWindow" can only be used for TWinControl
descendants and "TNonDesignerWindow" for any other TObject descendants (even
TWinControl if you like). The problem is that I need a TVisualDesignerWindow
for TObject descendants. And at this ugly detail, all delphi forums become
silent... (If you will search google, you will even see Intraweb author
questions about this detail and I somehow understand him why it chose "bad"
design.)
I just had a question if someone has any better idea how to make limited
TWinControl descendant (removing messaging/painting stuff, via overriding
virtual methods, overrideing constructors and so on if this even make some
sense) for the sake of luxury of IDE RAD using TVisualDesignerWindow.
Regards,
Frenk
 

designer needs to use the very same classes that your ISAPI will instantiate.
But it really doesn't have to!
For all you know and care, Delphi's own form designer could be using TImages
to represent all the components on the design surface and you wouldn't even
know it. Or it could be simply painting them directly on its canvas.
Where does it say the rectangles you see on a form designer in IDE need to be
the actual TLabels and TEdits and so on? Nowhere.
Sure, in the case of a form designer they really are, but that is only because with
forms, design-time and run-time are practically the same - both appear on the
user's desktop, so it only makes sense to reuse the same objects in both
environments (design-time and run-time).
But all this doesn't apply to your case - your run-time is very much different
from the design-time. Your designer can freely make use of TLabels and TEdits
and whatnot, but their run-time counterparts should be non-visual, because they
will be used in a non-visual environment.
Short of writing you some code, I fail to see how else I could explain all this.
Unfortunatelly, that is completely out of the question.
Anyway, do as you want. I have already written so much to no effect, I feel like
I'm seriously wasting my time here.
Regards,
Aleksander Oven
 

people. You are talking about a theoretical aspect, I am talking about an
implementation. As I said I allready did a visual representation of
TComponent as TVisualDesignWindow/TLabelComponent via implementing a custom
designer from scratch. And this works almost like a charm for D5-D7. But
because IDE changes all the time (BDS has now tags for code/designer +
changes in OTA again and again + no documentation +
"nodbody_knows_what_a_future_will_bring"), you have 2 options, (1) to use
"bad" design and avoid problems with IDE or (2) to have a good design and
you are deadly thinkinkg WTF are changed again and again. I did never said
it can not be done, but the question of the first post was, what is the
easiest (optimum) path to accomplish the requested task.
So if I return to the original question, how big is an overhead of using
TWinControl (bad design) descendant vs. TComponent descendant (good design)?
(I will ask this question in rtl.Win32).
Regards,
Frenk