I want to take a string, say 'TSomeClass', and convert that into something
that can be used by RegisterClasses. The idea is to put all the registered
classes into a database so I don't have to recompile everytime I add a new
bpl to the project. This concept of dynamically registering classes is
critical to my project's success.
Code might look like this:
procedure RegisterClassFromString(const AClassName: string)
begin
RegisterClass(DoSomethingCoolHereToHelpMe(AClassName));
end;
I feel like I'm pulling myself up by my boot straps. ug.
Any help is *greatly* appreciated.
Mark
RegisterClass(GetClass(AClassName));
________
Andreas
Delphi 5.01 Pro, Win2K Sp2
If I could use GetClass() or FindClass() then the class would already be
registered and I wouldn't be in this odd situation.
Why not have each bpl register the classes it houses as it is loaded?
I usually put the registration of a class that needs to be found by name in
the initialization section of the unit that implements the class. That way I
know the class is registered when the unit is loaded and that saves a heck
of lot of hassle. And... you won't forget to update the database... <g>
Marjan
_________________________
Marjan Venema - BJM Software
in...@bjmsoftware.com
http://www.bjmsoftware.com
I want to use common UI elements. Like TButton and TEdit, etc.
> And... you won't forget to update the database... <g>
It seems a strange thing indeed to me to store data in code instead of in
the /data/base where it belongs. <g>
How could I forget to "update" the database? The idea is that updating the
database is what effects changes in the appearance of the form. I don't
want to update the code every time the data changes. That's insane.
If I understand well what you say, the actual form description is stored in
a database and that's why you need to register every possible classes used
in the application, right?
A while ago, Ludovic Dubois published a piece a code hacking the EXE file to
register every classes used in a Delphi application. It quite old but I kind
of remember succesfully testing it a few months ago.
I think it's a big hack and not the proper way to do things but if you're
interested, go to www.tamaracka.com and search for "ludovic dubois classes
hack".
HTH
Charles
You are close to understanding what I want.
Think of what I'm trying to do as an XML Delphi form browser. Instead of
creating HTML pages, I want to create a Delphi page. I want an engine to
get an XML form definition and create the form on the fly.
By the way... did you sign my NDA? <grin>
You hit it in one <g>.
>
> I want to take a string, say 'TSomeClass', and convert that into something
> that can be used by RegisterClasses.
Sit back a moment and switch on the ol' brain <g>. What is RegisterClass used
for? To register classes so you can later use FindClass to find a class
reference given a class name. The method puts the classes you hand it into an
internal list, which FindClass then uses for a simple lookup operation. You
must have such a list, which contains class references, otherwise you have
the chance of a snowball on the sunny side of Mercury for finding a class if
you only have the class name in a string. So you simply cannot start out with
*only* the string.
--
Peter Below (TeamB) 10011...@compuserve.com)
No e-mail responses, please, unless explicitly requested!
Use the newsgroup archives :
http://www.mers.com/searchsite.html
http://www.tamaracka.com/search.htm
http://groups.google.com
http://www.prolix.be
I figured. It seemed like I was stuck in a logic loop. I started asking
people 'round here which came first, the chicken or the egg in hopes of some
philosophical insight into my problem. <g>
So look, I just want to find all the classes that can be used in the UI.
Maybe there's a way to iterate through the classes in a unit? Something that
would look like this (only more complex I assume)
for i := 0 to MyUnit.ClassList.Count - 1 do
RegisterClass(MyUnit.ClassList[i].Class);
What about doing something like StringToComponent does in the help file?
Here's the simple version of what I'm trying to do:
I want to send an a text version of a form (XML) to a client app and have it
create components and stick them on the form. I figured TButton would
already be registered, but it doesn't seem to be. I don't want to have to
register every darn control available to a Delphi UI developer. That's
nuts. <g>
> Sit back a moment and switch on the ol' brain <g>.
That's way too much to expect from me this late in the day. <g>
Then you will need to register every needed class to create such a form. I
already had that problem and I'm not aware of any "miracle" solution. I
tried a few approaches:
1. Register all classes at once. It's not that big a deal, I used code like
this one:
type
TClassArray = array [1..108] of TPersistentClass;
const
ClassArray: TClassArray = (
TApplication, TDDEServerItem, TPanel, TAutoIncField,
TDirectoryListBox, TPopupMenu, TBatchMove, TDrawGrid,
....
TUpdateSQL, TDDEClientItem, TPageControl, TUpDown,
TDDEServerConv, TPaintBox, TVarBytesField, TWordField, TwwDbGrid);
....
initialization
begin
RegisterClasses (Slice (ClassArray, High (ClassArray)));
end;
Of course, this unit must have all needed units in its uses clause
2. Put every needed component of a dummy form. At run-time, create the dummy
form and iterate over its components to register the classes.
3. At run-time, load Delphi's design-time packages so they register all the
components they contain. I did it once as an experiment, that's a pretty
crazy approach and besides, there's no way you can distribute these packages
with your application.
4. Take a look at the suggestion in my previous post
HTH
Charles
By the way, I like this approach its a pretty good idea.
Do you think there's a way to iterate all the classes in a unit? Seems like
there must be a way.
<SNIP>
Last time I went through this I had to do all of what you have said. I was
hoping there was a better way. It seems unnatural to look at code from 1
year ago and say "Yup, that's the best way to do it." Makes me feel like I
didn't learn anything new.
I guess I just hit the technology ceiling. I figured if any development
system could pull off the impossible it would be Delphi. Oh well.<grin>
> Do you think there's a way to iterate all the classes in a unit? Seems
like
> there must be a way.
A unit is a programmer/compiler concept, once compiled/linked, there is
nothing that delimits/encloses/enumerates the classes/procedures/etc that
were grouped together as a unit, why would there be? (from a Delphi
designers point of view). I see no reason to keep a group relationship for,
say, TButton, TLabel, TScrollbar, etc that are all defined in StdCtrls.
If you wonder how Delphi can build its forms from the EXE resources if no
classes are available through FindClass/GetClass, the answer is that each
FormClass has a list of the TClass that are used on this particular form
(the list is available through the VMT). Delphi doesn't need FindClass to
build the forms because the class reference of a form is always directly
available (and so are the form's components class references). At design
time, OTOH, the design-time packages will register every components they
contain to the Delphi IDE so, inside the IDE, every component is available
using FindClass/GetClass.
Charles
Nope. Your only way out is to register all classes you want to use, period.
> I want to send an a text version of a form (XML) to a client app and have it
> create components and stick them on the form.
What for? A form is pretty useless without the associated code, you know. For
just showing you could get this to work if you standardise on a fixed set of
control classes and register those in the client app.
Right, I could just use a big case statement to create controls "manually".
I guess I'll just break down and decide which controls I like, register
them, and drive on.
Thanks for you assistance.
Cheers,
Mark
I don't put code in the forms.. well, one line of code per event - a direct
call to a business object's method. Besides, if I really needed to code on
the form, there are script engines available.
> For just showing you could get this to work if you standardise on a fixed
set of
> control classes and register those in the client app.
Yes, I see I will have to do this. I'm thinking I can create a BPL with the
registration code, then have the application check for BPL updates... I mean
how big can a BPL with nothing but 1 unit of registration code be? Should
be a trivial download.
Thanks for your A. Help, B. Sanity check. <g>
Cheers
Mark