CLIM mail archive

[Prev][Next][Index][Thread]

weird top-level accept problem for application frames



In my application frame I somethings get caught in a weird recursive type
accept problem.  Unfortunately, I haven't been able to reproduce this
problem with a small example so let me describe the symptom.  It may be
related to me trying to type ahead to another command before the command
already executing is done.  It seems that somehow the top-level accept loop in
the application frame sometimes starts in a deeper recursive call on accept
when you enter top level commands for the application.  It shows up after
some commands have already been entered and executed on the application. 

Afterwards when I try and type in another application command as you type in
the characters (including trying to do completion via the space bar) the cursor
all of a sudden moves to another line in my interactor pane and continues to
echo out the characters of the command.  Only the accept now thinks that those
characters entered on the new line are the beginning of a new command (from
this point on the top-level accept loop in the application frame is screwed
for keyboard input).  So, if I try and rubout those characters I randomly get beeped and it ignores the rubout.  However, if I do positioning of the cursor ala control characters the cursor sometimes jumps up to the original line
and starts editing on that character string.   From that point on the cursor
randomly jumps back and forth between the two lines and never lets me
successfully remove all of the characters in both lines.

If I abort out of entering the command, from that point on the top-level
accept will continually fail to accept my commands via the keyboard.  Menu
commands are still available and will echo correctly in the interactor pane,
but any keying in of commands will now fail as described above.
The only way for me to recover is to blow out the application frame and
re-instantiate a whole new one.

Another weird symptom is sometimes my interactor pane will lose the ability
to echo characters out (including the command prompt) (I think the ink
has somehow been flipped because I notice the cursor moving).  I am on a
monochrome SPARC system with CLIM 1.0.

I do to two things different from your normal execution of an application
frame.  First, I have a simple around method on execute-frame-command (below)
that echos the command done out to another application pane for my own history
if it is just a top level command, otherwise I massage the last form "evaled"
from the command's execution (which may be a totally different command).  This
I check works and shouldn't impact the command accept loop.

(defmethod execute-frame-command :around ((SELF Plan-IT-2) command)
  (with-slots (Action-Pane Scripts) SELF
     (let ((strg (call-next-method SELF command)))
       (when strg
	 (add-output-record Action-Pane
		(with-output-as-presentation
		 (:stream Action-Pane :object (cond ((listp strg) (car strg)) 
						    (t command)) :type 'command
				 :single-box t :allow-sensitive-inferiors nil)
	   (format Action-Pane "~&~d) ~a" (Scripts-Count Scripts)`
		   (cond ((listp strg) (cdr strg)) (t strg)))))
	 (incf (Scripts-Count Scripts))))))

The other unique thing I do is I start my application frame with a
process-run-function call to a function that checks to see if the application is not up yet and if so execute a run-frame-top-level to the application
instance.  Could there be some weird synchronization problems if you start
an application from a separate process?

1)  Has anybody had a similar problem?

2)  Is there a way I can force my top-level accept loop to clear its buffer
(totally) or get it back to normal without having to restart my application
frame from scratch?



Main Index | Thread Index