It is currently November 28th, 2021, 4:44 am

Script Reader

Discuss the use of Lua in Script measures.
Posts: 90
Joined: January 26th, 2013, 9:11 pm

Script Reader

Post by Frostschaden »

Am trying to implement Google Calendar using the Enigma Reader script into Smurfiers Lua calendar. I've successfully done so, but have run into a couple of problems.

1. Special characters do not display, for example '&'. I have included DecodeCharacterReference=1 to no avail.
2. The dates are not displaying correctly, they are displaying the current date and time, rather than the set.

EDIT: Ok so I've discovered the problem, it is not the code itself, but the calendar feed address. Following the instructions within Enigma Options I copy the xml address and input this address into the options.

It looks like this ''

Hitting enter then puts a call through to another script that converts "basic" to "full"
I've found that part in the Options script

Code: Select all

function ParseGcal(_, Value)
	Value = ParseProtocol(_, Value)
	return string.gsub(Value, '/basic', '/full')
What I would like to do is put this into its own little script rather than having use the entire Options script from Enigma. Unfortunately for me, learning the language is like trying to fly a plane without experience.

So if anyone can help me out with this that'd be great!
User avatar
Posts: 436
Joined: February 28th, 2011, 3:20 pm
Location: Vienna, Austria

Re: Script Reader

Post by ikarus1969 »

Since the docs in the LUA-Scripting section talks about some restrictions - at the bottom - , i don't think that's possible currently because you would need the use of "require" which is not available in the lua-implementation in rainmeter.

I would definitely second such a suggestion because i do use LUA in my own skins very often.

But i don't know how much effort it would mean to implement that to rainmeters lua.
User avatar
Posts: 446
Joined: August 7th, 2012, 9:18 pm

Re: Script Reader

Post by thatsIch »

you can do something like that with dofile, but you need to pay attention that you dont make it public. Basically you need to handle it, like an outsourced function

Code: Select all

	-- Libs
	Meters, Measures, Variables = dofile(SKIN:GetVariable('@').."Scripts\\libs\\InterfaceOOPAccess.lua")(SKIN)
	FileReader = dofile(Variables['@'].."Scripts\\Libs\\FileReader.lua")
	PrettyPrint = dofile(Variables['@'].."Scripts\\Libs\\PrettyPrint.lua")
for example is my lib call
User avatar
Posts: 1931
Joined: January 29th, 2010, 1:43 am
Location: Willmar, MN

Re: Script Reader

Post by smurfier »

I just want to point out that the gsub line posted above is for when the user inputs their url into the options skin. Unless you have a place for the user to input their url, or a measure that checks the url every once in a while, then it's not the solution you are looking for. Neither dofile or require are what you want.

Perhaps something like this:

Code: Select all


IfTrueAction=[!WriteKeyValue Variables CalendarUrl "[SubUrl]"][!Refresh]
As a warning: dofile does not work well in the implementation of Lua that Rainmeter uses and should not be used unless absolutely necessary.
GitHub | DeviantArt | Tumblr
This is the song that never ends. It just goes on and on my friends. Some people started singing it not knowing what it was, and they'll continue singing it forever just because . . .
User avatar
Posts: 22413
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: Script Reader

Post by jsmorley »

I want to be careful not to encourage dofile() in public messages in the forums. If you understand the implications of it properly, and want to use it in your skins on your PC, more power to you. However, I am fearful of the risk of having folks share code snippets as dofile() includes or having them used in skins that are distributed.

The risk comes from the fact that Lua code executed by a Script measure in Rainmeter runs in a local tablespace that is specific to the calling skin, and all variables or functions created or re-defined in them are local to that skin. However, when you execute a dofile() statement in the script, that dofile is loaded and executed in a global tablespace in our implementation of Lua in Rainmeter, and anything you do that isn't carefully "local" in nature is shared by all scripts, and the skins running them.

It would be easy for someone to assume that dofile() in Lua is pretty much the same as @Include in Rainmeter. It so, so isn't...

It's easy enough to test. Simply create two skins, both running Lua scripts. Have one of the skins execute a script that loads a dofile that simply has MyVar="FUBAR" as the only line of code. Then have it return(MyVar) in the Update() function.

In the second skin, execute a script that simply has return(MyVar) in the Update() function. Don't load the dofile.

Run both skins, and you will find that the value of the Script measure in BOTH will be "FUBAR". While harmless (although annoying) in this isolated instance, having the dofile() approach being used by all kinds of people in all kinds of skins that are mixed and matched around is destined to cause hideous conflict problems, ones that in fact can be difficult to debug at first glance.

And just to add insult to injury, anything that is defined in that dofile will remain defined in Lua until you completely restart Rainmeter. Unloading the skin(s) won't do it.

We have recommended in the documentation that dofile() not be used in Rainmeter, and this is the root of why. Unless and until we get require() working right, which will operate in a local way all the time, I really don't think it is wise to talk up dofile() as a solution here. The fact that YOU may know how to properly and safely use the function in your skins is irrelevant. It is not a safe or reliable function for the general community in our implementation of Lua in Rainmeter.