[BUG] OnDismissAction and LeftMouseUp event order

[Yincognito]

A little bug walked down the allee, till one dev stepped on it and the little bug went to bugs' hell...

Sample skin:

Code: Select all

[Variables]
Var1=1
Var2=2

[Rainmeter]
Update=1000
DynamicWindowSize=1
AccurateText=1
BackgroundMode=2
SolidColor=47,47,47,255

---Measures---

[InitInputs]
Measure=Calc
IfCondition=1
IfTrueAction=[!SetOptionGroup InputTextGroup FontFace "Consolas"][!SetOptionGroup InputTextGroup FontColor "255,255,255,255"][!SetOptionGroup InputTextGroup FontSize 16][!SetOptionGroup InputTextGroup AntiAlias 1]
UpdateDivider=-1
DynamicVariables=1

[Text1Input]
Group=InputTextGroup
Measure=Plugin
Plugin=InputText
X=[Text1:X]
Y=[Text1:Y]
W=[Text1:W]
H=[Text1:H]
DefaultValue=#Var1#
UpdateDivider=-1
Command1=[!SetVariable Var1 "$UserInput$"]
Command2=[!UpdateMeasure *][!UpdateMeter *][!Redraw]
Command3=[!Log "Enabled scroll from Text1Input commands"][!EnableMouseAction * "MouseScrollDownAction|MouseScrollUpAction"]
OnDismissAction=[!Log "Enabled scroll from Text1Input dismiss"][!EnableMouseAction * "MouseScrollDownAction|MouseScrollUpAction"]
DynamicVariables=1

[Text2Input]
Group=InputTextGroup
Measure=Plugin
Plugin=InputText
X=[Text2:X]
Y=[Text2:Y]
W=[Text2:W]
H=[Text2:H]
DefaultValue=#Var2#
UpdateDivider=-1
Command1=[!SetVariable Var2 "$UserInput$"]
Command2=[!UpdateMeasure *][!UpdateMeter *][!Redraw]
Command3=[!Log "Enabled scroll from Text2Input commands"][!EnableMouseAction * "MouseScrollDownAction|MouseScrollUpAction"]
OnDismissAction=[!Log "Enabled scroll from Text2Input dismiss"][!EnableMouseAction * "MouseScrollDownAction|MouseScrollUpAction"]
DynamicVariables=1

---Meters---

