Working with InputText

[balala]

Couldn't find anything during my searching but I've been encountering an unexpected behavior with InputText and colon characters.

If I input for example 10:30 then a Windows dialog appears saying:



Similarly occurs if I enter something like foo:bar (the dialog then says the type of link is 'foo'). I've observed the dialog doesn't appear for strings where the sub-string before the colon is a digit lower than '10' such as '9'.

I can't replicate the issue, at least not with, for instance, the example code, posted on the InputText plugin help page. So, please post the code you have the problem with, to can check what's going on.

[Crest]

I can't replicate the issue, at least not with, for instance, the example code, posted on the InputText plugin help page. So, please post the code you have the problem with, to can check what's going on.

Sure, here's a simplified test case. As mentioned in my edit further down the post I'm using jsmorley's method of re-using the $UserInput$ variable, which I need for what I'm doing* (or at least some way of re-using the input variable for multiple InputText commands which need to be triggered).

* The commands I'm actually using aren't represented in this test case below but I do utilize WriteKeyValue among other things. Either way the below skin demonstrates the issue due to the auto URL handling.

Main INI:

Code: Select all

[Variables]
InputHeight=30
Bg=457FA8
Fg=FFFFFF
Value2=

[Rainmeter]
AccurateText=1
DynamicWindowSize=1
Update=1000

[InputBox]
Measure=Plugin
Plugin=InputText
H=#InputHeight#
FontColor=#Fg#
SolidColor=#Bg#
FocusDismiss=1
Command1=["$UserInput$"]
Command2=[!WriteKeyValue Variables Value1 "[InputBox]" "foobar.ini"]
Command3=[!SetVariable Value2 "[InputBox]"]
DynamicVariables=1

[VisibleBox]
Meter=Shape
Shape=Rectangle 0,0,200,#InputHeight#,0 | Fill Color #Bg# | StrokeWidth 0
LeftMouseUpAction=[!CommandMeasure "InputBox" "ExecuteBatch 1-3"]
DynamicVariables=1

[VisibleText]
Meter=String
Text=#Value2#
FontColor=#Fg#
DynamicVariables=1

Example sibling INI for WriteKeyValue (foobar.ini):

Code: Select all

[Variables]
Value1=

[Brian]

There is nothing unexpected with your code. The issue is with the "trick" in jsmorley's code is also sending whatever is typed directly with Command1=["$UserInput$"] to the Windows command line. Thus, you are seeing an dialog message since it is interpreting the colon as a protocol command (like a URL), but it can't process it.

You will probably have to find another solution to what you are trying to do.

-Brian

[Crest]

You will probably have to find another solution to what you are trying to do.

A problem I was having in my prior testing (before discovering the URL handling drawback) were drawbacks with alternative methods.

