 | |
#11
 
| |||
| |||
|
Re: Trapping the X? -
09-18-2010
, 04:37 AM
|
I do exactly the same thing as David. I remove the title bar completely, and I also remove the controls from forms and create my own. It was the only way I could guarantee control over the process. Has worked fine for years. The Frog |
If you have a form and you minimize it the controls don't track as well.
Do you have code in the Activate event to move the buttons as well?
#12
| |||
| |||
|
|
The Frog wrote: I do exactly the same thing as David. I remove the title bar completely, and I also remove the controls from forms and create my own. It was the only way I could guarantee control over the process. Has worked fine for years. In David's examples he has only the X box. Is yours the same as well? If you have a form and you minimize it the controls don't track as well. Do you have code in the Activate event to move the buttons as well? |
minimize their forms.
The only thing I'm wondering about is if in your case you'd need to
trap Ctrl-F4. I can't recall if it works for forms without title
bars or not.
--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/
#13
| |||
| |||
|
#14
| |||
| |||
|
|
Hi Salad, I keep my forms modal (mostly) and completely eliminate the 'X' so to speak. I place a substitute 'X' - which is really just a command button in the appropriate location. I have done sometimes the same with a minimize but never worked out how to re-maximise it, so in the end I used modal forms. The user is either working on the form that is open, or they are not. If I need a type of switching between forms then I use a multitab type approach with all the possible 'things' a user could want on a single form (so to speak). I did see a nice multitab form that allowed the creation of new tabs on the fly, as well as the closing of those tabs, similar to a web browser I suppose. I have not tried to replicate the functionality as none of the apps I work with / design have required it. If I needed greater complexity and / or flexibility I would probably head this way as it was extremely neat and effective. If I get time I might have a go at replicating the functionality, but I am guessing it would not be straight forward, and would probably be meta-data driven (ie/ you need some sort of descriptor of what goes where on a form and the functions it requires etc...., then the forms own code could add a tab and build the appropriate form.) Nice, but seems like a heap of work if you dont actually need it. From an academic point of view I would love to know how they actually did it though. Cheers The Frog |
It'd be nice if MS set a flag when the "X" is pressed. Then a person
could let the op knop that data won't be saved if validation checks
don't pass.
#15
| |||
| |||
|
|
The Frog wrote: Hi Salad, I keep my forms modal (mostly) and completely eliminate the 'X' so to speak. I place a substitute 'X' - which is really just a command button in the appropriate location. I have done sometimes the same with a minimize but never worked out how to re-maximise it, so in the end I used modal forms. The user is either working on the form that is open, or they are not. If I need a type of switching between forms then I use a multitab type approach with all the possible 'things' a user could want on a single form (so to speak). I did see a nice multitab form that allowed the creation of new tabs on the fly, as well as the closing of those tabs, similar to a web browser I suppose. I have not tried to replicate the functionality as none of the apps I work with / design have required it. If I needed greater complexity and / or flexibility I would probably head this way as it was extremely neat and effective. If I get time I might have a go at replicating the functionality, but I am guessing it would not be straight forward, and would probably be meta-data driven (ie/ you need some sort of descriptor of what goes where on a form and the functions it requires etc...., then the forms own code could add a tab and build the appropriate form.) Nice, but seems like a heap of work if you dont actually need it. From an academic point of view I would love to know how they actually did it though. Cheers The Frog Kinda what I thought. It'd be nice if MS set a flag when the "X" is pressed. *Then a person could let the op knop that data won't be saved if validation checks don't pass. |
simply closes the form, why can't the form's unload event take care of
either way of closing the form and give the user the opportunity to
save changes? A simple test I tried that traps a variant Response
variable for a MsgBox in the Unload event suggests that the user can
choose to have the changes saved.
J. A. Fortune
CDMAPoster (AT) FortuneJames (DOT) com
#16
| |||
| |||
|
|
On Sep 20, 1:10 pm, Salad <sa... (AT) oilandvinegar (DOT) com> wrote: The Frog wrote: Hi Salad, I keep my forms modal (mostly) and completely eliminate the 'X' so to speak. I place a substitute 'X' - which is really just a command button in the appropriate location. I have done sometimes the same with a minimize but never worked out how to re-maximise it, so in the end I used modal forms. The user is either working on the form that is open, or they are not. If I need a type of switching between forms then I use a multitab type approach with all the possible 'things' a user could want on a single form (so to speak). I did see a nice multitab form that allowed the creation of new tabs on the fly, as well as the closing of those tabs, similar to a web browser I suppose. I have not tried to replicate the functionality as none of the apps I work with / design have required it. If I needed greater complexity and / or flexibility I would probably head this way as it was extremely neat and effective. If I get time I might have a go at replicating the functionality, but I am guessing it would not be straight forward, and would probably be meta-data driven (ie/ you need some sort of descriptor of what goes where on a form and the functions it requires etc...., then the forms own code could add a tab and build the appropriate form.) Nice, but seems like a heap of work if you dont actually need it. From an academic point of view I would love to know how they actually did it though. Cheers The Frog Kinda what I thought. It'd be nice if MS set a flag when the "X" is pressed. Then a person could let the op knop that data won't be saved if validation checks don't pass. Maybe I'm missing something here, but if the Exit command button simply closes the form, why can't the form's unload event take care of either way of closing the form and give the user the opportunity to save changes? A simple test I tried that traps a variant Response variable for a MsgBox in the Unload event suggests that the user can choose to have the changes saved. New or old rec? |
Cancel = True on a saved rec works ok in the Unload. (I'm not going to
test to see if it saves the modified data or just the old if Cancel =
True) But on a new rec, if it displays an error message as in
B4_Update event
If IsNull(FirstName) then
msgbox "Supply a first name"
cancel = True
blnErr = True
Me.FirstName.setfocus
Endif
then when it hits the Unload event
IF blnErr then Cancel = True
the new data is wiped out if the (X) is used.
It seems kinda of stupid to even display the error message if the data
is going to be wiped out. And if you don't have Cancel = True in the
Unload event, the Cancel in the B4Update is ignored. Where's the benefit?
It would be one thing if the only thing you ever did was use an command
exit button. But if you have navigation buttons you can't trap them
(know that they were used to move to another record) or the Exit button.
With the Nav buttons they at least recognize the B4Update and keep
the data, not the (X) button.
If you have a method to hit the (X) button in the title bar, display any
error messages in the B4Update event and remain open and keep the data
let me know.
Quote:
|
J. A. Fortune CDMAPoster (AT) FortuneJames (DOT) com |
#17
| |||
| |||
|
|
New or old rec? Cancel = True on a saved rec works ok in the Unload. *(I'm not going to test to see if it saves the modified data or just the old if Cancel = True) *But on a new rec, if it displays an error message as in * * B4_Update event * * * * If IsNull(FirstName) then * * * * * * * * msgbox "Supply a first name" * * * * * * * * cancel = True * * * * * * * * blnErr = True * * * * * * * * Me.FirstName.setfocus * * * * Endif then when it hits the Unload event * * * * IF blnErr then Cancel = True the new data is wiped out if the (X) is used. It seems kinda of stupid to even display the error message if the data is going to be wiped out. *And if you don't have Cancel = True in the Unload event, the Cancel in the B4Update is ignored. *Where's the benefit? It would be one thing if the only thing you ever did was use an command exit button. *But if you have navigation buttons you can't trap them (know that they were used to move to another record) or the Exit button. * * With the Nav buttons they at least recognize the B4Update and keep the data, not the (X) button. If you have a method to hit the (X) button in the title bar, display any error messages in the B4Update event and remain open and keep the data let me know. |
with it a bit to see what I can discover.
James A. Fortune
CDMAPoster (AT) FortuneJames (DOT) com
 |
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.