[v1.7.3] "Profile" control direct scrolling results in unexpected profile change

[Pfeil]

When the "Profile" dropdown control has focus, but the dropdown is not actually open, the contents can be changed by a number of methods, including scrolling the mouse wheel, using the arrow keys, and typing the starting letter of any item(which are standard WinForms features).

If this is done slowly, at a pace where VoiceAttack has time to switch between profiles, it works as expected.

However, if the contents are changed rapidly, E.G. by holding down an arrow key, the active profile will change a few times, but often not to the one now displayed on the control.

Even stranger is scrolling rapidly using the mouse wheel, which will result in the profile changing multiple times to the same profiles a few times, then ending up at the wrong profile.


EDIT: Unresolved but unimportant; Archiving.

[Gary]

I am aware of that behavior - it hasn't come up as an issue, so it has been sitting in the, 'investigate' pile for some time.

I'll move it up the list

Thanks, man.

[Gary]

I put on some brakes - hope that works

[Pfeil]

In v1.7.3.1, after selecting the dropdown and changing the profile, either using a keyboard key or the mousewheel, the control will lose focus(so until it regains it, either by clicking it or tabbing to it, the keyboard will not affect it, effectively making keyboard input unusable).

Scrolling the list using the mousewheel will on rare occasions still load one profile multiple times.

I also managed to get the control to get stuck in a disabled state(greyed out), where it seemed no profile was loaded at all.
At this point no commands of the profile last listed as loaded in the log were recognized, and even though the profile had over four commands(and was not named "My Profile") the "Tip  --->  Add some more commands that can be recognized" message appeared in the log.
The Edit Profile button did not function at this time.


If I may, I did a little experimenting with the ComboBox control, and this is what I came up with:

Code: [Select]

void ComboBox1SelectedIndexChanged(object sender, EventArgs e)
{
timer1.Stop();
timer1.Start();
}
void ComboBox1DropDownClosed(object sender, EventArgs e)
{
setProfile();
}
void Timer1Tick(object sender, EventArgs e)
{
setProfile();
}
void ComboBox1DropDown(object sender, EventArgs e)
{
timer1.Stop();
}

void setProfile()
{
timer1.Stop();
if (profile != comboBox1.Text)
{
Debug.WriteLine("setting to " + comboBox1.Text);
profile = comboBox1.Text;
}
}
It uses a timer set to 500ms interval; If the profile dropdown's index is changed using any method other than the dropdown itself, the timer is started.
If the dropdown's index is changed again within 500ms, the timer is stopped and started again to reset the elapsed time.

This defines the behavior as such: If the dropdown list is used to changed the value, it is applied immediately(as the "DropDownClosed" event is triggered), if another method is used to manipulate the value of the ComboBox, the chosen value will be applied after a delay of 500ms.
If the chosen value is already the active profile, it will not reload the profile(as is already the case in VoiceAttack currently).
If the ComboBox value is changed, and within the 500ms delay the dropdown is opened, the profile will not change(as the "DropDown" event handler will stop the timer).


The snippet above is not intended to be taken literally, but to illustrate what I feel may be a possible solution when a user is scrolling though values, without responding to each individual change unnecessarily, while not adding an artificial delay to loading profiles when it is not required.

[Gary]

The problem (I think) is because the control is disabled until the profile is loaded and then re-enabled.  That causes the focus to be lost on the control.  I am trying it with just refocusing the control if it already had focus to see if that solves the problem.  Thanks for your work on this!

[Pfeil]

I tested this after the last change was made, but it's such a niche issue I didn't see the point in pushing the subject.

Testing with v1.7.5.8 my findings are the same as back then:

Profile changed to test
Profile changed to test
Profile changed to test

The repeated loading can still occur, but is rare.

However, the way scrolling loads each profile it comes across makes it pointless to switch profiles using this technique.
The suggested behavior I outlined seems to me like the most useful way for this control to operate, but even I myself don't change profiles this way (as going sequentially is less efficient than using the dropdown directly), so what is implemented currently is probably (more than) enough.

I propose archiving this unless someone else brings it up.

[Gary]

It's all gonna go soon anyway (for better or for worse) - UI update is in the pipeline (first step - remove target from main screen).