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.
<<winmail.dat>>
