GPF in pop-ups

[vefatica]

I see you also fixed that in built 40. But you did it in a way that's a bit cumbersome for the user ... after typing it takes two keystrokes to get something done, the first merely to cause something to become selected.

When you first open a pop-up, something is selected and, although the I-beam cursor is not in the edit box, typing appears there. After the user types a (or another) character, and you have adjusted (narrowed down) what appears in the window, can't you cause **something** to be selected (first, last, I don't care) so that a simple "Enter" executes it and "Up"/"down" moves the selection relative to it?

 

[rconn]

That seems a spectacularly bad idea -- you want TCC to randomly select and execute something?!?

Or do you want a Windows impossibility -- for both the edit control and the list box to have focus simultaneously??

I did not make anything more cumbersome for the user; the changes make it much less so. Previously there was no way to switch from the edit control to the list box without switching to the mouse. The only change I made was if you hit Enter in the edit control, it moved the focus to the first matching entry in the list box. (Previously, it wouldn't do anything on an enter.)

 

[vefatica]

That seems a spectacularly bad idea -- you want TCC to randomly select and execute something?!?

Or do you want a Windows impossibility -- for both the edit control and the list box to have focus simultaneously??

I did not make anything more cumbersome for the user; the changes make it much less so. Previously there was no way to switch from the edit control to the list box without switching to the mouse. The only change I made was if you hit Enter in the edit control, it moved the focus to the first matching entry in the list box. (Previously, it wouldn't do anything on an enter.)

To the first comment ... no ... if the selected one is what the user wants, he should execute it with "Enter" ... if it's not what he wants he should continue typing or press "Up" or "Down" to change the selection.

To the second ... I don't know exactly how focus works now ... I never put the I-beam cursor in the edit box (and it doesn't go there on its own) but magically typing goes there. I want it to be, after each update of the list, as it is when it first opens (something selected which is executed upon "Enter" and typed letters going into the edit box).

 

[rconn]

To the first comment ... no ... if the selected one is what the user wants, he should execute it with "Enter" ... if it's not what he wants he should continue typing or press "Up" or "Down" to change the selection.

If the focus is in the list box and you press Enter, you'll get the selected line. If the focus is in the edit control, then it's impossible for anything to be selected in the list box, so pressing Enter in the edit control would be meaningless and random to the list box. (If you prefer, I could have TCC select a random matching entry in the list box instead of the first one, but I don't see how that is an improvement ...)

To the second ... I don't know exactly how focus works now ... I never put the I-beam cursor in the edit box (and it doesn't go there on its own) but magically typing goes there.

As soon as you start typing (instead of using the cursor keys), the focus goes to the edit control.

I want it to be, after each update of the list, as it is when it first opens (something selected which is executed upon "Enter" and typed letters going into the edit box).

You can't have that (unless Microsoft agrees to rewrite some fundamental Windows architecture).

As I said to a similar previous complaint, you can either have the v12 behavior (no edit control, and no automatic elimination of non-matching entries, but the focus always stays in the list box), or the v13 behavior. You cannot cherry pick the features you want from each and combine them. If you want the v12 behavior, I have to remove the v13 behavior completely. If you can get 51% of the users to agree with you, I'll delete the v13 changes.

 

[Charles Dye]

Possibly dumb suggestion: What if it were a text box, rather than an edit control? Could you update a text box after each keystroke without giving it the focus?

I guess you'd lose the cursor, and therefore the left- and right-arrow keys; would that cause more complaints than it forestalled? But backspace at least would be easy to implement.

 

[vefatica]

Possibly dumb suggestion: What if it were a text box, rather than an edit control? Could you update a text box after each keystroke without giving it the focus?

I guess you'd lose the cursor, and therefore the left- and right-arrow keys; would that cause more complaints than it forestalled? But backspace at least would be easy to implement.

The fact that it's an edit control doesn't seem to matter. If there's a selection in the list box, it persists when the I-beam is in the edit control. Can't the edit control react to "Enter" by sending "Enter" to the list box?

 

[rconn]

Possibly dumb suggestion: What if it were a text box, rather than an edit control? Could you update a text box after each keystroke without giving it the focus?

I guess you'd lose the cursor, and therefore the left- and right-arrow keys; would that cause more complaints than it forestalled? But backspace at least would be easy to implement.

That's what v12 had -- a text field, with no way to edit anything. Whatever you typed got put up there; if you made a mistake, or wanted to cut & paste something, well -- too bad for you. It also made it impossible to remove non-matching entries in the list box (a significant v13 feature). But if everybody prefers the v12 approach, I'm happy to remove the v13 features.

 

[rconn]

The fact that it's an edit control doesn't seem to matter. If there's a selection in the list box, it persists when the I-beam is in the edit control. Can't the edit control react to "Enter" by sending "Enter" to the list box?

No, the selection in the list box definitely does NOT persist when the focus is in the edit control! At least, not in any remotely reliable sense. Consider what happens as soon as you enter anything in the edit control. All non-matching entries are deleted from the list box, probably including the current list box selection. What becomes the current selection then? Any random selection that still matches?

And when you're in the edit control, the highlight is removed from the selection in the list box, so there's no way to know what the current selection (if any) might be. So you're asking for a random non-visible selection to be returned when the user presses Enter in the edit control. I don't see how this is going to be useful to the non-suicidal subset of the user community.

 

[pizzaman]

Frankly, I can't see how it be could more convenient than it is. If you pull up a list box, you can execute the highlighted command with an Enter. Or move the cursor up and/or down to select another one, and execute that one with an Enter.

Or you can start typing to narrow the search and typing automatically changes the focus to the edit window. Pressing Enter in the edit window puts you back in the list window, which works just as did when you first pulled it up. If the command you want is highlighted, press Enter again and it's executed. Just how much trouble can it be to press Enter twice!?!

Not every person with a personal nit can have it his way.