Actually, I think the 2 techniques are simply expressions of a point of view, and either works fine in the sense of displaying, operating, and cleaning up after. If you do this
SearchForm := TSearchForm.Create(self);
SearchForm.Showmodal;
SearchForm.Free;
SearchForm := nil;
the calling form is saying "TSearchForm is mine, I control it." And you have
to have these 4 lines of code everywhere you use TSearchForm.
On the other hand, if you use my favorite technique
TSearchForm.execute(somestuff); //where execute() is a class proc in
TSearchForm that does the create, show, close (and free if appropriate).
the calling form is saying "TSearchForm, please do what you do best, and let me
know when you're done." Anywhere you want to use TSearchForm, you just need
this one line of code.
Jeremy
-----Original Message-----
From: advanced_delphi@yahoogroups.com on behalf of David Smith
Sent: Thu 12/6/2007 6:37 AM
To: advanced_delphi@yahoogroups.com
Subject: RE: [advanced_delphi] Mysterious vanishing form
That's straight out of the Delphi manual and I've never found any reason to
do it another way (even though I use embedded forms extensively in my
applications). I've never had the kinds of intermittent problems with form
loading that you describe. Go figure!
Dave
Jeremy Grand <[EMAIL PROTECTED]> wrote: Dave,
yes, I used to create forms from alien units. These days I write a class
procedure that creates the form in its own unit, and I'm proud of it (g). The
idea is highly cohesive, minimally coupled objects. But this puppy was coded
by 2 other folks before I got my hands on it, and I didn't know much when I
took it over. However, the creating proc is within epsilon of using a class
proc, which I consider very OOP, so I dispute your claim of "violates the
principles of OOP".
Anyway, where you create the object is not relevant to the problem. But the
code is spaghetti, and the on-demand creation and almost random freeing could
be a source of the problem. I'm glad you asked the questions that made me look
at this again.
The 2nd programmer chose to create the forms and mostly leave them in ram for
performance reasons, thinking that hiding and showing was quicker than freeing
and creating. With faster processors this might not be such an issue, but
changing the paradigm isn't simple, given the mass of code involved.
Jeremy
-----Original Message-----
From: advanced_delphi@yahoogroups.com on behalf of David Smith
Sent: Wed 12/5/2007 7:52 PM
To: advanced_delphi@yahoogroups.com
Subject: RE: [advanced_delphi] Mysterious vanishing form
Well right off the bat I'd say that you will have problems doing things that
way. Your creating and destroying the form from it's own unit! This violates
the principles of OOP. The standard Delphi way to instantiate a non
auto-created form is to launch it from the primary form (or a different
secondary form) as follows:
SearchForm := TSearchForm.Create(self);
SearchForm.Showmodal;
SearchForm.Free;
SearchForm := nil;
This is such a safe way of doing things that you will never have any GPF's. If
you want to show the form non modally (I.E. using Searchform.Show instead),
then put Action := caFree; in the OnClose event of the SearchForm. There,
that's all you need to know to write clean, safe apps that never crash (for
those kinds of reasons). As a debugging measure, I'd say try it and see if
your problem goes away.
Dave
Jeremy Grand <[EMAIL PROTECTED]> wrote:
My form handling in general? Now that is broad-ranging (g).
There are 3 primary forms. The main form is of course autocreated. View
detail form autocreated. Search form created on demand when called from main.
Main frees the search form. The following proc is in the search form unit,
but not a method of the form. The proc sets up the search initially, and the
user can do multiple searches from the form before finally exiting back to
main.
procedure infosearch(pstr:string;var puser:tuser);
begin
if frmSearch=nil then frmsearch := tfrmsearch.Create(nil); //jhg 04/20/2004
with frmsearch do begin
edSearch.Text := pstr;
putcbSearchLabel;
show;
setRGSearchByItem(0);
doSearch;
end;
The following, from an earlier post, is called in a click event in the search
form.
myobj.loaddata;
self.hide;
viewDetail(myobj); // does a ShowModal on the detail form. Detail form
closes itself, but does not free.
self.show; //access violation here --sometimes, not always--.
Jeremy
---------------------------------
From: advanced_delphi@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of
David Smith
Sent: Wednesday, December 05, 2007 4:19 PM
To: advanced_delphi@yahoogroups.com
Subject: RE: [advanced_delphi] Mysterious vanishing form
Well I for one am not getting a good snapshot of your form handling in
general. You may have a systematic problem going on from an unlikely source.
Unless this app is just these two (or 3) forms?
re: the resource problem. I've never heard of these kind of problems and have
never seen them on my apps (running on everything but Vista). Are you doing
something unusual with resource handling?
Dave
Jeremy Grand <[EMAIL PROTECTED]> wrote:
Dave, I know what you mean. But as a practical matter, there is just
far too much code in the viewer to expect anyone to wade through. I'm
hoping for ideas on where to look, really. I have eurekalog implemented, so
I can see the call stack when the problem happens, but there is nothing
unusual there.
I've verified that the viewDetail form does not refer to the search
form. It is not Used, so, how could anything that happens in viewDetail
affect search? The problem happens sometime before self.show, and by
inference after self.hide. They ain't nothin else between, cept viewDetail.
I'm thinking external forces. I have another issue that comes and goes,
which very likely is external: the app issues an out of resources message
and claims the window doesn't have scroll bars. This gives credence to
environmental issues, but no clue on how to diagnose.
Jeremy
---------------------------------
From: advanced_delphi@yahoogroups.com [mailto:[EMAIL PROTECTED] On
Behalf Of David Smith
Sent: Wednesday, December 05, 2007 10:52 AM
To: advanced_delphi@yahoogroups.com
Subject: Re: [advanced_delphi] Mysterious vanishing form
There appears to be nothing wrong with the code you have shown so how about
showing the rest of it so someone can make a stab at debugging it for you?
Dave
Jeremy Grand <[EMAIL PROTECTED]> wrote:
My app sometimes tries to show a hidden form that is no longer in
existence, but I can't think of a reason for it to no longer exist.
Here's the scenario:
There is a search form, and a detail form, both Created and in existence
always, but only one is visible at a given moment. In the search screen a
click handler does this:
myobj.loaddata;
self.hide;
viewDetail(myobj); // does a ShowModal on the detail form. Detail
form closes itself, but does not free.
self.show; //access violation here --sometimes, not always--.
This works fine almost all the time. Obviously, some users (or the OS)
are doing something I'm not expecting, but what? The detail form is
modal, and the search form is not visible, so how can it be freed? Or
maybe more precisely, how can Self not point to something Show-able?
I must have a blind spot here. Any suggestions?
Jeremy
---------------------------------
Never miss a thing. Make Yahoo your homepage.
---------------------------------
Looking for last minute shopping deals? Find them fast with Yahoo! Search.
---------------------------------
Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.
---------------------------------
Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.
<<winmail.dat>>
