Andy Lacey
andy at minstersystems.co.uk
Wed Oct 29 13:50:57 CST 2003
Thanks Ken. I'll work through this tomorrow. Andy Lacey http://www.minstersystems.co.uk > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Ken Ismert > Sent: 29 October 2003 17:40 > To: 'Access Developers discussion and problem solving' > Subject: RE: [AccessD] Disabling the user > > > Andy, > > I would suggest a variation of option 2: > > * In your Popup's module: > - Set Cancel=True in the Form_Unload event to reliably > prevent the user from closing the form. > - Add any other public subs required to display messages, > update progress bars, etc. > > * Create a class module, CUserPopup, to manage your Popup form. > - Add a module level form object variable: Private > mFrmPopup As Form_YourPopup > - In Class_Initialize, create an instance of the form: Set > mFrmPopup = New Form_YourPopup > - In Class_Terminate, add this line: Set mFrmPopup = Nothing > - Add a public sub, Show, with one line: mFrmPopup.Visible = True > - Add any public subs required as wrappers for the popup's > display and update routines > > * In your command button event procedure: > Dim rPopup as CUserPopup > Set rPopup = New CUserPopup ' Creates Popup form > rPopup.Show > ' (Run your Procedure) > Set rPopup = Nothing ' (optional) Destroys Popup form > > The beauty of this is, you don't have to worry about shutting > down the popup. Set rPopup = Nothing is really there for good > form. Even if the procedure errors out, rPopup will go out of > scope at the end of the procedure, and be terminated, > destroying the popup form. > > With this setup, the popup is divorced from any other > function, so you can use it in any circumstance you like, > without needing to modify the Popup's code. > > Also interesting is that regardless of Cancel=True in the > Unload event, the popup gets closed anyway in > Class_Terminate. This is because an object needs at least one > reference to exist. When that reference, in this case > mFrmPopup, is set to Nothing, the form object will be > destroyed, protestations of the Unload event notwithstanding. > > -Ken > > > -----Original Message----- > From: Andy Lacey [mailto:andy at minstersystems.co.uk] > Sent: Tuesday, October 28, 2003 12:32 PM > To: 'Access Developers discussion and problem solving' > Subject: RE: [AccessD] Disabling the user > > > Thanks John. Yes I think that's where I'm heading (option 2). > Am going to take a look at JC's progress form as a basis. > > Andy Lacey > http://www.minstersystems.co.uk > > > -----Original Message----- > > From: accessd-bounces at databaseadvisors.com > > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of > John Bartow > > Sent: 28 October 2003 16:14 > > To: Access Developers discussion and problem solving > > Subject: RE: [AccessD] Disabling the user > > > > > > Hi Andy, > > Similar to Stuart's suggestion, I've handled this situation > using two > > methods: > > > > -Present a progress/info form with a timer set to the > maximum amount > > of time this process will take which I only use for non-critical > > processes to give the user a heads up to what is happening. > > > > -Open a modal pop-up form with info/progress that then calls the > > procedure. When the procedure returns a value close the form. The > > command button doesn't actually call the procedure but > rather it calls > > the form that calls the procedure, thus making the > procedure calling > > form easily reusable, just have a button that opens the form. > > > > It sounds like the latter might fit your case. > > > > HTH > > John Bartow > > > > > -----Original Message----- > > > From: accessd-bounces at databaseadvisors.com > > > [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Stuart > > > McLachlan > > > Sent: Tuesday, October 28, 2003 5:46 AM > > > To: Access Developers discussion and problem solving > > > Subject: Re: [AccessD] Disabling the user > > > > > > > > > On 28 Oct 2003 at 11:24, Andy Lacey wrote: > > > > > > > Hi folks > > > > If you want a routine (called from a command button) to finish > > > before the > > > > user can do anything else in the app how would you achieve > > > that, short of > > > > putting up a message saying "Wait" and cutting their > > fingers off if > > > > they don't? The forms quite busy and there are a number > > of buttons > > > > they could press, or close the form etc, and I could write a > > > > function which just disabled all of those things then > re-enabled > > > > them when the routine's finished, but it's a bit messy. > > Is there a > > > > cleaner way of just > > > temporarily > > > > disabling the app? > > > > -- > > > > > > One way would be to open another form modally ie. > > > "WindowMode=acDialog" with no buttons or ControlBox and put the > > > routine in that form's OnOpen. Then close the form when it has > > > finished. > > > > > > > > > > > > > > > > > > > > > -- > > > Lexacorp Ltd > > > http://www.lexacorp.com.pg > > > Information Technology Consultancy, Software Development,System > > > Support. > > > > > > > > > > > > _______________________________________________ > > > AccessD mailing list > > > AccessD at databaseadvisors.com > > > http://databaseadvisors.com/mailman/listinfo/accessd > > > Website: http://www.databaseadvisors.com > > > > > > > > > > > > _______________________________________________ > > AccessD mailing list > > AccessD at databaseadvisors.com > > http://databaseadvisors.com/mailman/listinfo/a> ccessd > > Website: > > http://www.databaseadvisors.com > > > > > > > > _______________________________________________ > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/a> ccessd > Website: > http://www.databaseadvisors.com > >