[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference bulova::decw_jan-89_to_nov-90

Title:DECWINDOWS 26-JAN-89 to 29-NOV-90
Notice:See 1639.0 for VMS V5.3 kit; 2043.0 for 5.4 IFT kit
Moderator:STAR::VATNE
Created:Mon Oct 30 1989
Last Modified:Mon Dec 31 1990
Last Successful Update:Fri Jun 06 1997
Number of topics:3726
Total number of notes:19516

3111.0. "SoftPC Icon Problem" by WRKSYS::GOLDBERG (Marshall R. Goldberg, Workstations) Fri Jul 20 1990 17:03

    
    Here is a problem sent to us by Insignia Solutions. I would produce
    a QAR on it, but am not sure if their technique is correct. Can
    someone comment on this note?
    
    Greatly appreciated,
    
    Marshall
    
    
To:	Phil Bousfield (Insignia Solutions)
From:	Jim Hatfield (Insignia Solutions)
Date:	Thu, Jul 12, 1990

Subject: SoftPC Problem on Digital Platforms

Iconisation Bug:

SoftPC has a number of windows associated with it (the UIF panels are each 
windows) but usually only one or two are visible at once. The others still 
exist though; the visible ones are "mapped" and the invisible ones "unmapped"
in X-speak. You can draw to an unmapped window but the X server will usually 
throw all your data away. You cannot, however, set the keyboard focus to an 
unmapped window - that's a big no-no and attempting to do this (by calling 
XSetInputFocus) generates an X error which terminates the calling process.

SoftPC's icon is a window, created by DECWindows. Either it is mapped, or the 
SoftPC window is, but not both. When you iconise, the SoftPC window is 
unmapped and the icon window mapped. When you deiconise the reverse happens.

If the SoftPC window has the keyboard focus at the time it gets unmapped, it 
loses the focus. The X server does this. However when the window is mapped 
again it is not automatically given the focus by the server. However DECWindows 
does do this for you (it is an optional setting which can be turned off). The 
actual call of XSetInputFocus is made from within SoftPC, but not by our code -
it must be from the DECWindows Toolkit libraries.

What happens is that the user de-iconifies the SoftPC window then immediately 
re-iconifies it again. By the time the DECWindows Toolkit has reacted to the 
MapNotify event (which you get when you become mapped) and called 
XSetInputFocus, the window has already been unmapped again, hence the  
X error. The root cause is that the map/unmap is being done by the DECWindows
Window Manager, while the call to XSetInputFocus is being done by the 
DECWindows Toolkit library in SoftPC - ie two asynchronous processes are 
involved and a race condition occurs. I would not be surprised if it didn't 
happen with other applications.


T.RTitleUserPersonal
Name
DateLines
3111.1How to reproduce the BugWRKSYS::GOLDBERGMarshall R. Goldberg, WorkstationsMon Jul 23 1990 13:5478
    
    Here is reliable way Jeff Nelson discovered that shows, what we believe
    is, the icon bug.
    
    Marshall
    
From:	TLE::JNELSON "Jeff E. Nelson  19-Jul-1990 1325" 19-JUL-1990 13:31:48.14
To:	wrksys::woods
CC:	JNELSON
Subj:	SoftPC X protocol error and another way to reproduce non-repeating keys

Platform: RISC/Ultrix V4.0, DECwindows session manager

SoftPC:   dka300:[apps.ultrix.version2risc]spc_july3.40 (For Ultrix 4.0)

Invoking: Either from an entry in the Session Manager Applications menu or from
	a DECterm

~/.SoftPC:
	HARD_DISK_FILENAME              /usr/lib/SoftPC/hard_disk
	HARD_DISK_FILENAME2
	FLOPPY_DEVICE           /dev/PC_floppy
	GRAPHICS_ADAPTOR                VGA
	FILE_DEFAULT_VALUE                      /tmp/dosprt
	PRINTER_DEFAULT_VALUE                   /dev/doslp
	PLOTTER_DEFAULT_VALUE                   /dev/dosplt
	PIPE_DEFAULT_VALUE                      |lp -or
	DATACOMM_DEFAULT_VALUE                  /dev/dostty
	COM_PORT_1_TYPE
	COM_PORT_2_TYPE
	COM_PORT_1
	COM_PORT_2
	LPT_PORT_1
	LPT_PORT_2
	LPT_PORT_1_TYPE
	LPT_PORT_2_TYPE
	FSA_DIRECTORY                   /usr/users/jnelson/softpc
	EXPANDED_MEMORY_SIZE            0
	MEMORY_LIMIT            640
	SLAVEPC_PORT            /dev/slavepc
	AUTO_FREEZE             0

