Form_Deativate (what called it)

zekeman

Well-known member
Joined
May 23, 2006
Messages
224
Programming Experience
10+
I need help determining what control called the form_deactivate.

Distinquishing between the user (X) closing the form verses the

the deactivate getting called by something other.

I am hoping that in the following line of code there is a way
to get to what I need such as using the 'sender' or 'System.EventArgs'

VB.NET:
[SIZE=2][COLOR=#0000ff]Private[/COLOR][/SIZE][SIZE=2][COLOR=#0000ff]Sub[/COLOR][/SIZE][SIZE=2] Form1_Deactivate([/SIZE][SIZE=2][COLOR=#0000ff]ByVal[/COLOR][/SIZE][SIZE=2] [COLOR=red]sender[/COLOR] [/SIZE][SIZE=2][COLOR=#0000ff]As[/COLOR][/SIZE][SIZE=2][COLOR=#0000ff]Object[/COLOR][/SIZE][SIZE=2], [/SIZE][SIZE=2][COLOR=#0000ff]ByVal[/COLOR][/SIZE][SIZE=2] e [/SIZE][SIZE=2][COLOR=#0000ff]As[/COLOR][/SIZE][SIZE=2] [COLOR=red]System.EventArgs[/COLOR]) [/SIZE][SIZE=2][COLOR=#0000ff]Handles[/COLOR][/SIZE][SIZE=2][COLOR=#0000ff]Me[/COLOR][/SIZE][SIZE=2].Deactivate[/SIZE]

Thanks in advance.
 
I don't think you understand what Deactivate means. That is an event that gets raised when a form loses focus. It's got nothing specifically to do with a form being closed. Also, that method handles the form's Deactivate event, so the sender will ALWAYS be the form. What exactly are you trying to achieve, so that we can describe the best way to go about it because what you're doing is incorrect. If you want to be notified when a form is closing you need to handle its FormClosing event. Also, there is no justifiable reason to have to know if the user pressed the Close button on the title bar. If you don't want them to use that then you disable it. If you don't disable it then it should be no different to using any other method of closing the form. if you want to prompt the user to save changes or whatever then you should do so in the FormClosing event for EVERY method of closure. The ONLY justifiable reason to test why a form is closing is if you normally disallow the closure, like if you minimise to the system tray, and you want to allow the form to close if Windows itself is closing. If you feel you need to do so for some other reason then you've designed your application incorrectly.
 
It seems like Basic programmers have been picked on since the beginning of time and I guess a vb.basic formum is going to be the worst of all places. Nobody likes me in here. :) LOL

Thanks for you help. I'm converting an application from VB6 to 2005 but now .... Im just trying to figure what to do with the code inside the form_deactivate (old vb6 unload)/lost focus event). Imagine a formBig without focus and a smaller in size formSmall with focus over the top of the formBig. If formSmall puts up a message box, it is deactivated, if it calls a splash form to display a timed message, it is deactivated, and if the user clicks on the formBig it is deactivated etc.

There are things to do When the Deactivate event fires but preferable not when it is fired by a message box or splash form, I wanted to know if there is a way to sense the caller or type of call

Thanks

P.S. - Gone are the days when you could actually ask users to perform a save-action.
 
Event handlers aren't called by any object other than the one whose event is being handled, or at least they shouldn't be. That means that the 'sender' of a Deactivate event is always going to be the form that is losing focus. Also, I really don't see what the user closing the form via the Close button on the title bar has to do with losing focus. If you want to do something when the form closes then use the FormClosing or FormClosed event. If you want to know that the Deactivated event was raised because a dialogue was displayed then set a Boolean variable before displaying the dialogue. You can then test the value of that variable in your Deavtivate event handler.

Finally, what does that last line mean? Prompting the user to save their work if they try to close a form with pending changes is good UI design. Treating the user closing a form via the Close button on the title bar differently to their closing the form some other way is bad UI design. Closing a form should be closing a form regardless of how it's done. If the user tries to close a form with pending changes they should be prompted to save their work before closing and given Yes, No and Cancel options.
 
Yes I will set a boolean variable before the dialog - thanks.

One of the bigest problems converting has been that AS: the UPDATE message warns 'these control have a new behavior' i.e. they will get called when the form is loading (not deactivate). I know they say rewrite but sometimes thats not affordable. Im putting up booleans in too many places and wanted one stop stopping at the deactivate, combo.text changes, etc. I'm dealing with front-end edits where one value change will effect the drop downs in many other forms - and checks on checks. Thanks again I will stick with your suggestion.

Oh the meaning of no save buttons was only meant to say that save buttons are now-a-days implied as you move
through forms in most apps. However I prefer a save button which I guess seems anitiquated.
 
Last edited:
Back
Top