Dynamically created Datamodule(s)
Blake Courtney
Hello all,
In my application's mainform it has some menu items/buttons
to create SDI forms that are not auto-created. Each of the SDI forms
have an associated base form and datamodule that is also created on the fly.
I'm having a problem, in that if I launch two instances of the
'same' form and datamodule when trying to destroy the second instance,
I get an AV. It seems that cleanup on the Form instance is working
ok, however the datamodule portion doesn't want to free correctly
is there a way to create a *unique* instance of a datamodule
dynamically? It seems that TForm aloows for this, but the associated
datamodule does not.
TIA,
--
Blake Courtney
bl...@ogdencheck.net
George Mealer
I don't think it's the datamodules per se that do this, Blake, but rather the
form linking...like having dmDataModule.DataSource as the Datasource property
of your DBEdit on frmFoo. From what messing around I've been able to do,
Delphi resolves this at runtime by linking it with the first instance it can
find, which makes having multiple instances of a particular DataModule a
rather bleak prospect. I also seem to recall even more spurious behavior than
THAT if you broke a link by freeing the DataModule...like it never relinking
during that application run again, even after freeing and recreating both the
data module and associated form.
I think the moral of that whole experiment was that DataModules are really
meant to be one instance, life of program sorts of things.
Your particular application may be better suited for having the data access
objects directly on the SDI form where they're used.
Geo
--
George Mealer geo...@cambria.com
Programmer/Systems Analyst Office: (650) 328-9270
Cambria Corporation Fax: (650) 328-8642
"A good programmer is someone who looks both ways before
crossing a one-way street." -- Doug Linder
Blake Courtney
George Mealer wrote:
> I don't think it's the datamodules per se that do this, Blake, but rather the
> form linking...like having dmDataModule.DataSource as the Datasource property
> of your DBEdit on frmFoo. From what messing around I've been able to do,
I think I follow you here.
> Delphi resolves this at runtime by linking it with the first instance it can
> find, which makes having multiple instances of a particular DataModule a
> rather bleak prospect. I also seem to recall even more spurious behavior than
> THAT if you broke a link by freeing the DataModule...like it never relinking
> during that application run again, even after freeing and recreating both the
> data module and associated form.
>
> I think the moral of that whole experiment was that DataModules are really
> meant to be one instance, life of program sorts of things.
>
> Your particular application may be better suited for having the data access
> objects directly on the SDI form where they're used.
>
> Geo
George,
Thank you for taking the time to explain this. However what good
is a datamodule? -- and yes I'm being serious. If I'm to regress
simply to 'dumping' database components right back on the form,
how can I exploit inheritance if I can only have one particular
instance at a time? I really _like_ the idea of seperating my GUI
code from my database code, I think it 'clutters' the form code.
OOP? - what happened to keeping everything in one tight spot Delphi?
Please excuse this rant but I really think this is a silly thing,
and from the sound of it maybe you think so too? Why on earth
can a datamodule be anything but auto-create if that's really
all you can do with it?
--
Blake Courtney
bl...@ogdencheck.net
George Mealer
In article <34B9B3CD...@ogdencheck.net>, Blake Courtney <bl...@ogdencheck.net> wrote:
>
>George,
>
>Thank you for taking the time to explain this. However what good
>is a datamodule? -- and yes I'm being serious. If I'm to regress
>simply to 'dumping' database components right back on the form,
>how can I exploit inheritance if I can only have one particular
>instance at a time? I really _like_ the idea of seperating my GUI
>code from my database code, I think it 'clutters' the form code.
>OOP? - what happened to keeping everything in one tight spot Delphi?
>Please excuse this rant but I really think this is a silly thing,
>and from the sound of it maybe you think so too? Why on earth
>can a datamodule be anything but auto-create if that's really
>all you can do with it?
You ask good questions, for which I have few answers. <g> I've never been
big on Datamodules myself, since I end up having to clutter the datamodule
code with "if Screen.ActiveForm is this, do this, otherwise do that, blah" and
I end up having to play with the indexes and field properties, etc. I think
they're a godsend if you have an application that does use one relatively
static database object structure, but if your different forms have different
needs, I prefer to put the objects there. I'm pretty good at keeping all the
database-specific code in either a well-commented corner of the form for true
singletons, or in a base-class form for general solutions to inherit from.
As for the form linking, it appears to be a bit kludgey. I don't have the toy
application I made to test it anymore, but it was an app with two nonmodal
forms (with multiple instances) and database objects linked between them. You
can play with such a thing yourself...you'll find that the links are fragile.
It's like Delphi RTL keeps a table of links somewhere, and once it's done a
link, it marks it off and forgets it. So, it doesn't matter if the DataModule
or the form loads first, but it's a one-shot deal. You don't HAVE to
autocreate the DataModule, but if you're only going to have one up there, why
not do so?
On the other hand, autocreate datamodules are wonderful for putting
single-instance components on, like the TDatabase and other nifties.
::shrug:: I honestly think it's a solution for which a real problem hasn't
been invented yet. If anyone knows truly effective ways to use the buggers,
I'd love to hear them.
Blake Courtney
George Mealer wrote:
> As for the form linking, it appears to be a bit kludgey. I don't have the toy
> application I made to test it anymore, but it was an app with two nonmodal
> forms (with multiple instances) and database objects linked between them. You
> can play with such a thing yourself...you'll find that the links are fragile.
> It's like Delphi RTL keeps a table of links somewhere, and once it's done a
> link, it marks it off and forgets it. So, it doesn't matter if the DataModule
> or the form loads first, but it's a one-shot deal. You don't HAVE to
> autocreate the DataModule, but if you're only going to have one up there, why
> not do so?
>
> On the other hand, autocreate datamodules are wonderful for putting
> single-instance components on, like the TDatabase and other nifties.
> ::shrug:: I honestly think it's a solution for which a real problem hasn't
> been invented yet. If anyone knows truly effective ways to use the buggers,
> I'd love to hear them.
Me too.
I think I'll play with trying to Inherit from the TDataModule class
itself and maybe declare a few new proprties like TForm (to Link to)
and Bindings (Controls) to bind the datasource
to. I wonder if it's possible to guarantee uniqueness of the instantized DataAccess components
in the datamodule, I think so.
--
Blake Courtney
bl...@ogdencheck.net
George Mealer
In article <34BE00A6...@ogdencheck.net>, Blake Courtney <bl...@ogdencheck.net> wrote:
>
>I think I'll play with trying to Inherit from the TDataModule class
>itself and maybe declare a few new proprties like TForm (to Link to)
>and Bindings (Controls) to bind the datasource
>to. I wonder if it's possible to guarantee uniqueness of the instantized
> DataAccess components
>in the datamodule, I think so.
>
I'd love to hear about anything you figure out...posting here would be best,
so we can share, but you can also email me. :)
Gerald Von Korff
I think the main advantage of a datamodule is to provide you with a central location for
standard database settings for functions you may use without attaching a ttable or other
dataset component to a form. For example in a lookup function that requires a result--open the
database, perform the lookup and close it again. If you have a number of such functions which
use the same table in various locations, you can use the ttable component that is on your
datamodule. And when you make changes in the fields or other settings, you don't have to run
around to forms and change every ttable component.
George Mealer wrote:
--
Attorney by Day
Mathematics, Mozart, Delphi
and Family.