focke@gmdzi.UUCP (Stefan Focke) (02/01/90)
If your Formdial is the same like mine it works like this: Formdial increases the speed of closing dialoges. If you open a dialog- box Formdial saves the screen in memory. If you close the dialog, it restores the screen. The application needs no time to redraw the window under the dialogbox. Stefan Focke
obryan@gumby.cc.wmich.edu (Mark O'Bryan) (02/03/90)
In article <6157@eagle.wesleyan.edu> ncastellano@eagle.wesleyan.edu writes: > > What does the program FORMDIAL from the archives do? The index says it speeds > up dialog boxes, but I got it and unarchived it, and it contains no > documentation, and doesn't seem to affect system performance, and doesn't > display any messages or anything, just exits. Programs like that make me > nervous. I agree that the documentation for FormDial is minimal, or non-existent. Which is unfortunate, since it's an interesting idea. What it does is to speed up screen redraws (make them instaneously, actually) after you CLOSE a dialog box. It does this by reserving a 32 kB chunk of memory (and you thought it took only 500 bytes!), where it saves a portion of the screen during a formdial (reserve, ...) call which preceeds a dialog box draw. Then it intercepts the formdial (free,...) call and blits the image back when the dialog exits, avoiding the redraw. The reason it displays no messages is that it's intended to be run from the AUTO folder. If you don't know that, I can see why you'd be nervous. Ac- tually, you should be nervous of *any* program of doubtful parentage, with no documentation! If your dialogs commonly cover fairly small, or simple areas, you may not notice the speedup very much. If they tend to cover very large, or complex areas that takes lots of time to redraw, you will notice it. But you might not attribute it to FormDial, unless you know that is what it's for. Most programs work OK with FormDial, but some don't and will hang, probably because they got sloppy and don't balance their calls to formdial properly (just my guess). Whether it's worthwhile for you will depend on how tight memory space is, and if you ever run ill-behaved programs that cause it to hang. -- Mark T. O'Bryan Internet: obryan@gumby.cc.wmich.edu Western Michigan University Kalamazoo, MI 49008
obryan@gumby.cc.wmich.edu (Mark O'Bryan) (02/03/90)
In article <20359@watdragon.waterloo.edu> swklassen@tiger.waterloo.edu (Steven W. Klassen) writes: > > I found that FORMDIAL did indeed increase the speed that dialog boxes were > drawn at. (A performance benchmark program told me this.) I also Nope, not actually the dialog box draws. They're done at the same speed as usual. It's the *redraws* when the dialog boxes are closed that get sped up. By a lot. I scratched my head over this a while myself, since QuickIndex indicated that dialogs were running almost TWICE as fast. I watched REAL close, but couldn't see any difference at all in how fast they were drawn. Then I noticed how fast they were closed. Bingo. See my previous posting for other comments. -- Mark T. O'Bryan Internet: obryan@gumby.cc.wmich.edu Western Michigan University Kalamazoo, MI 49008
pegram@uvm-gen.UUCP (pegram r) (02/15/90)
From article <1990Feb3.070418.13493@gumby.cc.wmich.edu>, by obryan@gumby.cc.wmich.edu (Mark O'Bryan): Useful explanation deleted here (saying that formdial saves the screen behind a dialog box, eliminating slow redraws when dialog box is removed). > Most programs work OK with FormDial, but some don't and will hang, probably ^^^^^^^^^^^ UIS III also eliminates screen redraws when it disappears using the same idea. However, the feature is optional because - as the manual points out - some programs are written badly and *depend* upon the call to redraw the screen to realize that the "dialog" is over. Time Works Publisher ST is mentioned specifically, and some others that I forget. I expect that this is the bug that hangs programs with formdial. If this is what you meant by not balancing calls, it wasn't very clear. On a related note, what *is* the proper procedure in calling and returning from dialogs - one that doesn't check for a screen redraw? > because they got sloppy and don't balance their calls to formdial properly > (just my guess). Whether it's worthwhile for you will depend on how tight > memory space is, and if you ever run ill-behaved programs that cause it > to hang. > > -- > Mark T. O'Bryan Internet: obryan@gumby.cc.wmich.edu > Western Michigan University > Kalamazoo, MI 49008 Bob Pegram (pegram@griffin.uvm.edu) Univ. of Vt. Burlington, VT.
barry@gpu.utcs.utoronto.ca (Barry Lay) (02/16/90)
There is an example of handling dialogs in Tim Oren's ProGem series. If you the form_do() in a loop awaiting the proper "exit" button, then wrap it in calls to form_draw() (is that the right call?), you shouldn't have a problem. As I recall, the form_draw() routine takes a numeric parameter which indicates its function. Zero allocates a screen area (whatever that means), one animates the zoom out, two animates the zoom in, and three releases the screen area, causing the redraw messages. Mr. Oren points out that calling form_draw() with a function code of three and the coordinates of the desktop will cause redraws to be sent for all windows; that is, there is no "balancing" required. I don't understand why you have to wait for the redraw to carry on. If your program handles messages as they arrive, this shouldn't be an issue. Barry Lay University of Toronto
klute@heike.informatik.uni-dortmund.de (Rainer Klute) (02/16/90)
In article <1990Feb15.161106.17781@gpu.utcs.utoronto.ca> barry@gpu.utcs.utoronto.ca (Barry Lay) writes: >... Mr. Oren points out that calling form_draw() with ^ Obviously form_dial() is meant here. ----| >a function code of three and the coordinates of the desktop will cause redraws >to be sent for all windows; that is, there is no "balancing" required. I don't >understand why you have to wait for the redraw to carry on. If your program >handles messages as they arrive, this shouldn't be an issue. The problem is the "if" in the last sentence. Some badly programmed applications do not send their output to some window but simply put it on the screen. They will not look for WM_REDRAW messages and thus will not process any of them. (I am not quite sure whether a form_dial (3, ...) causes the screen manager to send a WM_REDRAW to the window with handle 0 (the screen) but if the application does not care for WM_REDRAW messages that would not make any difference.) Dipl.-Inform. Rainer Klute klute@heike.informatik.uni-dortmund.de Univ. Dortmund, IRB klute@unido.uucp, klute@unido.bitnet Postfach 500500 |)|/ ...uunet!mcvax!unido!klute D-4600 Dortmund 50 |\|\ Tel.: +49 231 755-4663
saj@chinet.chi.il.us (Stephen Jacobs) (02/17/90)
I didn't follow right away, but now maybe I understand. It's the nature of
dialog boxes that the program state is different after using one. Sometimes
the state is unstable (perhaps there's a new working copy of a string which
needs to be validated and moved to the permanent string). Sometimes the
display needs to be changed (consider choosing different display sizes in a
page layout program). It's very tempting to assume that these functions will
only be needed after a redraw is requested at the end of a dialog. If FORMDIAL
suppresses that, and if those functions are folded into the redraw code,
confusion would result. The problem is one that becomes acute in multitasking:
anything may change under you without notice, at any time.
Steve J.barry@gpu.utcs.utoronto.ca (Barry Lay) (02/19/90)
[remarks about my remarks about forms handling ... ] You are right; I meant form_dial(). The application will not receive a WM_REDRAW message for handle 0 (desktop). For this reason I usually open a window which covers the entire desktop work area when I am "drawing directly on the desktop". Since there is only one window, and it doesn't have any sliders, movers, or other such nasty stuff, it isn't very difficult to deal with. The only way I can think of to intercept the desktop redraw is to create your own desktop object and declare it via wind_set(WF_NEWTOP, ... ). I can't say that I have ever tried this, but I suspect that it would be more difficult than opening a big window. Barry