John Bartow
john at winhaven.net
Wed Oct 29 12:18:47 CST 2003
I think I like this idea too! Its a good day on the list for me :o) JB > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Ken Ismert > Sent: Wednesday, October 29, 2003 11:40 AM > 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/accessd > Website: http://www.databaseadvisors.com > >