Re: [foxboro] mouse loosing its focus.
- From: tom.vandewater@xxxxxxxxxxxxxx
- To: foxboro@xxxxxxxxxxxxx
- Date: Fri, 28 Mar 2003 13:15:55 -0500
"Con Obrien said:
Sounds like the 'motif' application problem... we've had the same thing
here. It occurs on dual-head WPs, and one theory is that it is more likely
to occur on stations where the alarm manager window is minimised - could
this apply in your case?
cheers,
Con
Frits,
I absolutely agree with Con. I have never heard the Dual Head WP
theory but that makes a lot of sense since that is virtually all we use.
The Motif application problem for us involves the Alarm Manager. We are
using the non-Motif "legacy" Fox DM in lieu of the Motif FoxView for our
operator interface but are forced to use the Motif Alarm Manager to view the
alarms coming to our dual headed workstations.
We started to have a myriad of problems such as cursor and keyboard
lock-ups when we upgraded to V6.2.1 and WP-51B,C,D's but didn't know why.
At the same time, we moved away from using the old CAD alarm screens on
dedicated WP-30's. We finally discovered enough from experience to write a
CAR which I am including below. The CAR was immediately closed out with the
old response to implement two workarounds that don't "SOLVE" the problem but
try to mask it as much as possible. Editting the ".Xdefaults" and modifying
the "Set Active Window" properties to "Move Pointer" do not keep the lockup
problem from occurring but make it less frequent. The "Set Active Window"
which makes the window focus follow the mouse is really annoying if you are
accustomed to working with multiple tiled windows, especially in the Openwin
environment where there is no taskbar to easily refocus a desired window.
It seems self evident to me that spending significant effort to actually fix
the problem in the Motif applications would be more effective than all of
the time users and Foxboro have spent trying to "WORKAROUND" the problem. I
find it arrogant on Foxboro's part to close out a CAR, without my
acceptance, if they are not providing a "SOLUTION" to the problem.
Some would say that this isn't a very serious problem but I can tell
you from experience that operating technicians that can't make a change to
their process because of this problem strongly disagree. I encourage all
users having this problem, even occasionally, to submit a CAR because it is
the users only documented way to show Foxboro that we think this issue is
still important. Otherwise they will assume that this problem isn't worth
working on if the users aren't willing to take the time to submit a CAR.
You are welcome to cut and paste the body of my CAR below in order to ease
the pain of writing up the same problem in your own words, but if you have
other interesting observations such as Con's above, please include them. I
know it seems useless, but since the users haven't submitted CAR's recently,
Foxboro may believe that the issue no longer exists.
Below is a list of other CAR's that have been closed that relate to
this issue. A few of them mention an actual solution is forthcoming in
releases that have already been released, but most of them say to use the
"old faithful" but ineffective workarounds mentioned above.
CAR # 1003752 Keyboard Lockups caused by Motif Apps
CAR #: 991254 FoxView loses mouse events
CAR #: 10671 When mouse is double clicked AMI hangs up AW
CAR #: 10566 The cursor could be moved around no actions could be picked
CAR #: 10491 Alarm History display locks up, loses keyboard and mouse
input
CAR #: 10456 Number of lock-ups have been greatly reduced, but not
elimated
CAR #: 10354 WP51 frozen when Current Alarm Page was on display
CAR #: 10303 AW51B cursor lockup after alarm manager is called up
CAR #: 10108 Instead of rebooting, kill the alarm manager
CAR #: 10023 Cursor moves but does not respond to "click" events
CAR #: 10004 Nothing could be selected using the mouse
CAR #: 9952 Possible to lock up the cursor from the Alarm Manager.
CAR #: 9822 WP51B1 locked up, one screen for ICC, other was at AM
CAR #: 9703 Killing the AM process, via remote login, clears situation.
CAR #: 9620 'Freeze' seems to occur when one calls up the alarm manager
CAR #: 9529 The problem is corrected in the 6.0 release. Quick fix
QF9529
CAR #: 9407 The problem is currently planned to be corrected as part of
V4.2.4
CAR #: 9276 Still updating but no actions from the mouse could be taken
CAR #: 8911 WP Alarm Manager appears to lock up
Thanks,
Tom VandeWater
CUSTOMER ACTION REQUEST #1003752
Submitted by:
Tom VandeWater
Dow Corning Corp.
Carrollton, KY
10/14/2002
Issue : Keyboard Lockups caused by Motif Apps
Problem description: At Ver. 6.2.1 keyboard entry into
Fox Display Manager windows running on AW/WP-51B, C, or
D style boxes occasionally ceases to function giving the
appearance of a faulty keyboard. Replacing the keyboard
does not resolve the problem. Rebooting the Sun
workstation, (AW/WP), does resolve the problem and was
our only known way to make the keyboard work again.
After repeatedly experiencing keyboard lockup problems on
the local CRT's of the Sun Workstations, we started using
remote DM's called up on PC's running Windows 2000 and
Hummingbird Exceed. The PC's experienced the same
keyboard lockups as the AW/WP's but only on the Fox DM
window. The PC keyboard continued to work in other
Windows applications. We have now discovered that if we
close out, or dismiss, the Alarm Manager window associated
with the Fox DM, the keyboard will begin to function properly
again.
This led us to the conclusion that the Alarm Manager window
somehow captures or locks up the keyboard function as far
as the Fox DM is concerned. Dismissing the Alarm Manager
releases the keyboard to be used by the DM. Calling up the
Alarm Manager window doesn't always cause the keyboard
to quit functioning in the Fox DM window. There must be
some scenario or sequence of events that causes the
keyboard lockup to begin! Although we haven't pinned down
the exact sequence of events that cause the lockup, we are
convinced that there is a problem with the Alarm Manager
application, which, by the way, is displayed in a Motif
window!! I don't know the difference between a Motif and a
standard X-window used by the Fox DM, but I have heard
that it makes a difference to Solaris. Foxboro has blamed the
Sun OS for the cursor lockup problem, which I believe, is part
of the same problem.
We have 10 dual headed WP-51's in our Central Control Room
that use the Alarm Manager for monitoring process alarms.
Each one is adjacent to a dual headed PC that calls up remote
DM's from its WP partner. The PC's also use the Alarm
Manager. We have seen the keyboard on the local SUN WP
continue to function in its DM window while the keyboard on
the PC calling a remote DM from that same WP ceased to
function in the PC DM window.
We have 13 AW's where the DM's are used extensively both
local and remote but don't use the Alarm Manager
application. They do not experience keyboard lockups
anymore, but we had a few that were used as process
alarming stations in the past and locked up when the Alarm
Manager application was used on them! There is no doubt in
our mind what is the root cause of the keyboard lock ups. It
is the Alarm Manager!!
We don't know if this same problem exists when using
instances of Foxview instead of Display Managers because
we don't use Foxview, which I'm told is a Motif application.
We do know that we can work around the problem by
closing or dismissing the Alarm Manager application on the
affected workstation whether it is a PC or a Sun box.
For your information, the default Alarm Managers on the local
Sun workstation are configured in
the /usr/fox/customer/hi/dmcfg file as: Operator
which is un-quittable. As such, they cannot be dismissed. To
make them quittable go to the AMNAME section of the dmcfg
file, as shown below and set them to RemoteOperator. The
WP/AW must be rebooted for the changes to take effect.
#---------------------------------------------------------
# AMNAME
#---------------------------------------------------------
AMNAME 01AW01 01AW01 -
RemoteOperator
AMNAME " 01A011
- "
AMNAME " 01A012
- "
AMNAME " 01A013
- "
AMNAME " 01A014
- "
Work Around: If you cannot type in values or
passwords in a Foxboro Display Manager Window and it
looks as if you have a faulty keyboard, call up the Alarm
Manager window associated with that DM and pick "FILE"
and then "DISMISS". If you get a Message "Alarm Manager
Application Un-Quittable" you either haven't edited the dmcfg
file mentioned above or haven't rebooted the AW/WP since
modifying the dmcfg file. When the Alarm Manager exits
return to the DM and try again to type in values. This problem
has been around since the inception of the "MOTIF" Alarm
Manager and it is high time that Foxboro addresses the issue.
Response:
Oct 14, 2002 (TC) - Response from TAC:
Problem Workaround:
This problem is related to Motif applications such as Foxdraw, Foxview
,Alarm
Manager, and Alarm Configuration Tools on Solaris. Two problems have been
discovered which can cause the OpenLook window
manager to " hang" . When the window manager is hung, all mouse clicks and
keyboard inputs are ignored until the offending application is killed or the
machine is rebooted.
Problem #1 Workaround
The workaround for this problem is to edit the file " /.Xdefaults
1. Open a VT100 window.
2. Change directory to the root directory . cd /
3. Edit the /.Xdefaults file to include (or modify) the following two
lines
exactly as they appear here (be careful about the
underscores and upper/lower case letters). (Note: the "."
character makes this file invisible to an "ls" command ).
4. vi .Xdefaults
5. Make edits such that the following lines appear exactly as they do
below:
olwm.Modifier.WMGrab:
olwm.Modifier.Ignore: mod5,Alt,Num_Lock,Mode_switch,Lock
6. After completing the edits, reboot the workstation.
Problem #2 workaround
The second defect is related to handling of rapid mouse clicks by the
window
manager and can be avoided entirely by setting the window focus property to
"move pointer" as follows:
1. From the Workspace menu (click the right mouse button with the mouse
cursor on the blue "background" screen), and select "properties...".
2. On the resulting "Workspace Properties" dialog, click on the
"Category"
icon and select "Miscellaneous" from the drop-down menu.
3. On the "Miscellaneous" page, under "Set Active Window" , click the
"Move
Pointer" button.
4. Select the "Apply" button at the bottom of the dialog box to apply
the
change.
5. Click on the "pushpin" in the upper left corner of the dialog to
dismiss
the dialog.
This CAR is now closed.
CAR # : 1003752 Version :
Status :
CLOSED
________________________________________________________________________
This email has been scanned for all viruses by the MessageLabs SkyScan
service. For more information on a proactive anti-virus service working
around the clock, around the globe, visit http://www.messagelabs.com
________________________________________________________________________
_______________________________________________________________________
This mailing list is neither sponsored nor endorsed by Invensys Process
Systems (formerly The Foxboro Company). Use the info you obtain here at
your own risks. Read http://www.thecassandraproject.org/disclaimer.html
foxboro mailing list: //www.freelists.org/list/foxboro
to subscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
Other related posts:
