Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / Languages / VB.NET / March 2008

Tip: Looking for answers? Try searching our database.

Form.Visible=False drive Fork closing?

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Alan Gillott - 19 Mar 2008 14:33 GMT
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
Armin Zingler - 19 Mar 2008 15:34 GMT
> I am having difficulty believing this but it appears that setting a
> form Invisible drives the formclosing event. Actually, i am
[quoted text clipped - 17 lines]
> Can anyone confirm this behavior and more to the point, convince me
> that it is correct behavior.

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
Alan Gillott - 19 Mar 2008 18:22 GMT
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

>> I am having difficulty believing this but it appears that setting a
>> form Invisible drives the formclosing event. Actually, i am
[quoted text clipped - 31 lines]
>
> Armin

Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.