Merging Skins For Improved Functionality (i hope)[succeeded]

[death.crafter]

Alright!
There are two stucks,
Generating the container shapes, and assigning the GetConfigName for each container.

The other one is having the top row hold position whilst the path containers scroll up or down, kinda like an excel sheet can have.

I dunno about other people, but I think this is a pretty cool idea - even if most of the design is based on other persons' scripts/skins.

Tho a cool idea, the config is far from what it needs to do. I currently don't have much time to make a complete config out of this, but here is a short explanation of what you need to do:

• You need to parse the result of GetConfigNames to get individual configs.
• Then use them in text fields of your string meters, you may replace the texts from options, like you do in %% or just make the whole config.
• Also, the order of include files matter, you can't just include them anywhere you like. I am saying this cause you are using relative positioning in meters.

Also to do the first, you'd need Lua or PowershellRM whichever you prefer.

For you it might be a little bit hard, but not impossible.

I will drop a complete config with proper comments tomorrow, or the day after it.

[death.crafter]

Sorry CodeCode. I just broke my laptop today . So can't really help out rn. Until my pc comes back try out things on your own.

Sorry again.

[CodeCode]

Sorry CodeCode. I just broke my laptop today . So can't really help out rn. Until my pc comes back try out things on your own.

Sorry again.

Man, sorry your computer is offline.

Try not to miss me or be too bored without me.

[CodeCode]

Hey there is still hope for me yet - but it still requires your help.

I went back to the PSRM. Things are starting to make sense. There is one detail that screams my name in torment:

I am creating the iterated shapes and have managed to get to a point.

So, in PSRM in a template like this:

Code: Select all

[Configs$i]
Meter=String
X=450
Y=25r
Text=[*GetConfigName*]
MeterStyle=Contents
Container=Container$i
DynamicVariables=1

How do I reference the GetConfigName which is the parse measure reading the Rainmeter.ini. What is there now simply puts [GetConfigName] literally, but successful in that every shape has the literal measure and is formatted good.

Thanks death.crafter. I hope this can be simple enough for your tablet or cell.

[death.crafter]

Okay, a little heads up.

In powershellrm you can use $RmAPI.MeasureStr('MeasureName') to get the string value of a measure.

Now moving on to the measure, now use a delimiter | to delimit the active configs. Basically, use “\1|“ in the substitute in GetRainmeterSettings measure.

Now you'll have a string like ActiveConfig1|ActiveConfig2|ActiveConfig3 from the measure.

Now let's come back to powershell.

In powershell store the value of the measure in a variable, say $activeConfigsRaw.

Now we have the string stored. Next we will process that string to get all the active configs, which we'll store in an array and use them to make our string meters.

