Re: [ptp-dev] help with strange UI issue

[Greg Watson <g.watson@xxxxxxxxxxxx>]

It's hard to see how a running vs not running RM could affect this, but I presume when the RM is started some handlers get registered somewhere.

Greg

On Sep 30, 2010, at 2:30 PM, Albert L. Rossi wrote:

> For those whose curiosity I piqued.  I added mouse listeners to all widgets. 
> 
> When the resource manager has not been launched, the first MouseUp event seems to get lost.  However, all widgets seem to act as receivers (I get a MouseDown, even on simple Composites).
> 
> When the resource manager is running, only widgets that are activated by the mouse, like buttons and combos, report MouseDown and MouseUp (no lost event), but the composites report nothing.  
> 
> Does this mean that in the second case, something is setting "capture" on the child control of the tab to false?
> 
> Al
> 
> ----- Albert L. Rossi <arossi@xxxxxxxxxxxxx> wrote:
>> I'm finishing up some modifications to the PBS Launch UI and I've run into a rather strange mouse event problem which I was wondering if anyone has had to deal with before.
>> 
>> It seems that the first mouse click on a newly constructed Launch Tab either freezes (on a push button), or gets misdirected to another view (usually the configuration tree to the left of the run configuration page, for instance, if I try to scroll), then spinning endlessly.  In the case of clicking the button, the button remains selected without doing anything, and a second click usually activates it.  Thereafter, everything is sane.
>> 
>> Thus this only happens on the first click; moreover, it only happens when I use the tab without having started the resource manager; it the resource manager is running, this never happens.  When you bring up the Launch Tab without having started the resource manager, a message box tells the user that the template view about to display may not be up to date.  But commenting out that code does not seem to change this peculiar behavior.
>> 
>> At first I thought I had not properly threaded a few of the processing actions that might be on the path of such a mouse click (though I don't see how simple scrolling would involve them...), but even with all the actions which could possibly take time threaded as separate UI jobs, the behavior remains the same.
>> 
>> Perhaps I need to find a way of separating out the activity in these threads from touching the widgets, and run them as normal Jobs rather than in the UI thread...?
>> 
>> At any rate, I was just wondering if anyone had encountered this situation before and knew of a quick (and proper) fix.
>> 
>> Thanks, Al
>> _______________________________________________
>> ptp-dev mailing list
>> ptp-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/ptp-dev
>> 
> 
> _______________________________________________
> ptp-dev mailing list
> ptp-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/ptp-dev