Re: Again on kb_event. It almost works
From: Rob Kennedy (me3_at_privacy.net)
Date: 09/15/04
- Next message: Jamie: "Re: Bandwidth throttling question"
- Previous message: Stark: "Re: Again on kb_event. It almost works"
- In reply to:(deleted message) L D Blake: "Re: Again on kb_event. It almost works"
- Next in thread: Stark: "Re: Again on kb_event. It almost works"
- Reply: Stark: "Re: Again on kb_event. It almost works"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 15 Sep 2004 10:58:24 -0500
L D Blake wrote:
> On Tue, 14 Sep 2004 16:48:27 -0500, Rob Kennedy <me3@privacy.net> wrote:
>> I think the combo box does capture the mouse (or something like that) by
>> itself since it needs to know when the user clicks off the control. I
>> can see the same behavior in Microsoft-written programs. Open the
>> Windows "Run" dialog. Set focus to the combo box, and place the cursor
>> over the edit portion, so it is an I-beam. Press Alt+Down to drop down
>> the combo box. Move the mouse anywhere within the bounds of the dialog,
>> and it will still be an I-beam. Outside the dialog, the cursor's shape
>> appears is normally.
>
> Actually that would be the editor capturing the mouse.
No, it's the combo box. Here's another example: In a "file open" common
dialog, set focus to the file-type combo box, which has no editor. Place
your cursor over the file-name combo box's edit window, and press
Alt+Down to drop down the file-type list. Your cursor should be stuck as
an I-beam even though the window that has the focus.
This might not be "capturing the mouse" in the sense of the SetCapture
API function, but something is going on that causes a dropped-down combo
box to prevent its application's windows from updating the cursor shape.
> Comboboxes (which I use rather a lot) at winapi level don't generally cause
> the mouse cursor to vanish nor do edit windows, which I also use quite a bit.
Combo boxes and edit boxes *do* cause the cursor to vanish. On the
Windows XP system I'm using right now, anyway. It's controled by a
setting in my mouse control panel. Maybe it's an IntelliMouse-specific
setting, or maybe it's native Windows.
When I type into the edit portion of a combo box in a file-open dialog,
the cursor disappears after just one character, *unless* what I've typed
matches the start of name of a file in the current directory, in which
case the auto-complete window drops down and the cursor re-appears.
(That drop-down window is not the combo box's usual list box.) The first
non-matching character makes the drop-down window go away, and the next
character after that makes the cursor go away again. The behavior is
similar when deleting characters and causing the remaining string to
match a file name again.
The cursor also disappears when I type into the spin-edit box on the
screen-saver control panel, so this isn't limited to combo boxes or the
common dialogs.
The cursor does not disappear as I type this message into Thunderbird,
but I figure that's because Mozilla programs don't use the native
Windows controls, except for the common file dialogs (which behave as I
described above).
The cursor also does not disappear when I type at the Windows 98 machine
behind me. (Actually, it does disappear, but only because it flickers as
the edit box repaints itself and the caret blinks.) Then again, it's
also a Logitech mouse and driver, and its control panel doesn't mention
anything about hiding the cursor.
> Frankly, this one's got me stumped.
Looks like standard Windows behavior to me, but I, too, am stumped
regarding how to change it.
Since it looks like Stark is typing to do some sort of autocomplete
feature, it might be worth looking at Windows' built-in cability for
that, via the IAutoComplete interface. It looks like that requires
Windows 2000 or Windows ME, though.
-- Rob
- Next message: Jamie: "Re: Bandwidth throttling question"
- Previous message: Stark: "Re: Again on kb_event. It almost works"
- In reply to:(deleted message) L D Blake: "Re: Again on kb_event. It almost works"
- Next in thread: Stark: "Re: Again on kb_event. It almost works"
- Reply: Stark: "Re: Again on kb_event. It almost works"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|