Form.Visible=False drive Fork closing?

  • Thread starter Thread starter Alan Gillott
  • Start date Start date
A

Alan Gillott

I am having difficulty believing this but it appears that setting a form
Invisible drives the formclosing event. Actually, i am intercepting the user
close (the nasty x box top right that causes more trouble thay other button
in windows) and setting the form invisible and cancelling the close. so well
and good, but all that happens is the form closing event gets driven again
and the cancel close is ignored.

This is the second app doing this to me, and I have a whole raft more to
convert from VB6 that do the same; essentially waiting for a double click on
a taskbar icon to redisplay the form. The work around is to minimise and
remove it from the task bar. That makes the form vanish but is is somewhat
inelegant when that's what Visible is for - there's no point to the visible
attribute if it closes the form.

Im sure VB is working as designed but it really is inconsistent behavior and
in my view a design error that needs to be fixed.

Can anyone confirm this behavior and more to the point, convince me that it
is correct behavior.

Thanks
 
Alan Gillott said:
I am having difficulty believing this but it appears that setting a
form Invisible drives the formclosing event. Actually, i am
intercepting the user close (the nasty x box top right that causes
more trouble thay other button in windows) and setting the form
invisible and cancelling the close. so well and good, but all that
happens is the form closing event gets driven again and the cancel
close is ignored.

This is the second app doing this to me, and I have a whole raft
more to convert from VB6 that do the same; essentially waiting for a
double click on a taskbar icon to redisplay the form. The work
around is to minimise and remove it from the task bar. That makes
the form vanish but is is somewhat inelegant when that's what
Visible is for - there's no point to the visible attribute if it
closes the form.

Im sure VB is working as designed but it really is inconsistent
behavior and in my view a design error that needs to be fixed.

Can anyone confirm this behavior and more to the point, convince me
that it is correct behavior.
Click to expand...

I can confirm that the form is closed if you hide it, and I think it's
correct. The message loop keeping the
Form (I guess it's a modal Form) alive checks whether either the
dialogresult has been set or the form got invisible. I think it is
correct because what do you want with an invisible modal form? The
windows revealed behind could not be used anyways because of an existing
modal form. That's the rule for modal windows.

I can not confirm that the FormClosing events fires twice even if you
execute e.cancel=true and me.hide in the FormClosing event. I hope I
understood it correctly.


Armin
 
Good, I wasn't imagining it! alas, my application is hung off the system
tray and I want the forms to be invisible except for when the user needs to
interact with the application. Minimised screens occupy valuable task bar
space. I regard this behavior to be a BUG as there are lots of good reasons
to start an application with an invisible form. that routine perhaps should
also check if there is a NotifyIcon control active for the form before
assuming it is dead!

So I am going to have to create a Vanish method that Minimises the Form and
removes it from the task bar. I have 6 or seven monitoring utilities that
use this technique which only need to active when something is broken.

Please, if anyone from MS VB team is monitoring: I beg you to fix this
nuisance problem.

A
 
Back
Top