Another AppNextEvent challenge 1.2 -> 2.2

This forum is read only. No new submissions are accepted.

Questions about motif? Contact us

2 posts / 0 new
Last post
Another AppNextEvent challenge 1.2 -> 2.2

Submitted by Anonymous on Thu, 08/08/2002 - 18:11. Developers
Hi!
Any input ideas welcome. Sorry about the length. Will process the problem with Xt compiled with the -d option over the next few days.

Rough Structure

I have a Bulletin containing 24 text, toggle, radio and push buttons. Plus a scrolled window which contains an unpopulated Drawing Area widget. This bulletin is created as a result of the user activating a push button.

Under 1.2 no problems.

Under 2. , Changes made e.g. OpenApplication. No widget pointers at this stage, no destoyed widgets, it is almost at the top of the application main - options menu bull then a push button that calls this bull.

Problem

Under current version on the FIRST entry the system is in a continual AppNextEvent loop. All buttons can be activated but not text widgets. The cancel button destroys the bulletin. On second entry all is OK. (Sometimes takes two or three cycles )

Other symptoms

The initial focus is set to a toggle button. On first entry this does not show except if the mouse button is pressed while over one of the scroll bars. The focus box disappears once the mouse button is released.

The bulletin is not moveable, in fact the bulletin header bar is missing.

The bulletin is visible across all pseudo windows on a KDE Linux display. On cancel the control and display reverts to the initiating pseudo window.

I have used null callbacks for the new 2.0 Drawing area callbacks with no effect. I found a footnote in 6a stating that xmClipWindowWidgetClass should be used but this made no effect either. I do not believe the problem has anything to do with the drawing area widget.

It feels like a problem with scroll window where focus mechanisms are being mixed up between the scroll bars and the application designated focus point. Obviously I am confused hence this request. The biggest query is why should it correct itself on the second + generations, i.e. after the bulletin has been destroyed and the bulletin and all the child widgets recreated using exactly the same code.

Attempted work around

After the basic screen set up but before the Drawing area creation with the bulletin still unmanaged I put in a Destroy and a loop back ( with a goto Ugh!) for the first entry only. Problem "went away" only temporaily next day it was back! It is still there so I need to understand why, devise a solution and remove the goto.

Anonymous

More info, I guess that there are no ideas on this out there!.

The problem seems to be confined to the version of KDE2 that we are running. All other session types operate A-OK.

So the recompile of X11R6.6 will wait as we pursue the KDE question route. Incidentally UpdateDisplay made no effect as
did unmanageing all above the chain except the main_widget.