[comp.windows.news] liteitem bug

conrad@jupiter.ucsc.edu (Al Conrad, x2370) (04/07/89)

The following code demonstrates some kind of race condition that
comes up when you use getanimated after typing text into a text
item.  Just psh the following, type some text into the text box,
click OK, and then get a rubber band line.  You'll notice that
after the first rubber band line click the line disappears every
time you stop moving the cursor.  Somewhere, somebody is doing
an erasepage in the overlay canvas, but commenting out the
erasepage in litetext.ps doesn't help?!

----------------------------------------------------------------

systemdict /Item known not { (NeWS/liteitem.ps) run } if

/overlay framebuffer createoverlay def
/PromptBox {

   /CANCELResponce {
        can /Mapped false put                 %get rid of canvas
        p killprocess                         %kill dialog process
   } def


   /OKResponce {
	/getvalue items /responce get send 
        can /Mapped false put                 %get rid of canvas
        p killprocess                         %kill dialog process
   } def

	%create canvass for the dialog box
	/itembackground .75 def
	/can framebuffer 240 150 createcanvas def
	can setcanvas 400 100 movecanvas currentcanvas mapcanvas
	itembackground fillcanvas 0 strokecanvas

   /items 10 dict dup begin
	%items is the dictionary of liteitems that make up the dialog
	/CancelButton
           (CANCEL) /CANCELResponce can 100 0 /new ButtonItem send def
           130 30 /move CancelButton send

	/OKButton
           (OK) /OKResponce can 100 0 /new ButtonItem send def
           10 30 /move OKButton send
	
    	/responce (>)  () /Right {} can 220 0
        	/new TextItem send
		10 100 /move 3 index send def

   end def
   items paintitems
   /p items forkitems def
   p
} def

	PromptBox waitprocess

overlay setcanvas
0 0 {} getanimated
waitprocess aload pop    % wait for first click
{ lineto } getanimated
waitprocess aload pop    % wait for second click