Text editor skin?

[Active Colors]

Yincognito,
here is my test skin from the Gif above:

EDIT: I have reuploaded the file:

NoteTest1.zip

Ctrl+Enter for line-break.

Reminding that the issues are:
1) When adding new lines of text InputText plugin will copy-paste the previous lines of text. It ends up with a) multiple copies of the same text, and b) the input does not reflect those copied lines and shows your input the way it had to be.
2) Refreshing the skin will make InputText plugin show only the first line of the variable.

[Yincognito]

I was about to post my test code but you were faster than me because I was cleaning up my test code.

Lua could be the approach but due to my lack of experience with lua I use Quote plugin to read a text file. https://docs.rainmeter.net/manual/plugins/quote/

This is how it is done with Quote plugin:

Code: Select all

[MeasureNotes]
Measure=Plugin
Plugin=Quote
PathName=#@#Note.txt
Separator=¶

[MeterNotes]
Meter=String
MeasureName=MeasureNotes
Text=%1

Unless I'm mistaken, the QuotePlugin isn't able to write to a file, just read from it. Plus, the random thing might not be desirable in this case.

Yincognito,
I have just come up with an idea that it might be possible to create a multi-line text editor skin but there are some issues and I don't know if they can be fixed. See the gif below with the issues in-action [...]

Hmm ... the issues being with the InputText measures, am I right? To be honest, I didn't use Lua to make a text editor skin yet, but I successfully used it to read / write to files. My launcher skin is doing some reading from a file, but I just used left click to trigger editing the file with Notepad as an easier alternative. You made me curious about the whole text editor implementation though...

[Active Colors]

Unless I'm mistaken, the QuotePlugin isn't able to write to a file, just read from it. Plus, the random thing might not be desirable in this case.

I know. I just acknowledged about the way to read a file.

[Active Colors]

Hmm ... the issues being with the InputText measures, am I right? To be honest, I didn't use Lua to make a text editor skin yet, but I successfully used it to read / write to files. My launcher skin is doing some reading from a file, but I just used left click to trigger editing the file with Notepad as an easier alternative. You made me curious about the whole text editor implementation though...

I am not sure where the problem is, to be honest.

The read-write lua approach probably can handle the whole case better but I am not much familiar with lua.

EDIT:
1) The copied lines issue might be due to the Commands in the InputText plugin. Improving the Commands could possibly solve this issue.
2) It is probably possible to make Enter imitate the line-break simply by adding another command which will: 1) save the user input but at the end of the user input will add the line-break character to imitate the "add new line by pressing enter" 2) execute editing batch again.

[jsmorley]

I am not sure where the problem is, to be honest. Read-write lua approach probably can handle the whole case better but I am not much familiar with lua.

Be careful about depending on Lua for reading and writing text files. Remember that Lua can only deal with ANSI / UTF-8 files, and will choke on UTF-16 Unicode files.

[Yincognito]

I am not sure where the problem is, to be honest.

The read-write lua approach probably can handle the whole case better but I am not much familiar with lua.

EDIT:
1) The copied lines issue might be due to the Commands in the InputText plugin. Improving the Commands could possibly solve this issue.
2) It is probably possible to make Enter imitate the line-break simply by adding another command which will: 1) save the user input but at the end of the user input will add the line-break character to imitate the "add new line by pressing enter" 2) execute editing batch again.

I can't - or maybe I just don't know how to - replicate the copied lines issue, but the Enter thing is normal: option values in Rainmeter (including the INC-like files included in skins) stop at the newline character. It's not that a multiline string doesn't load correctly, it's the fact that by design Rainmeter "can't see" past the new line in a file like:

Code: Select all

[Variables]
MyText=one
two
three

so it will only get the "one".

EDIT: I replicated the copied lines issue. That looks to have a logical explanation as well.

[Active Colors]

I can't - or maybe I just don't know how to - replicate the copied lines issue.

Really? Can you try again? Recorded another Gif with the skin I posted:

