[TC 11.00b4] incorrect drawing of menu items when changing an option

[ghisler(Author)]

"Caret" is the term Microsoft uses for the current text/list position. Cursor is what they use for the mouse cursor only.

The position in the list is only changed when you move the mouse. As long as you don't move the mouse, the position isn't changed. Even if I tried to determine the mouse position in any possible event (which btw. isn't possible on touch screens), it wouldn't help when the user switches this option via keyboard.

[AntonyD]

"Caret" is the term Microsoft uses for the current text/list position. Cursor is what they use for the mouse cursor only.

The position in the list is only changed when you move the mouse. As long as you don't move the mouse, the position isn't changed. Even if I tried to determine the mouse position in any possible event (which btw. isn't possible on touch screens), it wouldn't help when the user switches this option via keyboard.

All right, let's deal with the small blocks of answer.

The position in the list is only changed when you move the mouse. As long as you don't move the mouse, the position isn't changed.

Agree! Sound good. Correct action, or even better - inaction in this case
But this concerns ONLY the mouse cursor itself. Not the things which are next to it, or under it.
Let's move on:

Even if I tried to determine the mouse position in any possible event (which btw. isn't possible on touch screens)

touch screen we should left for users of the touch screen. Only they can create any Significant bug report would it popped up for them in their circumstances.
And of course we have no doubt that you can get the mouse pos?

Code: Select all

#include <Windows.h>

int main() {
    POINT cursorPos;
    if (GetCursorPos(&cursorPos)) {
        int x = cursorPos.x; // X-coordinate of the cursor position
        int y = cursorPos.y; // Y-coordinate of the cursor position
        // Print or use the cursor position as needed
        printf("Cursor position: X = %d, Y = %d\n", x, y);
    }
    return 0;
}

Again Let's move on:

it wouldn't help when the user switches this option via keyboard.

Something here again does not connect in my mind. Even if this menu was called only with the keyboard - the fact of the presence of the mouse cursor on the screen in some area - unchanged! Consequently, if we find its position and compare it with the coordinates of the pop-up menu and intersect it with the positions of the items in that menu - we should still easily get some non-empty set of that intersection - which will correspond to some 1 entry in that menu. And we're highlighting it up. Well, or if the mouse cursor was actually somewhere far away from the pop-up menu, we will get an empty set - which means that the menu simply will not have any primary selection of any of its items. It's all very reasonable. Then I take the mouse in my hands and move its cursor to the desired entry in this "no selection" menu - and I get my primary selection.

[ghisler(Author)]

Moderator message

Moved to will not be changed

[AntonyD]

strange...