It is currently May 25th, 2020, 3:16 pm

[Help] Getting config's WindowX and WindowY position!

Discuss the use of Lua in Script measures.
DeathByChocolate
Posts: 25
Joined: September 17th, 2014, 8:47 pm

[Help] Getting config's WindowX and WindowY position!

Post by DeathByChocolate »

I was absolutely certain that this issue would have been asked by someone else in this forum, but surprisingly not...

Anyways, essentially I am trying to grab the WindowX value of a config in the Rainmmeter.ini file, however I seem to be having trouble. If I enact this piece of code in lua:
File = io.open(os.getenv('APPDATA').. '\\Rainmeter\\Rainmeter.ini', 'r')
print(File:read('*a'))
Then I get a Debug message in the log which says ÿþ[...
Log.jpg
If I then copy Rainmeter.ini and move it elsewhere like in my Documents folder, it persists with that debug message. Other files such as .txt and other .ini seem to work perfectly! Is there some sort of read protection on this file? If so, how would I go about attaining a config's X/Y position?
You do not have the required permissions to view the files attached to this post.
User avatar
jsmorley
Developer
Posts: 20629
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: [Help] Getting config's WindowX and WindowY position!

Post by jsmorley »

You really can't read Rainmeter.ini from Lua. Lua will only read ANSI / UTF-8 encoded files, and Rainmeter.ini is always encoded as UTF-16.

https://docs.rainmeter.net/tips/unicode-in-rainmeter/

Use WebParser, with CodePage=1200 on the parent, to read the entire Rainmeter.ini file into a single StringIndex. Then you can use LUA to parse the value of the WebParser measure as you like, in effect treating that as a file.

Code: Select all

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

[Variables]

[MeasureReadIni]
Measure=WebParser
URL=file://#SETTINGSPATH#Rainmeter.ini
CodePage=1200
RegExp=(?siU)^(.*)$
StringIndex=1
FinishAction=[!EnableMeasure Lua]

[Lua]
Measure=Script
ScriptFile=Test.lua
Disabled=1
UpdateDivider=-1

[MeterDummy]
Meter=String

Code: Select all

function Initialize()

	measureReadingIni = SKIN:GetMeasure('MeasureReadIni')
	
end

function Update()

	entireIni = measureReadingIni:GetStringValue()
	
	print(entireIni)

end

Note that you also should not "write" to Rainmeter.ini with Lua. If you want to write to Rainmeter.ini, you want to send !WriteKeyValue bangs to the skin and have the skin write to the file. If you write to Rainmeter.ini with Lua, you will likely destroy it. The only safe way to write to Rainmeter.ini with Lua is to write the entire contents as a new file, being careful to preface the file with the BOM characters ÿþ for UTF-16 LE.

I would also note that none of this is needed to get the current X and Y position of the actual skin the Lua is running in. That can be done by simply using the #CURRENTCONFIGX# and #CURRENTCONFIGY# built-in variables. You would only need this if you wanted to find the position of some other skin. Also, be aware that just because a config is in Rainmeter.ini, and has a WindowX / WindowY setting, doesn't mean it is actually loaded and running. To be sure of that, you need to look for Active=x in the [Section], where "x" is some number other than 0.

Final note: I really hate this for trying in some fashion to have one skin "follow" some other skin based on its real-time position. This is going to end up as a horrid Rube Goldberg, and will at best have all kinds of "lag" and/or use a ton of CPU. I don't know exactly what you are going for here, but I already sorta hate it... There is no efficient or satisfactory way to have one skin "follow" another skin around on the screen. Period.
DeathByChocolate
Posts: 25
Joined: September 17th, 2014, 8:47 pm

Re: [Help] Getting config's WindowX and WindowY position!

Post by DeathByChocolate »

I greatly appreciate the help JSMorley!! Works like a charm!

And to hopefully put your mind at ease, what I currently have is a sort of 'temporary' desktop, essentially I have one skin which is an image that takes the whole screen and then on top of that are multiple 'widget' skins that !Show/!Hide when the main image skin is shown or hidden...

The point of grabbing the WindowX/Y values was so that when I hide the image skin (and subsequently all of the 'widget' skins), I could save the original positions of all of the 'widgets', !Move them off screen and then use !Move to position them back. As you can see I will not once be touching Rainmeter.ini :)

For the reason why I am doing it, essentially since I only hide the skins, never unload them, they still exist on my desktop and so when I move other skins, they snap to the invisible widget edges. I hope this is not CPU intensive, however if it is, then I may have to instead use !DeactivateConfig/!AcitvateConfig instead (which I prefer not to do as it clogs up the log and could cause issues with Weather widgets and the such.
User avatar
jsmorley
Developer
Posts: 20629
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: [Help] Getting config's WindowX and WindowY position!

Post by jsmorley »

DeathByChocolate wrote:
April 14th, 2020, 3:41 pm
I greatly appreciate the help JSMorley!! Works like a charm!

And to hopefully put your mind at ease, what I currently have is a sort of 'temporary' desktop, essentially I have one skin which is an image that takes the whole screen and then on top of that are multiple 'widget' skins that !Show/!Hide when the main image skin is shown or hidden...

The point of grabbing the WindowX/Y values was so that when I hide the image skin (and subsequently all of the 'widget' skins), I could save the original positions of all of the 'widgets', !Move them off screen and then use !Move to position them back. As you can see I will not once be touching Rainmeter.ini :)

For the reason why I am doing it, essentially since I only hide the skins, never unload them, they still exist on my desktop and so when I move other skins, they snap to the invisible widget edges. I hope this is not CPU intensive, however if it is, then I may have to instead use !DeactivateConfig/!AcitvateConfig instead (which I prefer not to do as it clogs up the log and could cause issues with Weather widgets and the such.
Sounds reasonable....