GIF.gif

[SilverAzide]

It's not that a multiline string doesn't load correctly, it's the fact that by design Rainmeter "can't see" past the new line in a file like:

Code: Select all

[Variables]
MyText=one
two
three

so it will only get the "one".

Actually, it's Windows itself, not Rainmeter. The .INI file format is/was defined by Microsoft. Rainmeter uses the Win32 APIs to read (and write) these files.

[Yincognito]

Really? Can you try again? Recorded another Gif with the skin I posted:
GIF.gif

I replicated the issues you mentioned already. I'll work on a proper "text editor" thing later on - I have to eat and do other stuff first, LOL.

Actually, it's Windows itself, not Rainmeter. The .INI file format is/was defined by Microsoft. Rainmeter uses the Win32 APIs to read (and write) these files.

Indeed - just tried to be "simple" (though innaccurate) when posting.

[Yincognito]

I am not sure where the problem is, to be honest.
2) It is probably possible to make Enter imitate the line-break simply by adding another command which will: 1) save the user input but at the end of the user input will add the line-break character to imitate the "add new line by pressing enter" 2) execute editing batch again.

This is what stops one to make a text editor in Rainmeter - the InputText measure behavior:

Code: Select all

[Variables]
Text="one#CRLF#two#CRLF#six"

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

---Styles---

[StyleText]
FontFace=Arial
FontSize=10
FontColor=220,220,220
SolidColor=50,50,50
StringStyle=Normal
AntiAlias=1

---Measures---

[MeasureInput]
Measure=Plugin
Plugin=InputText
X=7
Y=24
W=166
H=230
FontFace=Arial
FontSize=10
FontColor=220,220,220
SolidColor=100,100,100
StringStyle=Normal
AntiAlias=1
FocusDismiss=1
DefaultValue="#Text#"
Command1=[!SetVariable SomeVariable "$UserInput$"]
DynamicVariables=1

---Meters---

[MeterBackground]
Meter=Image
X=0
Y=0
W=180
H=300
SolidColor=40,40,40
UpdateDivider=-1
DynamicVariables=1

[MeterNotes]
Meter=String
MeterStyle=StyleText
X=7
Y=24
W=166
H=230
Text="#Text#"
DynamicVariables=1

[MeterButtonEdit]
Meter=String
MeterStyle=StyleText
X=7
Y=265
SolidColor=60,60,60
Padding=5,5,5,5
Text=[Edit]
LeftMouseUpAction=[!CommandMeasure "MeasureInput" "ExecuteBatch 1"]
DynamicVariables=1

In the file above that has no dependencies (basically your modified Notes version), despite the fact that the meter displays the "#Text#" variable correctly using new lines, once one clicks on the [Edit] button to trigger any bang at all involving the "$InputText$" macro, the new line characters are stripped off the "#Text#" variable, similar to how new lines are stripped off in the Rainmeter Log when viewing String values of measures and variables that "normally" contain new lines as well.

As far as I'm concerned, I can deal and find solutions to most of the other issues, but if one cannot display the text properly in the InputText measures, creating a multiline editor is a difficult task, especially since this kind of measures are pretty much the only way one can interact to edit text in a Rainmeter skin. To build a multiline editor would thus involve crazy workarounds like having multiple one-line InputText measures to simulate new lines which would break proper selecting and copy pasting in the said construct, or reinventing the wheel and replicate all text interactions like the ones mentioned earlier in Rainmeter itself even though those things are already provided by Windows by default.

I didn't even get to Lua because of this, LOL. While in theory implementing such workarounds is entirely possible, via $MouseX$, $MouseY$, Draggable settings, context menus, different coloring for selected text and free text, or the HotKey plugin (I believe I started something along the HotKey lines a while ago just for fun), it's the fact that these are or should be already available and not have to be reimplemented. But yeah, I understand why this happens, InputText is a special measure based on a smart "steal" from Windows and requires special rules...