essam@gagme.chi.il.us (Essam Khairullah) (03/11/91)
I have a modal dialog that pops up at a given time (installed with an INIT) and I want to be able to dismiss the dialog if the user doesn't do it himself after a half an hour. How can I get ModalDialog to report null events (or in my filterProc) so that I can tell how much time has passed without the user having to cause an event? Thanks, --Essam -- Essam Khairullah essam@gagme.chi.il.us I don't got no fancy signature.
hairston@henry.ECE.CMU.EDU (David Hairston) (03/16/91)
[essam@gagme.chi.il.us (Essam Khairullah) writes:] [] I have a modal dialog that pops up at a given time (installed with an INIT) [] and I want to be able to dismiss the dialog if the user doesn't do it [] himself after a half an hour. How can I get ModalDialog to report null [] events (or in my filterProc) so that I can tell how much time has passed [] without the user having to cause an event? if you can write a modal dialog loop, you should make the effort to go the next step and write a modeless dialog loop which emulates a modal dialog as much as you'd like. the benefit of being modeless is that you can then handle null events (and you must handle others, like update and activate events). modal dialogs are nice for _simple_ things ... -dave- hairston@henry.ece.cmu.edu
kurash@ascutney.dartmouth.edu (Mark Valence) (03/19/91)
>essam@gagme.chi.il.us (Essam Khairullah) writes: > I have a modal dialog that pops up at a given time (installed with an INIT) > and I want to be able to dismiss the dialog if the user doesn't do it > himself after a half an hour. How can I get ModalDialog to report null > events (or in my filterProc) so that I can tell how much time has passed > without the user having to cause an event? As long as the dialog is "yours" (you're the one who called GetNewDialog or NewDialog), you can use the "refCon" field of the DialogRecord for the dialog (you can access this field with calls to GetWRefCon and SetWRefCon). Set the refCon of your DialogRecord to the time "one half hour" from when you first display the dialog (use GetDateTime from pascal or C to get the current time in seconds). Then, every time your filter proc gets an event (null or otherwise, if you like), check the value in the refCon with the current time. If the current time is ever greater than what's in the refCon, set itemHit (passed as a var parameter to the filter proc) to "ok" or "cancel", or whatever item you want to be hit by your ghost user, and return "true" from the filter proc. Yup. That'll do it. Alternately, you could store a pointer to the "deadline" and other stuff in the refCon. More indirection, but you can then have access to all of your INIT's global variables. BTW, your INIT might crash under 7.0b1 and b2, but the bug (in the Finder) that causes this crash is fixed in the b3 and b4 releases. Also, just to emphasize the point, if you are not the one who called GetNewDialog or NewDialog to post the dialog, you cannot use this scheme and claim to be bug-free. The "owner" of the dialog might be using its refCon for its own purposes. Sorry I had to post, but mail just bounced. Mark.
aep@world.std.com (Andrew E Page) (03/21/91)
I seem to recall that ModalDialog replies with an item number of 99 or 100 or something to that effect if there is a null event. You can verify this with SADE or think C debugger by setting a breakpoint in the default section of your switch statement. Other than that you may want to try a recurring VBL on 3600 tick (1 minute) intervals that will trip a driver or a global for you. -- Andrew E. Page (Warrior Poet) | Decision and Effort The Archer and Arrow Concepts Engineering | The difference between what we are CIS:70202,234 BIX:page1 | and what we want to be.