I’m not sure if it is possible. I set up the Tutorial in a theoretical way, but it isn’t really working yet. For example, with the iChangeColor(elem,prop,color) function, I set the Invoke Action Parameter as follows:
iChangeColor([:elem], [:prop], [:color])
However, my Rule only shows a setting value for [:color], so I guess I have the Action Parameter set incorrectly, or it only accepts a single [:setting] value. And I can’t get that (1 setting) to work either. Maybe my function is borked. Still playing with it.
I had colors changing, did submit no problem, changed form values, did click methods… it was all working… then I split the Script into several Functions… now I’m not sure any of it works…
I just successfully made the folowing behavior… I added a button called Clock Out on the same screen as my TimeTrex HTml viewer… when pressed it invoked the Clock out portion of TimeTrex which caused timetrex to record the punch and then send another value back to SambaPOS telling Samba to logout… lol it worked great… Not sure I would use that but it worked!
The really cool thing is… i was able to record a punch inside timetrex WITHOUT all the fancy API calls and .bat stuff I was using. Now thats not to say I would still need that stuff for automation at Login etc… because this only works with HTML widget on screen.
So right now its neat that I got it to work but its not really that functional of a feature because I could just press logout from Timetrex without having to use the extra step of clicking a samba button. This does tell me I can do some cool things that would definitely be functional though.
If you include quotes that will be a value with quotes. Just like a quote in a word. This is not a JS parsing. We only need a function name and parameters. It could be iChangeColor,blue or something else. I’ve just formatted it like F(x) to make it look like a function.
OK that’s not so important. Doesn’t it work when you do not include quotes?
I realize this is a bit of a side-feature that isn’t necessarily that important, but if Javascript Injection and Function Invocation works as we expect it to, the possibilities are tremendous.
However, if we need to change the way we know to code in Javascript, it becomes cumbersome and unnatural. I hope you can appreciate that.
I was planning using eval function to execute an anonymous function as parameter. So we may not need to inject script for simple tasks and I thought that might be useful there but it won’t I’m rolling it back.
Whoah, what do you mean? I hope you don’t mean what I think you mean, because…
Are you saying eval() is just as good or better and that you’ll switch to that? I hope so, because I don’t want to see this power disappear. Not just @Jesse is giddy about the possibilities, so am I… as are others I’m sure.
That was the reason of {:SETTING} support but it is useless as we won’t need to configure it as a script and just pass it as a rule parameter. So I meant to roll back setting support.
sorry if it was confusing I’ve even didn’t tested if it is possible or not. I was both implementing scripts and entity logs together.
I set the Action Parameter to Invoke this function as such
iChangeColor([:elem], [:prop], [:color])
I thought my Rule might give me access to all those settings. However, my Rule only shows a setting value for [:color]… so does it only accept a single [:setting] value right now? Can this be examined and expanded?
Ok, maybe I’m using the wrong terminology. I don’t want to access settings; I want to “prompt” for input to the Action within the Rule, so as far as I know, the syntax is:
// script with default value for icolor
function iChangeColor(icolor=#FF0000) {
document.body.style.backgroundColor=icolor;
}
Instead, I have to do an explicit check within the function; this works:
function iChangeColor(icolor) {
if (icolor==undefined) {
icolor='#FF0000';
}
document.body.style.backgroundColor=icolor;
}
Multiple variables are now presented to the Rule:
iChangeColor([:elem],[:prop],[:color])
However, if I do not specify a value for the first 2 variables, then the last variable (color) remains undefined, so my function uses a default (red):
function iChangeColor(ielem,iprop,icolor) {
if (ielem==undefined) {
ielem='body';
}
if (iprop==undefined) {
iprop='backgroundColor';
}
if (icolor==undefined) {
icolor='#FF0000';
}
document.body.style.backgroundColor=icolor;
}
Workaround: supply values for everything (this works):
I’m rolling it back.