---------------
Note that, in an attempt to search for hidden, unsupported features, I modified
the GRAPHICS_ADAPTOR value to VGA.  :-)  That's the only change I made to the
otherwise default .SoftPC file.  This must be done in order to reproduce the
error.

Reproduce by:
	Start SoftPC.

	A dialog box appears informing you that the value for the graphics
	adaptor is bad and that SoftPC is changing the value to CGA.

	Click on "Continue" and then shrink the SoftPC window to an icon.
	(If you don't shrink to an icon, the error does not occur and SoftPC
	starts normally.)

	The following X protocol error occurs:

X Protocol error detected by server:  BadMatch - parameter mismatch
  Failed request major op code 42 (X_SetInputFocus)
  Failed request minor op code 0 (if applicable)
  ResourceID 0xd0000c in failed request (if applicable)
  Serial number of failed request 656
  Current serial number in output stream 659

	SoftPC terminates.

	Keys no longer repeat!  Earlier I reported that I experienced no repeat
	in just a text widget, but that it worked OK in a DECterm window.  Now,
	keys don't repeat *anywhere*, including DECterms.

	Key repeatability is restored by fixing the error in the ~/.SoftPC file,
	then starting and exiting SoftPC normally.

-Jeff

3111.2how to suppress the error (message)LOWELL::KLEINMon Jul 23 1990 15:0368
The proper fix for this is to install an X error handler (XSetErrorHandler)
that ignores the FOCUS match error.  Sample code has been posted before,
I don't remember exactly when.  It might be in DECWINDOWS_PROGRAMMING.NOTE.
Looks something like:

#include <stdio.h>
#include "decw$xlibmsg.h"
#include <decw$include/DECwDwtWidgetProg.h>
#include <decw$include/XProto.h>

#define BUFSIZ 256

static void ErrorHandler(dpy, event)
    Display *dpy;
    XErrorEvent *event;
{
    char bufA[BUFSIZ];
    char msgA[BUFSIZ];
    char numberA[32];
    char *mtype = "XlibMessage";

    /* Ignore soft errors. */

    if (
	/* Attempted to assign input focus to a window, but that window was 
	 * iconified at the time the server processed the request. */

        ((event->error_code == BadMatch) &&
         (event->request_code == X_SetInputFocus)) ||

	/* Attempted to select for ButtonPress on the root window, but
	 * another application already has selected for it. */

        ((event->error_code == BadAccess) &&
         (event->request_code == X_ChangeWindowAttributes))) return;

    XGetErrorText (dpy, event->error_code, bufA, BUFSIZ);
    XGetErrorDatabaseText (dpy, mtype, "XError", "X Error", msgA, BUFSIZ);
    fprintf (stderr, "%s:  %s\n  ", msgA, bufA);
    XGetErrorDatabaseText (dpy, mtype, "MajorCode", "Request Major code %d", 
	msgA, BUFSIZ);
    fprintf (stderr, msgA, event->request_code);
    sprintf (numberA, "%d", event->request_code);
    XGetErrorDatabaseText (dpy, "XRequest", numberA, "", bufA, BUFSIZ);
    fprintf (stderr, " (%s)", bufA);
    fputs ("\n  ", stderr);
    XGetErrorDatabaseText (dpy, mtype, "MinorCode", "Request Minor code", 
	msgA, BUFSIZ);
    fprintf (stderr, msgA, event->minor_code);
    fputs ("\n  ", stderr);
    XGetErrorDatabaseText (dpy, mtype, "ResourceID", "ResourceID 0x%x",
	msgA, BUFSIZ);
    fprintf (stderr, msgA, event->resourceid);
    fputs ("\n  ", stderr);
    XGetErrorDatabaseText (dpy, mtype, "ErrorSerial", "Error Serial #%d", 
	msgA, BUFSIZ);
    fprintf (stderr, msgA, event->serial);
    fputs ("\n  ", stderr);
    XGetErrorDatabaseText (dpy, mtype, "CurrentSerial", "Current Serial #%d",
	msgA, BUFSIZ);
    fprintf (stderr, msgA, dpy->request);
    fputs ("\n", stderr);
}

void SpecialSetErrorHandler()
{
    XSetErrorHandler (ErrorHandler);
}
3111.3WRKSYS::GOLDBERGMarshall R. Goldberg, WorkstationsMon Jul 23 1990 18:006
    Thanks for the hint. I will pass it right on to Insignia. Just
    wonder if this will help with their keyboard disable auto-repeat
    problem as well. Shall let you know.
    
    Marshall
    
3111.4FixedWRKSYS::GOLDBERGMarshall R. Goldberg, WorkstationsMon Jul 30 1990 11:269
    Steve,
    
    The error handler fixed the problem!
    
    Thanks again,
    
    Marshall