[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [platform-swt-dev] Focus problem with new widget... I think
|
Sounds like the calendar control starts a modal loop looking for
WM_LBUTTONUP
and eats it. The table does this when trying to detect a drag and SWT
issues a fake
WM_LBUTTONUP. You may have to do the same.
Really, without seeing the code, debugging through email and guessing at
what is
wrong is pretty difficult.
Steve
"Rob Hughes"
<rhughes@xxxxxxxxxxxxxx To: <platform-swt-dev@xxxxxxxxxxx>
> cc:
Sent by: Subject: RE: [platform-swt-dev] Focus problem with new widget... I think
platform-swt-dev-admin@
eclipse.org
06/25/02 03:48 PM
Please respond to
platform-swt-dev
It turns out that when the user clicks the drop down button a
WM_LBUTTONDOWN message is sent and the mouse is captured. However there
isn't a corresponding WM_LBUTTONUP message sent in this case so the
mouse never gets released.
Rob
-----Original Message-----
From: platform-swt-dev-admin@xxxxxxxxxxx
[mailto:platform-swt-dev-admin@xxxxxxxxxxx] On Behalf Of Steve Northover
Sent: Tuesday, June 25, 2002 11:28 AM
To: platform-swt-dev@xxxxxxxxxxx
Cc: platform-swt-dev@xxxxxxxxxxx
Subject: RE: [platform-swt-dev] Focus problem with new widget... I think
Nope, NO MESSAGES ARE LOST. Let me stress this as anything else would
be catastrophic. The problem is that the implemenation of the automatic
grab in one of WM_LBUTTONDOWN and friends in interfering with the
message processing of the widget. Slider and Table have this "problem"
and work around it in different ways. Slider saves and restores the
previous capture after calling the super. Table doesn't call the super,
calling the helpers that the super uses to do the same work but not
grab.
Imagine how hard this would be to debug if SWT were written in Java and
C.
Steve
"Rob Hughes"
<rhughes@xxxxxxxxxxxxxx To:
<platform-swt-dev@xxxxxxxxxxx>
> cc:
Sent by: Subject: RE:
[platform-swt-dev] Focus problem with new widget... I think
platform-swt-dev-admin@
eclipse.org
06/25/02 01:12 PM
Please respond to
platform-swt-dev
The problem goes away when I override those methods. Evidently SWT is
subclassing the window classes with the Display windowProc and is only
chaining the windowProcs some of the time. Is this correct? Should I
investigate further as to why it doesn't work with the subclassing so to
be consistent with the other widgets? My guess would be that one of the
messages isn't getting forwarded to the real windowProc.
Rob
-----Original Message-----
From: platform-swt-dev-admin@xxxxxxxxxxx
[mailto:platform-swt-dev-admin@xxxxxxxxxxx] On Behalf Of Steve Northover
Sent: Tuesday, June 25, 2002 8:32 AM
To: platform-swt-dev@xxxxxxxxxxx
Subject: Re: [platform-swt-dev] Focus problem with new widget... I think
Hack your new control to override subclass() and unsubclass() to do
nothing. Does the problem go away?
Steve
"Rob Hughes"
<rhughes@xxxxxxxxxxxxxx To:
<platform-swt-dev@xxxxxxxxxxx>
> cc:
Sent by: Subject:
[platform-swt-dev] Focus problem with new widget... I think
platform-swt-dev-admin@
eclipse.org
06/25/02 01:59 AM
Please respond to
platform-swt-dev
I'm trying to make a new widget that wraps the win32 DateTimePicker
control. Everything is working great except for 1 problem that I can't
seem to trace down, mainly due to my limited knowledge of the inner
workings of SWT.
The DateTimePicker Control has a popup window to allow the user to pick
the date. This is presented via a drop down arrow button similar to a
combo box. When the popup is activated by a left mouse click and then a
date is picked with a left mouse click, the popup is closed
automatically and the new date is put in the edit field. However the
app is in a funny state focus wise I believe( could be wrong here ). The
app no longer responds to mouse movements as far as hot tracking, button
pushing, list selection, and such. I have to left click anywhere in the
app to restore normal behavior. I'm not sure why this is happening. It
seems to stem from the fact that I clicked outside of the bounds of the
original date picker edit area in choosing the date. If I drop down the
picker with the keyboard shortcut and then pick the date with the mouse
this behavior does not happen. It only happens if I click the drop down
arrow with the mouse.
The class I'm creating extends Control and only overrides a minimal set
of super functions(callWindowProc, checkStyle, widgetStyle, windowClass,
windowProc).
Things I have tried.
I noticed Combo overrides WM_SETFOCUS and WM_KILLFOCUS because it
receives similar notifications in the WM_COMMAND messages. DatePicker
receives the same kind of messages in the WM_NOTIFY message so I tried
processing it the same as Combo to no avail.
I modified hasFocus() to take into account when the popup was visible.
I'm not sure what else to try, this could not even be a focus problem
:).
Rob Hughes
_______________________________________________
platform-swt-dev mailing list
platform-swt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-swt-dev
_______________________________________________
platform-swt-dev mailing list
platform-swt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-swt-dev
_______________________________________________
platform-swt-dev mailing list
platform-swt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-swt-dev
_______________________________________________
platform-swt-dev mailing list
platform-swt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-swt-dev
_______________________________________________
platform-swt-dev mailing list
platform-swt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-swt-dev
