From: cgwong@faraday.physics.utoronto.ca (Clint Wong)
Subject: Problem with WireService/Jot/Cut Key
Originator: cgwong@faraday
Reply-To: morgan@jts.com
Organization: Dept. of Physics, Univ. of Toronto
Date: Wed, 29 Jul 1992 18:00:15 GMT

I am currently having a problem with using Jot that perhaps
someone could shed some light on for me.  In a very small
nutshell, the problem is that when the Cut Key is pressed inside
a ClassJotCanvas subclass, the operation works but each step
generates an 'input queue lock broken message'.
 
The System:
===========
 
SunOS 4.1.2, OW3, TNT
wire.ps is overridden in a custom package, but I'm not getting
any problems with the //Temp dict used by wire_Sync which
indicate that conflicting versions of wire.ps are being used.
The changes to wire.ps allow configurable timeouts and allow
executable procedures to be uploaded to the server.
 
The Program:
============
 
I have a C-side client which provides Jot services to any number
of unrelated processes on the NeWS side.  To achieve this, I've
registered tags on the same wire that I used to initialize the
Jot library.
 
On the NeWS side, there is an instance of ClassWireClient
(subclassed as ClassJotClient) which acts as the interface to the
client.  This object is accessed (indirectly) via /shareddict.
The operation of this object is limited to wrapping up the
arguments of the callbacks and calling /wire_callbackclient.
 
There is a subclass of ClassJotCanvas which takes care of setting
up the necessary stuff in the C-side client, via calls to my
ClassJotClient.
 
The significance of this design is where the instance of
ClassJotCanvas executes.  In Jed, the ClassJotCanvas instance is
created (and executes) in the process started from the connection
to the NeWS server --- it is my understanding that this process
is the 'Listener Process'.  In my application, the instance of
ClassJotCanvas is created (and executes) in a process started
from a different C-side client, i.e., it does NOT execute in the
'Listener Process' for the Jot C-side.  This is significant to
/wire_Sync which uses different methods of syncing the wire
depending on whether the caller is executing in the Listener
Process.
 
The Problem:
============
 
Everything seems to work wonderfully with multiple jot canvases
being run (pseudo-) simultaneously ... until you press the Cut
Key.
 
When the Cut Key is pressed, there is a delay, followed by an
'input queue lock broken' message, followed by a delay, and
finally the text is cut.
 
Following is some trace output of what I am seeing.  Comments in
double angle brackets are what I do/see.  Comments in double
square brackets explain the trace output.
 
============================================================
 
Entering notifier               [[ about to call wire_Notify(NULL) ]]
 
<< hit Cut key >> 
 
-ClassJotText: send tag = CONTENTS, args = 35 0 0 
Exiting notifier                [[ wire_Notify() returns ]]
Notified 0                      [[ 0 means wire_InSync() returns false ]]
Entering notifier
Exiting notifier
Notified 0
Updating Views                  [[ about to call Jot_UpdateViews() if needed ]]
Views Updated                   [[ after Jot_UpdateViews ]]
Entering notifier
Wire: returns the
 
<< pause >>
 
xnews: Warning: input queue lock broken!
-ClassJotText: send tag = CONTENTS, args = 35 0 1 
Exiting notifier
Notified 0
Entering notifier
Exiting notifier
Notified 0
Updating Views
Views Updated
Entering notifier
Wire: returns {\rtf1\ansi\deff0{\fonttbl{\f0\froman LucidaSans;}}{\colortbl\red0\green0\blue0;
\red255\green255\blue255;}the}
 
<< pause >>
 
-ClassJotText: send tag = DELETESELECTION, args = 35 0 
Exiting notifier
Notified 0
Updating Views
Views Updated
Entering notifier
 
<< text is removed from view >>
 
============================================================
 
I have also seen where the pauses occur after the tag is sent,
i.e.,
 
Enter Notifier
-ClassJotText: send tag = CONTENTS, args = 35 0 0
<< pause >>
Exit Notifier
 
If, rather than hitting the Cut Key, I select the text to be cut,
go to a PSH and execute:
 
        nullevent /selectioncut ClassUI send
 
every thing works fine.
 
Any help or insight into this problem would be greatly appreciated.
 
Morgan Jones    -    morgan@jts.com
JTS Computer Systems Ltd., Toronto, Canada
 

Newsgroups: comp.windows.news