[comp.lang.smalltalk] Problems with ST80-2.5 StandardSystemView window cache

csq031@umaxc.weeg.uiowa.edu (05/04/91)

This was a real ball-buster, and came right before a public demonstration.

Another guy in my group was trying to put together a demo of our program, and
noticed that the main view for our application was showing bogus information
after he did something to change the application's state.  The setup is this.


+-----------------+           +---------------+
| Main Window     |           | Window with   |
|                 |           | a Button in it|
+-----------------+           +---------------+


In the program, you click on a button in one window (the window with the
button in it) and it modifies objects that have sub-windows opened on them
in the main window.

I played with it for several hours, setting break points in the code updating
the subwindows of the main window, but the updates did the right thing.
Where the problem came was some time after the update occurred, when the main
window decides to refresh itself from an obsolete bitmap.  Old information
was getting copied on top of the new information we just posted!

The problem goes away if you do a 

StandardSystemView leaveHoles.

but then you get irritating redraws all the time.

If you activate the same set of operations with a button on the Main
window, the problem goes away.

If you turn off caching for just the main StandardSystemView, you
still have the problem.

Incidentally, both the main window and the button window are
StandardSystemViews, or a simple-minded subclass thereof.

Questions

1. Am I nuts?  

2. When you open a StandardSystemView with the intent
of filling it with subviews, what are you supposed to use as a model?

3. What governs when changing a subview invalidates the cached bitmap?
It seems as though only the subviews (who are all subclasses of view)
we've drawn graphics on are overwritten with out of date information.

4. What is the proper way to coordinate a subview that is
non-interactive -- they need to change when the model changes, but
they don't need menus or mouse interaction?


My cheap-suit assessment of Smalltalk-80 after wrestling with it for 8
months is that the language is great, but the windowing, graphics, and
scheduling stuff is very difficult to get right.  If you don't believe
me, try forking a process and having it do anything useful!
--
             Kent Williams --- williams@umaxc.weeg.uiowa.edu 
"'Is this heaven?' --- 'No, this is Iowa'" - from the movie "Field of Dreams"
"This isn't heaven, ... this is Cleveland" - Harry Allard, in "The Stupids Die"

ags@scs.carleton.ca (Alexander George Morison Smith) (05/04/91)

In article <5873@ns-mx.uiowa.edu> williams@herky.cs.edu () writes:
>Another guy in my group was trying to put together a demo of our program, and
>noticed that the main view for our application was showing bogus information
>after he did something to change the application's state.

The old window refresh problem! Just use the displaySafe: [aBlock]
method in your update code.  When a view is sent the displaySafe:
message, it moves its window temporarily to the front, does the drawing
by executing your code in the block, caches the new bitmap and moves it
back to the background, leaving the previous front window in front.  Not
pretty and not fast but it does work. 

- Alex