kxgj@vax5.cit.cornell.edu (06/10/91)
I'm having a problem with updating windows in Intuition and would appreciate
comments/help that anyone could give me.
Brief Summary (for those that wish not to read the [lengthy] description that
follows): I have a multi-windowed screen in which I move and resize one of
the windows in the code (no gadgets). Graphic writes to the window do not
behave consistently, even though I use system calls. I've fixed the problem
with extensive MakeScreen's and RethinkDisplay's but this seems like it should
not be necessary. Specific questions follow.
Full description: I'v opened a 640x200 screen and put in 5 windows (no overlap
and no titlebar or system gadgets (CLOSEWINDOW,...) so they are just 1 pixel
outlines. In 2 of the windows, I've put 9 of my own (BOOLEAN) gadgets. They
work well. One of the windows is a display window that I wish to allow to be
full screen (covering the other windows) once the user has everything set up.
I currently accomplish this by MoveWindow* (to upper left), SizeWindow* (to
full [or on return to small] size), WindowToFront*, SetRast*, RedrawWindowFrame*
(I think that name is right) and then do a few of my own GraphicCalls (the
asterisks indicate system Intuition calls). Many times this procedure works
and all is well. However, on too many other times, I do not get what I
expect. Typically, part of the graphics in GraphicCalls (my own...) are
drawn as if the window had not been resized yet. It is not consistent in that
sometimes all of the graphic calls are sized incorrectly, sometimes part and
at others, all are correct. I've stabilized the behavior by adding MakeScreen*
and RethinkDisplay* after each of the system calls above but I don't think that
this should be necessary. I am using SAS 5.10 and tried to figure it out
using the debugger, cpr. However, I could not make it mess up by stepping
through the program (without the MakeScreen...). This makes me think that
the problem is one of timing--the code processes all of the calls and the
system at times ends up acting on later calls before the earlier ones (this
would be a bit bizarre, I agree) finish. By stepping through the program
I allow things to get finished before the next part starts (I have tried to
make it mess up by setting one breakpoint in the code and looping through
the resize functions back and forth but it didn't mess up either). Am I way
off base here?
My specific questions:
1. What is causing the problem and are the MakeScreens and RethinkDisplays
the appropriate fix? If so, does this imply that I should do them
after each system call such as these?
2. Is there a better way to approach the window resizing function that
I want?
3. What is the best refresh flag to set for the window(s) in this
situation? I think I am using SMARTREFRESH (oh, for a memory that
worked...).
One unrelated question--I've just started using the workbench interface for
SAS c (I always used the CLI before..) and can't seem to get the debugger to
function from the workbench. It originally couldn't find the source so I
added the path/filename to the TOOLS part of debug.info and now it gets to
where it says 'Loading executable' and hangs. When I run it from the cli
with cpr filename, I have no problem. Any ideas?
Other info-- I like to RTFMs and have read TFMs but they are dated (they are
the 1.2 white LIBRARY and INTUITION books, as well as other noncommodore
ones--Peck, Mortimore...) and I get no other info (like developers docs, etc..).
If I need to reread a section, I do not mind being told to do so...
anyway, I would prefer an E-Mail response (kxgj@vax5.cit.cornell.edu) but
will cruise this group for a week or so to see if any kind soul has taken up
my problem.
Kirkforgeas@swinjm.UUCP (Jean-Michel Forgeas) (06/13/91)
In article <1991Jun10.092301.5350@vax5.cit.cornell.edu>, kxgj@vax5.cit.cornell.edu writes: > [...]I currently accomplish this by MoveWindow* (to upper left), SizeWindow* (to > full [or on return to small] size), WindowToFront*, SetRast*, RedrawWindowFrame* Guess that MoveWindow* and SizeWindow* would have a chance to execute faster if you WindowToFront* before them (because of layers). > [...]expect. Typically, part of the graphics in GraphicCalls (my own...) are > drawn as if the window had not been resized yet. It is not consistent in that > sometimes all of the graphic calls are sized incorrectly, sometimes part and > at others, all are correct. I've stabilized the behavior by adding MakeScreen* > and RethinkDisplay* after each of the system calls above but I don't think that > this should be necessary. [...] > > My specific questions: > 1. What is causing the problem and are the MakeScreens and RethinkDisplays > the appropriate fix? If so, does this imply that I should do them > after each system call such as these? All you have with these two calls is time, doing some Delay() could act as well: Intuition get enough time to resize the window before your draw into it. > 2. Is there a better way to approach the window resizing function that > I want? The SizeWindow() call does not resize your window but tells Intuition to resize it. See the autodocs: "Note that the Window will not be sized immediately" You could do this way: - SizeWindow(), - Wait() or WaitPort() for the NEWSIZE message class from Intuition, - draw into the window with graphic calls. > 3. What is the best refresh flag to set for the window(s) in this > situation? I think I am using SMARTREFRESH (oh, for a memory that > worked...). As a user my preference is that you set SMARTREFRESH. I don't like when redrawing windows take too much time :-) > Kirk -- \___/ Jean-Michel Forgeas \-/ cbmvax!cbmehq!cbmfra!swinjm!forgeas | The Software Winery -^- And, where is the universe ?