Code (I don't guarantee it's working since I can't test it) :

Code: Select all

function Update {
    $RmAPI.Bang('[!EnableMeasure GetRainmeterSettings][!CommandMeasure GerRainmeterSettings Update]')
    MakeConfigs
    $RmAPI.Bang("[!DisableMeasure $($RmAPI.GetMeasureName())]")
}

function MakeConfigs {
    $activeConfigsRaw=$RmAPI.MeasureStr('GetRainmeterSettings')

    # split method is used to split a string by a given delimiter. 
    # Here I used '\|' since '|' is a regex reserved character. 
    $activeConfigs=$activeConfigsRaw -split '\|'

    # now that I have an array of active configs, I can use them to make my meters.

    # in this function we would iterate through the values in $activeConfigs to make the meters. 
    # $_ is a automatic variable that is the current object in the iteration. 

   $str=''
   $i=0
   $activeConfigs | ForEach-Object {
       $str+=@"
[MeterContainer$i]
Meter=Shape
MeterStyle=ConfigContainer

[Meter$i]
Meter=String
MeterStyle=ConfigString
Container=MeterContainer$i
Text=$_
"@
        # we increase the $i variable with each iteration
        $i++
   }
   # now that we have a complete string of measures and meters, we can make a file out of it. 
   # we will use unicode encoding, aka UTF-16
   $str | Out-File"$($RmAPI.VariableStr('@'))ActiveConfigs.inc" - encoding unicode
}

Skin would have something like this:

Code: Select all

[PowershellRM]
Measure=Plugin
Plugin=PowershellRM
ScriptFile=xxx

[GetRainmeterSettings]
Measure=WebParser
Url=file://#SETTINGSPATH#Rainmeter.ini
Substitute="active filter":"\1|"
Disabled=1

I can only hope that it will work. You can test it.

[CodeCode]

Okay, a little heads up.

In powershellrm you can use $RmAPI.MeasureStr('MeasureName') to get the string value of a measure.

Now moving on to the measure, now use a delimiter | to delimit the active configs. Basically, use “\1|“ in the substitute in GetRainmeterSettings measure.

Now you'll have a string like ActiveConfig1|ActiveConfig2|ActiveConfig3 from the measure.

Now let's come back to powershell.

In powershell store the value of the measure in a variable, say $activeConfigsRaw.

Now we have the string stored. Next we will process that string to get all the active configs, which we'll store in an array and use them to make our string meters.

Code (I don't guarantee it's working since I can't test it) :

Code: Select all

function Update {
    $RmAPI.Bang('[!EnableMeasure GetRainmeterSettings][!CommandMeasure GerRainmeterSettings Update]')
    MakeConfigs
    $RmAPI.Bang("[!DisableMeasure $($RmAPI.GetMeasureName())]")
}

function MakeConfigs {
    $activeConfigsRaw=$RmAPI.MeasureStr('GetRainmeterSettings')

    # split method is used to split a string by a given delimiter. 
    # Here I used '\|' since '|' is a regex reserved character. 
    $activeConfigs=$activeConfigsRaw -split '\|'

    # now that I have an array of active configs, I can use them to make my meters.

    # in this function we would iterate through the values in $activeConfigs to make the meters. 
    # $_ is a automatic variable that is the current object in the iteration. 

   $str=''
   $i=0
   $activeConfigs | ForEach-Object {
       $str+=@"
[MeterContainer$i]
Meter=Shape
MeterStyle=ConfigContainer

[Meter$i]
Meter=String
MeterStyle=ConfigString
Container=MeterContainer$i
Text=$_
"@
        # we increase the $i variable with each iteration
        $i++
   }
   # now that we have a complete string of measures and meters, we can make a file out of it. 
   # we will use unicode encoding, aka UTF-16
   $str | Out-File"$($RmAPI.VariableStr('@'))ActiveConfigs.inc" - encoding unicode
}

Skin would have something like this:

Code: Select all

[PowershellRM]
Measure=Plugin
Plugin=PowershellRM
ScriptFile=xxx

[GetRainmeterSettings]
Measure=WebParser
Url=file://#SETTINGSPATH#Rainmeter.ini
Substitute="active filter":"\1|"
Disabled=1

I can only hope that it will work. You can test it.

Hey,
I'm not sure about the "active filter" in the substitute. To what does it represent?

Oh yes, I found the $RmAPI.MeasureStr('MeasureName') from Khanis manual on GitHub. Just did not get the intended usage.

[CodeCode]

Oh and am I recalling correctly that the function Update is just the updater, but this line in the main ini should run the actual script array? :

LeftMouseUpAction=[!CommandMeasure Config_psrm "MakeConfigs"]

I am not in a hurry, it is just happens to be what I am doing rn.

I cant believe you were able to create the ps1 on a mobile device??

I am just not getting the $str | Out-File"$($RmAPI.VariableStr('@'))Builder.inc" - encoding unicode output. So i dont think i am successfully running the ps1.

[death.crafter]

Hey,
I'm not sure about the "active filter" in the substitute. To what does it represent?

Oh yes, I found the $RmAPI.MeasureStr('MeasureName') from Khanis manual on GitHub. Just did not get the intended usage.

Active filter is the regex pattern yamajac had in her original measure.

And no the usage of update is intended here. Powershell rm takes some time to initiate it's environment, so once it's completed Update will enable GetRainmeterSettings and update it. Then it will execute the config making function and disable it self. So the update function will only run once.

Then you can use OnChangeAction or if not match action in GetRainmeterSettings to remake the config list.

Well as I said I can't check it for bugs rn

[CodeCode]

Active filter is the regex pattern yamajac had in her original measure.

And no the usage of update is intended here. Powershell rm takes some time to initiate it's environment, so once it's completed Update will enable GetRainmeterSettings and update it. Then it will execute the config making function and disable it self. So the update function will only run once.

Then you can use OnChangeAction or if not match action in GetRainmeterSettings to remake the config list.

Well as I said I can't check it for bugs rn

Ok. Forgive my naivety. But how is the ps1 executed initially? Is this correct?
LeftMouseUpAction=[!CommandMeasure Config_psrm "Update"]
It seems it would be ok, but the initial load of the skin, will require a user triggered action, or is there an 'autopilot-startup'?

[CodeCode]

Then you can use OnChangeAction or if not match action in GetRainmeterSettings to remake the config list.

Sorry youe explained that already. I'll jump to it.

Thanks HEAPS d.c