For example I need to parse some formulas on the input string when the input is completed, however Lua (which I'm using to dynamically set InputText measure properties and values when an input box is clicked) can't see the input string until after the input has been entered.

Because of this I instead wrap the input variable with the desired formulas and set it as part of the value of a dynamically created Command for the InputText measure, so that when Enter is pressed the InputText measure itself triggers an execution of the formula on the input variable.

What I found though is wrapping the $UserInput$ variable directly with a formula fails to parse the formula, instead it just returns the untouched original value. While alternatively when I tried writing $UserInput$ to a separate variable for Command1 (using !SetVariable), then using some formula on it during Command2, it failed to parse the formula—instead reproducing the entire formula verbatim.

So it was only jsmorley's method of storing the $UserInput$ variable as the measure value during Command1 then reading it back via the InputText measure's name in subsequent Commands where it can actually parse formulas with the variable.

If there is some other way that works for this I'd certainly be interested.

[Crest]

Should probably clarify, the overview of what I'm doing is like the following:

- User clicks meter styled as input box. Doing so passes various InputText measure property values (like number of max input characters to allow, whether to limit to numbers only, etc) along with some formula values (like clamp) to a Lua function. This is different for each meter styled as an input box.

- The Lua function dynamically applies those values to the InputText measure and sets its coordinates to that of the input box meter. Then sets the literal $UserInput$ as the measure value for Command1 (per jsmorley's method) and configures the WriteKeyValue/etc with the appropriate formulas for the subsequent InputText measure Commands.

- After entering a value in the actual input box and pressing Enter the input is then parsed with any formulas set in the Commands that get executed by InputText and for example stored to a file and variable.

---

So I suppose given these requirements if I wanted to avoid jsmorley's method but preserve the formulas passed to the Lua to begin with when clicking an input box then alternatively a Command could be dynamically made that triggered a separate Lua function with the passed values (ie: passing the values to the first Lua function which then writes a Command to pass the values on to a separate Lua function after Enter has been pressed).

This assumes that one instead writes the $UserInput$ to a separate variable so the separate Lua function could then read it after the fact, apply any formulas and then write to file and/or the final actual desired variable. Guess I'll have to test this.

[Yincognito]

Should probably clarify, the overview of what I'm doing is like the following:

- User clicks meter styled as input box. Doing so passes various InputText measure property values (like number of max input characters to allow, whether to limit to numbers only, etc) along with some formula values (like clamp) to a Lua function. This is different for each meter styled as an input box.

- The Lua function dynamically applies those values to the InputText measure and sets its coordinates to that of the input box meter. Then sets the literal $UserInput$ as the measure value for Command1 (per jsmorley's method) and configures the WriteKeyValue/etc with the appropriate formulas for the subsequent InputText measure Commands.

- After entering a value in the actual input box and pressing Enter the input is then parsed with any formulas set in the Commands that get executed by InputText and for example stored to a file and variable.

---

So I suppose given these requirements if I wanted to avoid jsmorley's method but preserve the formulas passed to the Lua to begin with when clicking an input box then alternatively a Command could be dynamically made that triggered a separate Lua function with the passed values (ie: passing the values to the first Lua function which then writes a Command to pass the values on to a separate Lua function after Enter has been pressed).

This assumes that one instead writes the $UserInput$ to a separate variable so the separate Lua function could then read it after the fact, apply any formulas and then write to file and/or the final actual desired variable. Guess I'll have to test this.

I still don't understand what exactly you're trying to do. Can you post a simple, short pseudo code, but with some actual values and explanation of what you expect to happen? Don't mention any tricks or Lua whatsoever or refer to theoretical stuff, just say "I type or do this, I want this to happen", as rudimentary and precise as you can. I'm sure it is possible, but the thing is we don't get what an actual, real life "storyline" of the process looks like.

[Crest]

I still don't understand what exactly you're trying to do. Can you post a simple, short pseudo code, but with some actual values and explanation of what you expect to happen?

The goal is simply: be able to re-use the input string from an InputText box for multiple immediate actions that trigger when Enter is pressed (such as !WriteKeyValue, !SetVariable), along with also applying any calculations/formulas to the input string with those actions.

Eg:

Code: Select all

[!WriteKeyValue Variables Value1 "(Clamp(<UserInput>,0,30))" "foobar.ini"]
[!SetVariable Value2 "(Clamp(<UserInput>,0,30))"]

Also that such formula values (like the '0,30' min/max clamp formula here) would be set dynamically when the input box is clicked. In other words those eg. clamp values will be different for different input boxes.

---

To be clear, until my initial post in this topic I already had a functional skin with all the desired behavior—but then discovered all inputs that are used by themselves for InputText Commands are treated as if the string had been entered into a Windows File Explorer addressbar (it thinks some strings are links, or will try to launch program names it recognizes from the PATH).

And to recap, the reason I had to set the raw $UserInput$ as the measure value (as seen in the test case skin above) was due a few things (spoilered to make the post shorter):

- 1st: What jsmorley explained in that linked thread: it's the only method where the user input can be re-used for multiple Commands in the InputText measure (Command1, Command2, etc). Otherwise $UserInput$ gets emptied/reset after each Command.

- 2nd: As I tried to detail above, in my brief testing formulas didn't get parsed if the $UserInput$ is used as variable within them. For example (Clamp($UserInput$,0,30)) just returned $UserInput$ instead of the formula-affected value. (This also assumes only a single Command is used not multiple but noted just as an observation).

Neither did I find formulas get parsed if I instead set $UserInput$ as a separate variable during Command1 (eg: [!SetVariable "foo" "$UserInput$"]) then used it within a formula in Command2 (eg: [!SetVariable "bar" "(Clamp(#foo#,0,30))"]), which from my notes resulted in the literal formula string being returned rather than parsing the formula and returning the resulting value.

- 3rd: I need any formula parsing to occur when the user presses Enter, which can be accomplished via InputText Commands, so had been leveraging Commands to contain such formulas.

If the second paragraph of the 2nd point was feasible then I would have used that, since it would allow me to ditch storing the variable as the measure's value with barely much change to the existing code. It would certainly be the simplest if it worked but I couldn't get it to when I briefly tested.

---

Anyway, my idea for the workaround was posted at the the end of my prior post. I think given I'm already passing formula values like clamp to a script function to handle the initial LeftMouseUpAction that triggers the configuration and appearance of the InputText box that my idea would be probably be suitable but haven't got around to testing the workaround idea.

[Yincognito]

Neither did I find formulas get parsed if I instead set $UserInput$ as a separate variable during Command1 (eg: [!SetVariable "foo" "$UserInput$"]) then used it within a formula in Command2 (eg: [!SetVariable "bar" "(Clamp(#foo#,0,30))"]), which from my notes resulted in the literal formula string being returned rather than parsing the formula and returning the resulting value.

If the second paragraph of the 2nd point was feasible then I would have used that, since it would allow me to ditch storing the variable as the measure's value with barely much change to the existing code. It would certainly be the simplest if it worked but I couldn't get it to when I briefly tested.

Easy peasy...

Code: Select all

[Variables]
foo=
bar=

[Rainmeter]
Update=1000
AccurateText=1
DynamicWindowSize=1

---Measures---

[InputMeasure]
Measure=Plugin
Plugin=InputText
SolidColor=0,128,0,255
FontColor=255,255,255,255
FontSize=15
X=5
Y=5
W=240
H=25
Command1=[!SetVariable foo "$UserInput$"]
Command2=[!SetVariable bar "(Clamp([#foo],0,30))"]
DynamicVariables=1

---Meters---

[Background]
Meter=Image
W=250
H=105
SolidColor=0,0,0,128

[InputMeter]
Meter=String
X=5
Y=5
W=240
H=25
SolidColor=0,64,0,255
FontColor=255,255,255,255
FontSize=15
AntiAlias=1
Text=foo="#foo#", bar="#bar#"
LeftMouseUpAction=[!CommandMeasure InputMeasure "ExecuteBatch 1-2"]
DynamicVariables=1

...using the nested variable syntax.

This forces the formula to use the recently modified value (even if it has been modified in the same bang, or, like in this case, in the same InputText measure).

[Crest]

Easy peasy... using the nested variable syntax.

This forces the formula to use the recently modified value (even if it has been modified in the same bang, or, like in this case, in the same InputText measure).

Such a simple change *whew*. Thanks a bunch ♡

If I could make a suggestion, going back to the string handling part of things, it would also be useful if the docs had some note that using the plain $UserInput$ value as a Command will cause various strings to be interpreted as though it were entered in the Run dialog/etc.

Since I get the impression it's assumed knowledge but the plugin page lacks mention of this and the first post here only briefly alludes to this behavior in the middle of the OP within a larger paragraph (emphasis mine):

Note that we set a "null bang", or "[]" at the beginning to keep Rainmeter from "executing" the value of $UserInput$. That could be a problem if the input text is "calc" or "cmd" or some other text that is also a command or shortcut in the Windows "path".

(I also tested this null bang on my original code but it still triggered the issue when using the measure name syntax so glad I found your nested variable solution)

[Yincognito]

Such a simple change *whew*. Thanks a bunch ♡

If I could make a suggestion, going back to the string handling part of things, it would also be useful if the docs had some note that using the plain $UserInput$ value as a Command will cause various strings to be interpreted as though it were entered in the Run dialog/etc.

No problem - glad to help. Not my place to address suggestions, but it is indeed assumed knowledge that you can place command lines, URLs, special folders and so on in a bang, which then executes those. But you're right, this isn't directly stated, that's true, not even on the Bangs page, which only mentions that you can use bangs in command lines (and not that you can use command lines in bangs). That being said, this is stated a bit clearer at the start of the RunCommand page, or when clicking the "action options" link at the start of the Bangs page...