From: nagle@netcom.com (John Nagle)
Newsgroups: comp.lang.smalltalk
Subject: Smalltalk/V Mac problems and solutions
Summary: A few minor problems
Keywords: bugs Smalltalk V/Mac
Date: 10 Nov 92 18:34:02 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest)


      Here are a few defects I've discovered in Smalltalk V/Mac over the
last few weeks.

      1.  GraphPane's approach to screen redrawing is decidely wierd.
	  Each GraphPane has a backing Form which is used to redraw the
	  screen on window damage.  But the backing Form isn't written
          unless the user explicitly creates a Pen and writes into it,
	  independent of writing to the display.  So the user has to
	  draw everything twice.  The manual doesn't tell you this.

          Worse, the backing Form is by default sized to the size of the
          display (not the window), but the scroll bars aren't adjusted to
          match.  So you can scroll off the area that has backing storage,
          in which case a redraw will lose part or all of the window 
          contents.

          Finally, the backing Form is only one bit deep.  You can draw in
          color, but redraw will be black-and-white!

          I recommend against using GraphPane for any serious work.
          Try DrawPane, which doesn't have a backing Form but lets you
          capture redraw events.  You have to do your own redrawing, as
          with most Mac applications.

      2.  If you're doing your own redrawing, and are thus between Mac
          BeginUpdate and EndUpdate brackets, and something happens with
          invokes the debugger, the debugger opens a window but doesn't
          properly prevent further window-damage events from being
          processed. The result tends to be that a debugging window pops
          up, followed by another debugging window on top of that, 
          repeated until memory runs out.  (If you do "quit" from the
          "File" menu, you can escape memory-full death).  Bad
          debugger behavior; it's the responsibility of a debugger to
          deal properly with being invoked at difficult moments.

      3.  "Pen"'s "centerText" doesn't clip at pane (not window) boundaries.
          This is a simple bug in "centerText"; it creates a new 
          CharacterScanner but doesn't "clipRect:" to it.  Easy to fix.

      4.  The approach to waiting for the mouse to go back up used in
          the sample program "FreeDrawing" is unsound and loses mouse
          clicks, because it's checking the wrong end of the event
          queue.  Use the approach in "ListPane" and your results will
          be better.  In general, "FreeDrawing" is not a good model to
          learn from; it does a number of minor things wrong.

Had a talk with Digitalk tech support.  Turns out they don't sell much
Mac product, so that's why the Mac interface issues are not well-handled.

An aside:
Have you noticed lately that most products available for both the Mac
and DOS/Windows/OS2 platforms are in better shape on the other platforms?
I've had this experience with Word Perfect, Protel, Smalltalk/V,
and Managing Your Money.  I get the feeling that the Mac is becoming
a niche machine for graphic artists, despite all those PowerBook sales.

					John Nagle
Newsgroups: comp.lang.smalltalk