How to check if a form exists?

[Haris I. Volos]

In my program I use forms that are not always are available(To use less
resourses) and I want to find a way to send them some data if are available.
In Delphi 3 I was using the try ...except statement but in Delphi 4
sometimes is raising exceptions.

Thanks in advance,

Haris

P.S.I use Delphi 4

[Richard Brunet]

>I want to find a way to send them some data

Take a look at the Screen (of type TScreen) global variable.

Regards... Richard bru...@dsuper.net

[Art Begun]

What I do before I create a form is see if Form1 = nil then form1:=
Tform1.Create(Application)
PROVIDED THAT when you Form1.Free you then set Form1 := n il.

In other words form1 is iniallty nil but when you free it you must set it to
nil. As long as you do that
you can check to see if it is nil to see if it is available.

Too bad free doesn't set the pointer to nil.

Haris I. Volos <ha...@nospam.hivolos.com.cy> wrote in message
news:7ns4f5$c5...@forums.borland.com...

[Ceci Gross]

> Too bad free doesn't set the pointer to nil.

Hmmm. I don't know how that could ever work. Which pointer should free set
to nil?

--Ceci.

[Jeff Overcash (TeamB)]

Delphi 5 introduces FreeAndNil and you pass it the instance you want to free and
nil. Now this will not handle multiple pointers to the same instance. It will
only nil the pointer you are passing the procedure.

--
Jeff Overcash (TeamB)
(Please do not email me directly unless asked. Thank You)
The mist crawls from the canal like some primordial phantom of romance
To curl, under the cascade of neon pollen. While I sit tied to the phone
like some expectant father, your carnation will rot in a vase.
(Fish)
--

[Jeff Overcash (TeamB)]

One thing you can do is loop the Forms property of the Global Screens
variable. This will list all the created forms. Just compared the classname
with the one you want and if it exists use it otherwise create it.

If you use a singleton object pointer and want to check if it is nil or not, try
placing code in the Forms OnDestroy event and nil, don't free, the object
pointer there. This can lead to a small chance of a timing problem but probably
not enough that it would affect you.

"Haris I. Volos" wrote:
>
> In my program I use forms that are not always are available(To use less
> resourses) and I want to find a way to send them some data if are available.
> In Delphi 3 I was using the try ...except statement but in Delphi 4
> sometimes is raising exceptions.
>
> Thanks in advance,
>
> Haris
>
> P.S.I use Delphi 4

--

[Ceci Gross]

>> Jeff:

Delphi 5 introduces FreeAndNil and you pass it the instance you want to free
and
nil. Now this will not handle multiple pointers to the same instance. It
will
only nil the pointer you are passing the procedure.
<<

That sounds like a convenient function. Of course the programmer is still
responsible for setting an object variable to nil (explicitly or via
FreeAndNil) if he or she is depending on comparisons to nil in the code. I
was just hoping that Art might see that there isn't any practical way to
"FreeAndNil" some magical MyObject variable within the TMyObject destructor.
I can see how that automatic "Form1" variable declaration might make one
think that the variable should some how be automatically nilled out...but if
you think about it just a little further, you see that it wouldn't make much
sense for that to be the case.

--Ceci.

[Jeff Overcash (TeamB)]

It is more than a convienance. MyObject.FreeAndNil; is better than
MyObject.Free; MyObject := nil;. The difference is that there is a minor time
period in which the Object is freed, but the Object Pointer is not nil. With
FreeAndNil the Address of the Object is saved off, the Pointer nil'd and then
the Object is freed so there is never a time that checking for
Assigned(MyObject) will ever point to a bad object. Much safer in multithreaded
apps in particular.

When a singleton object frees itself though, it is better to nil the singleton
pointer in the OnDestroy event. Automatic forms that destroy themselves when
closed are a good example of when to nil things there. As of D5 though, all
objects that are create and normally destroyed by calling Free, should call
FreeAndNil since it is safer.

--

[Ceci Gross]

>> Jeff:

MyObject.FreeAndNil; is better than MyObject.Free; MyObject := nil;.

...

Much safer in multithreaded apps in particular.
<<

Good point.

--Ceci.