Board index » delphi » Design vs Run use of "Active"

Design vs Run use of "Active"

Folks:

Seems like an obvious problem to solve, but I haven't found a good way.

I often want to set database components (eg: TTable) to "Active" at
design time, so as to make connection to database and take advantage of
fieldnames etc supplied from database.

But I want Active to default to false at run time, so as to be able to
prompt user for database name (or file in the case of desktop DB) (and
the database I used at design time might not be available to user).

I haven't found a good place to intercept the form or table creation
process to switch Active to false... I'd hate to have to manually set
Active false in many tables for release versions...  very mistake
prone.  

Any ideas on how to solve this?

Graham

 

Re:Design vs Run use of "Active"


Use TDatabase component.  When you set Connected proprty of TDatabase to False,
all TTable(s) & TQuery(s) will be closed automatically.
Other hint is that you place TDatabase on the MainForm so that OnFormCreate of the MainForm
you can place code like Database1.Connected := False;
Since MainForm is automatically created and only one time, the code will run only one time.

HTH
Ashok
    Graham wrote in message <360C0721.AE8B1...@sdsu.nospam.edu>...
    Folks:

    Seems like an obvious problem to solve, but I haven't found a good way.

    I often want to set database components (eg: TTable) to "Active" at
    design time, so as to make connection to database and take advantage of
    fieldnames etc supplied from database.

    But I want Active to default to false at run time, so as to be able to
    prompt user for database name (or file in the case of desktop DB) (and
    the database I used at design time might not be available to user).

    I haven't found a good place to intercept the form or table creation
    process to switch Active to false... I'd hate to have to manually set
    Active false in many tables for release versions...  very mistake
    prone.  

    Any ideas on how to solve this?

    Graham

Re:Design vs Run use of "Active"


Quote
> Ashok wrote:
> Use TDatabase component.  When you set Connected proprty of TDatabase
> to False,
> all TTable(s) & TQuery(s) will be closed automatically.
> Other hint is that you place TDatabase on the MainForm so that
> OnFormCreate of the MainForm
> you can place code like Database1.Connected := False;
> Since MainForm is automatically created and only one time, the code
> will run only one time.

Ashok:  Thanks for your speedy reply.

Unfortunately, I had already tried that approach, and so far as I can
see, it does not work.

It appears that as soon as the TDatabase is created (with Connected set
True at design time) it attempts to connect to the actual database, and
this happens *before* the main form's FormCreate is called. So although
the end result appears to be "not connected to database", it has not
avoided the problem that the app attempts to connect, and that's what
I'm trying to avoid.

Graham

Re:Design vs Run use of "Active"


Quote
Graham wrote:

> Folks:

> Seems like an obvious problem to solve, but I haven't found a good way.

> I often want to set database components (eg: TTable) to "Active" at
> design time, so as to make connection to database and take advantage of
> fieldnames etc supplied from database.

You don't need "Active = True" for getting persistent field objects.
The design time component- and property editors do that for you.

Quote

> But I want Active to default to false at run time, so as to be able to
> prompt user for database name (or file in the case of desktop DB) (and
> the database I used at design time might not be available to user).

Just set Active = False before doing your final compile run.
Actually, I can't really think of a reason why one must compile
with Active = True. Honestly, this approach doesn't make a whole lot
of sense to me - not meaning to insult you. ;-)

Karl

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   Karl Waclawek
   KD Soft Inc.
 * Phone:  (905) 579-3443
 * E-Mail: wacla...@idirect.com

Re:Design vs Run use of "Active"


Quote
Karl Waclawek wrote in message <360C3EC4.D01AA...@idirect.com>...
>Graham wrote:

>You don't need "Active = True" for getting persistent field objects.
>The design time component- and property editors do that for you.

You do when you use queryies based on other tables. The table
supplying parameter values must be active to access the fields at
design time. At least, that's what the IDE makes me do.

Quote

>Just set Active = False before doing your final compile run.
>Actually, I can't really think of a reason why one must compile
>with Active = True. Honestly, this approach doesn't make a whole lot
>of sense to me - not meaning to insult you. ;-)

This, I agree with. I keep my TDatabase active while designing until
ready to distribute. Then turn it off, Compile All, and there you
go......

Woody

Re:Design vs Run use of "Active"


Quote
Karl Waclawek wrote:

> You don't need "Active = True" for getting persistent field objects.
> The design time component- and property editors do that for you.
> Just set Active = False before doing your final compile run.
> Actually, I can't really think of a reason why one must compile
> with Active = True. Honestly, this approach doesn't make a whole lot
> of sense to me - not meaning to insult you. ;-)

Karl: Thanks for the concern for my feelings :-)

Actually, you caught me on that -- I wasn't intending to focus on *why*
I wanted it this way, and you're right, in my ill-considered example a
TTable doesn't need to be active to grab the fieldnames for the
component editors... however the TDatabase does need to be connected
(and at runtime I want to start not connected). And TTables do need to
be Active to display data in controls, which is most helpful for layout
and generally remembering what you are doing etc.

And yes, one can manually change things to False before compiling for
distribution (or more frequently, testing in alternative
environments)... and if you have only one or two that's fine, but if you
have a bunch it's tedious (though somewhat helped by setting the DB to
disconnected which cascades to inactivate the TTables).

So, I'm still interested in how to modify properties at runtime *after*
they are loaded but *before* the components have a chance to actually do
anything with them.

Thanks for your comments though!

Graham

Re:Design vs Run use of "Active"


One solution is to just set the Connected property of your TDatabase
component to False before you compile. That will force the Active property
of every dataset component to False.

--
Bill Todd
(Sorry but TeamB cannot answer questions received via email)
(Remove nospam from my email address to contact me for any other reason)

Re:Design vs Run use of "Active"


Bill, Woody and all --

Thanks for the several suggestions that all point to manually toggling
the TDatabase.Connected property to side-effect all the TTables to
inactive.... <sigh>.

The effect I was hoping to achieve was this:

(a) Have my (perhaps numerous) forms appear at design-time always
populated with data from a test DB.  This data would be supplied via
TDatabase(s) in a "design-time-only" DataModule that in ProjectOptions
is set *not* to Auto-Create.

(b) At run-time, forms could be created whose TTables could be
programmatically set to point to TDatabases that in turn could be
programmatically set to point to various databases relevant at run-time.

--- sounded good but there were a couple of hitches:

1) Couldn't find a way to de-Active-ate TTables at runtime before they
try to find a database... and

2) if for any reason a DB gets disconnected at design-time, it's TTables
go Inactive... a property value that might then get inadvertantly saved
into the dfm anyway... dang.

-------------------------------

I agree that if you have just one database to deal with, then it's no
big deal.  But if you have several, and a bunch of forms, with a whole
bunch of controls, it gets a bit more tedious.

An alternatives that came to mind was:

-- A component that can Active-ate all TTables on a form on demand at
Design time and de-Active-ate them for run-time.

Graham

Re:Design vs Run use of "Active"


Hi Graham,
I see I am not the only one having troubles with this Delphi "feature".
It happens to me often that I make the table active at design time
just to check whether all lookup links are valid. Now these lookup datasets
(located on different datamodules) go active as well and, what is most
important, remain active even if I close the first table again.
Now I have to go through several datamodules just to close the lookup
datasets. Could be another Delphi 5  wish:
"property InactivateOnRuntimeCreate: boolean ..... default TRUE "
--
Roman
(please remove STOPSPAM. in header)
URL:  www.rksolution.cz (Delphi corner)
MAIL: I...@rksolution.cz

Other Threads