| Title: | DECWINDOWS 26-JAN-89 to 29-NOV-90 |
| Notice: | See 1639.0 for VMS V5.3 kit; 2043.0 for 5.4 IFT kit |
| Moderator: | STAR::VATNE |
| Created: | Mon Oct 30 1989 |
| Last Modified: | Mon Dec 31 1990 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 3726 |
| Total number of notes: | 19516 |
I've got some questions concerning work procedures that I havn't
been able to locate answers for.
1) if a work procedure returns False does this imply that the procedure
will be called again?
2) if it is called again, is it up to the procedure to control the
flow of execution (i.e. what do I fo now?).
Any pointers to answers or any help would be appreciated. BT, I'm
posting this here because CLT has been difficult to reach lately.
/Ron
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 115.1 | ENXIO::thomas | The Code Warrior | Fri Feb 03 1989 00:52 | 10 | |
If a work proc returns TRUE, the tool kit deletes it. The work proc better have cleaned up all references to itself AND deallocated any memory it XtMalloc'ed. If a work proc return FALSE, it is the responsibility of the work proc to save any state info it needs for its next invocation. The client_data argument will normally be a pointer to block of memory that contains the work procs state information. The toolkit will call the work again unless someone XtRemoveProc's it. | |||||
| 115.2 | Thanks! | VENOM::DLUGOSZ | Ron Dlugosz, DTN 264-0306 | Sat Feb 04 1989 18:16 | 3 |
Thanks for the help Tom....fast too!
| |||||
| 115.3 | Can a work procedure do this? | VAXWRK::SCHNEIDER | Lather. Rinse. Repeat. | Thu Mar 09 1989 15:52 | 12 |
I'm just wondering why I've never heard of using work procedures for
fetching widgets that weren't fetched at application startup time.
SOrt of an intermediate stage to not make the application be so slow
initially and also not make the user wait the first time he/she first
uses a given widget that has its fetching deferred.
If this isn't a viable function for a work procedure, it seems to me it
should be made to be viable in the future. Response time is certainly
a large part of the sales equation.
Dan
| |||||
| 115.4 | Dispatch in haste, fetch at leisure | CALL::SWEENEY | Transforming Enterprises into Solutions | Thu Mar 09 1989 20:38 | 23 |
Perhaps you not heard of it recently, but in the lore of DECwindows, it was discussed as one the motivations for work procedures. And, yes, I do defer fetching widgets when it seems like the right thing to do. Oh, it would be nice to have some sort of placeholder data structure that would accomplish an automatic defferal, but I can't fit the concept into the margin of this notepaper. O, surprises with work procedures, when you do things in these steps: Initialize Register the work procedure Create some widgets Realize MainLoop The work procedure is called before all of the X events that map and expose all of the windows are completed, so the work procedure is called with your UI look like an application that's taken a coffee break until the work procedure is called. I kludged and used a timer to execute XtAppAddWorkProcedure so that it would be called after all of the map and expose activity of Realize had completed. | |||||