king@cats.ucsc.edu (Andrew Charles Harris) (06/02/91)
I am working on a program which requires the user to input text information during the course of the program. This information in direct response to a popup dialog. The problem is this: The program will not wait for this input. It seems to set up the current popup dialog, and then move on without waiting for the user to input the necessary information. If anyone has any code, or knows how to solve this dilema, I would appreciate it greatly. Thanks in advance, Andy Harris. (king@ucscb.ucsc.edu, or dank@ucscb.ucsc.edu)
dce@smsc.sony.com (David Elliott) (06/04/91)
In article <16495@darkstar.ucsc.edu>, king@cats.ucsc.edu (Andrew Charles Harris) writes: |> The problem is this: The program will not wait for this input. |> It seems to set up the current popup dialog, and then move on without |> waiting for the user to input the necessary information. |> |> If anyone has any code, or knows how to solve this dilema, I would |> appreciate it greatly. As far as I know, the only way to do this that isn't subject to some kind of problems in the future (i.e., isn't a hack) is to return to the main loop after managing the popup and do the rest of the work in the message box's OK callback. When you need to get any input from the user, the only way to do so is from a callback, and that means giving control back to Xt. This is the general nature of Xt, and is part of the puzzle you have to solve when writing Xt-based programs. Solving the puzzle usually means learning how to break up the program into small pieces joined by saved state. A really good example of this is the implementation of a "Save As..." menu item for saving a file that takes more than a second to save (such as a 640x480 16-bit TrueColor image in PPM format). This requires creating a file selection dialog, a "file exists" warning dialog, an "open failed" error dialog, and a "saving file" information dialog (and possibly a "save failed" dialog). Buttons on these dialogs are unmanaged as makes sense (e.g., the "saving file" dialog only needs a Cancel). The menu selection manages the file selection dialog and returns. The OK callback of this dialog checks to see if the file exists, and if so, manages the "file exists" dialog and returns. If not, or if the user says "OK", a routine is called to open the file. If there are any problems, the "open failed" dialog is managed and the routine returns. Otherwise, the code manages the "saving file" dialog, installs the file saving work procedure, and returns. For each call, the file saving work proc saves a small portion of the file (such as a raster in the aforementioned PPM file) and returns, giving the user a chance to hit the "Cancel" button on the dialog. The Cancel callback aborts the save and cleans up. During all of this, enough state must be saved so that the code can pick up where it left off without too much recalculation and redundancy. Oddly enough, assembly-language programmers have had to do this forever. Yes, this all seems like a lot of work, and if someone can show me a better way to do this that doesn't cause things like expose events and timeouts to get lost, I'd appreciate it. -- ...David Elliott ...dce@smsc.sony.com | ...!{uunet,mips}!sonyusa!dce ...(408)944-4073 ..."Art is never fair" - paa