[Text1]
Meter=String
Y=5R
W=100
FontFace=Consolas
FontColor=255,255,255,255
FontSize=16
AntiAlias=1
Text="#Var1#"
UpdateDivider=-1
MouseScrollUpAction=[!SetVariable Var1 (#Var1#+1)][!UpdateMeasure *][!UpdateMeter *][!Redraw]
MouseScrollDownAction=[!SetVariable Var1 (#Var1#-1)][!UpdateMeasure *][!UpdateMeter *][!Redraw]
LeftMouseUpAction=[!Log "Disabled scroll from Text1 click"][!DisableMouseAction * "MouseScrollDownAction|MouseScrollUpAction"][!CommandMeasure Text1Input "ExecuteBatch All"]
DynamicVariables=1

[Text2]
Meter=String
Y=5R
W=100
FontFace=Consolas
FontColor=255,255,255,255
FontSize=16
AntiAlias=1
Text="#Var2#"
UpdateDivider=-1
MouseScrollUpAction=[!SetVariable Var2 (#Var2#+1)][!UpdateMeasure *][!UpdateMeter *][!Redraw]
MouseScrollDownAction=[!SetVariable Var2 (#Var2#-1)][!UpdateMeasure *][!UpdateMeter *][!Redraw]
LeftMouseUpAction=[!Log "Disabled scroll from Text2 click"][!DisableMouseAction * "MouseScrollDownAction|MouseScrollUpAction"][!CommandMeasure Text2Input "ExecuteBatch All"]
DynamicVariables=1

Expected behavior: I should be able to scroll, unless editing an input text (even if I directly switch from editing one input text to editing another)
Actual behavior: when DIRECTLY switching from one input text to another (i.e. without dismissing outside of all input texts first and clicking to edit another input text afterwards), the OnDismissAction of the "leaving" input text triggers AFTER the left click on the "entering" input text, which results in enabling scroll instead of disabling it like desired

More specifically, while the dismiss event of an input text "should" occur BEFORE the click event on another input text (which is also logical from a sequential point of view, not to mention the order of things in Rainmeter, aka measures then meters), the order of these is reversed, making achieving the desired goal impossible in the current implementation. I added some !Log bangs to better illustrate what happens:

EventOrder - Wrong.jpg

This should however look like (a bit of photoshopping involved):

EventOrder - Right.jpg

P.S. A long time ago, it was eclectic-tech if I recall correctly, who came up with a solution to this, but while I already applied it in my skins ever since then, it's kind of redundant to keep repeating this for every little skin where such a functionality is desired (if I remember to do so, that is - if not, the bug becomes a bug in such a skin), so it would be nice if there was a way to fix this. For the record, that solution was to use a variable to increment and decrement the number of input texts that are "active" or "editing" and set the mouse actions based on that and not on the said measure and meter options - something like this:

Code: Select all

[Variables]
Var1=1
Var2=2
SetScroll0=[!EnableMouseAction * "MouseScrollDownAction|MouseScrollUpAction"]
SetScroll1=[!DisableMouseAction * "MouseScrollDownAction|MouseScrollUpAction"]
NoScroll=0

[Rainmeter]
Update=1000
DynamicWindowSize=1
AccurateText=1
BackgroundMode=2
SolidColor=47,47,47,255

---Measures---

[InitInputs]
Measure=Calc
IfCondition=1
IfTrueAction=[!SetOptionGroup InputTextGroup FontFace "Consolas"][!SetOptionGroup InputTextGroup FontColor "255,255,255,255"][!SetOptionGroup InputTextGroup FontSize 16][!SetOptionGroup InputTextGroup AntiAlias 1]
UpdateDivider=-1
DynamicVariables=1

[Text1Input]
Group=InputTextGroup
Measure=Plugin
Plugin=InputText
X=[Text1:X]
Y=[Text1:Y]
W=[Text1:W]
H=[Text1:H]
DefaultValue=#Var1#
UpdateDivider=-1
Command1=[!SetVariable Var1 "$UserInput$"]
Command2=[!UpdateMeasure *][!UpdateMeter *][!Redraw]
Command3=[!SetVariable NoScroll ([#NoScroll]-1)][#SetScroll[#NoScroll]]
OnDismissAction=[!SetVariable NoScroll ([#NoScroll]-1)][#SetScroll[#NoScroll]]
DynamicVariables=1

[Text2Input]
Group=InputTextGroup
Measure=Plugin
Plugin=InputText
X=[Text2:X]
Y=[Text2:Y]
W=[Text2:W]
H=[Text2:H]
DefaultValue=#Var2#
UpdateDivider=-1
Command1=[!SetVariable Var2 "$UserInput$"]
Command2=[!UpdateMeasure *][!UpdateMeter *][!Redraw]
Command3=[!SetVariable NoScroll ([#NoScroll]-1)][#SetScroll[#NoScroll]]
OnDismissAction=[!SetVariable NoScroll ([#NoScroll]-1)][#SetScroll[#NoScroll]]
DynamicVariables=1

---Meters---

[Text1]
Meter=String
Y=5R
W=100
FontFace=Consolas
FontColor=255,255,255,255
FontSize=16
AntiAlias=1
Text="#Var1#"
UpdateDivider=-1
MouseScrollUpAction=[!SetVariable Var1 (#Var1#+1)][!UpdateMeasure *][!UpdateMeter *][!Redraw]
MouseScrollDownAction=[!SetVariable Var1 (#Var1#-1)][!UpdateMeasure *][!UpdateMeter *][!Redraw]
LeftMouseUpAction=[!SetVariable NoScroll ([#NoScroll]+1)][#SetScroll[#NoScroll]][!CommandMeasure Text1Input "ExecuteBatch All"]
DynamicVariables=1

[Text2]
Meter=String
Y=5R
W=100
FontFace=Consolas
FontColor=255,255,255,255
FontSize=16
AntiAlias=1
Text="#Var2#"
UpdateDivider=-1
MouseScrollUpAction=[!SetVariable Var2 (#Var2#+1)][!UpdateMeasure *][!UpdateMeter *][!Redraw]
MouseScrollDownAction=[!SetVariable Var2 (#Var2#-1)][!UpdateMeasure *][!UpdateMeter *][!Redraw]
LeftMouseUpAction=[!SetVariable NoScroll ([#NoScroll]+1)][#SetScroll[#NoScroll]][!CommandMeasure Text2Input "ExecuteBatch All"]
DynamicVariables=1

[Brian]

I'm not sure anything can be done for 2 reasons.

#1. Threading: The plugin creates its own "input" control, running in its own thread. This means there could possibly be "timing" issues beyond Rainmeter's control. Also, bangs sent from a "threaded" source (like OnDismissAction) could be delayed depending on what the main Rainmeter thread is currently doing (like its in the middle of the Update cycle of the current skin or any other skin, etc.).

#2. Windows: The "OnDismissAction" is executed basically when the input text control loses focus. Clicking outside of the input text window causes the loss of focus, and in this case Windows sends the mouse click event automatically to the skin. There is no "wait for the input text control to react to losing focus before sending the mouse click to another window".


You may have to live with the workaround.

-Brian

[Yincognito]

I'm not sure anything can be done for 2 reasons.

#1. Threading: The plugin creates its own "input" control, running in its own thread. This means there could possibly be "timing" issues beyond Rainmeter's control. Also, bangs sent from a "threaded" source (like OnDismissAction) could be delayed depending on what the main Rainmeter thread is currently doing (like its in the middle of the Update cycle of the current skin or any other skin, etc.).

#2. Windows: The "OnDismissAction" is executed basically when the input text control loses focus. Clicking outside of the input text window causes the loss of focus, and in this case Windows sends the mouse click event automatically to the skin. There is no "wait for the input text control to react to losing focus before sending the mouse click to another window".


You may have to live with the workaround.

-Brian

Yep, that's what I thought. Then, maybe a small note in the manual regarding this situation (unfortunately, the workaround code would be too long to add there, but maybe it could be synthesized in a few words) is a good idea? Of course, the situation is not necessarily common enough to happen in simple, regular skins, I'm just saying...