Re: Again on kb_event. It almost works
From: Stark (franco.jommi_at_tin.it)
Date: 09/15/04
- Next message: Martin Harvey (Demon account): "Re: Bandwidth throttling question"
- Previous message: Christian Hartmann: "Sorting of 4 String-Lists"
- In reply to: Rob Kennedy: "Re: Again on kb_event. It almost works"
- Next in thread: Bruce Roberts: "Re: Again on kb_event. It almost works"
- Reply: Bruce Roberts: "Re: Again on kb_event. It almost works"
- Reply:(deleted message) L D Blake: "Re: Again on kb_event. It almost works"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 15 Sep 2004 17:43:01 GMT
No I am not trying to do some sort of autocomplete feature. In fact, I have
a Name editbox and Surname editbox through which I capture Name and Surname
that I later compose into a single field in the dataset. The combobox is in
fact a lookup combo that display the name+surname field present in the
dataset. What I wanted to do was to match the string the user types into the
first (name) editbox against the combobox content to suggest a possible
existent name+surname.
I got to the point when the combobox correctly drops down highlighting the
matching line, but I can't get that line !
Unfortunate !
"Rob Kennedy" <me3@privacy.net> ha scritto nel messaggio
news:2qr74uF11u8sgU1@uni-berlin.de...
> 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: Martin Harvey (Demon account): "Re: Bandwidth throttling question"
- Previous message: Christian Hartmann: "Sorting of 4 String-Lists"
- In reply to: Rob Kennedy: "Re: Again on kb_event. It almost works"
- Next in thread: Bruce Roberts: "Re: Again on kb_event. It almost works"
- Reply: Bruce Roberts: "Re: Again on kb_event. It almost works"
- Reply:(deleted message) L D Blake: "Re: Again on kb_event. It almost works"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
