WebParser: Local Files and inserting the parsing result into the URL.

[Kotofanchik]

So basically, what I'm trying to say is that @include would automatically parse the file for you, if it was suited to be used in this case (which apparently isn't, given that you still need to extract "cod" from the address), cancelling the need to have all kinds of WebParsers to parse the file and look for some value.]

My brain was racing. I don't understand how @include would automatically parse the file
Where is there about file analysis?
https://docs.rainmeter.net/manual/skins/include-option/

[Yincognito]

I'm currently using @include and actual "cod" value as a variable. I want to give this up.

So, do it. Nobody is forcing you to do something you don't want. Nobody will be upset about it either, so it's fne.

[Yincognito]

My brain was racing. I don't understand how @include would automatically parse the file
Where is there about file analysis?
https://docs.rainmeter.net/manual/skins/include-option/

The first paragraph (ok, it doesn't say it literally, but one can read between the lines, right?):

The @Include option loads the content of an external .ini at the position it is defined. The loaded file is treated as if the contents were included in the actual skin .ini file.

Then, in the @include guide linked on that page, it's spelled out in a more direct fashion:

Understanding @include
When Rainmeter reaches an @include line, it reads the given file, placing all unique options into any existing sections, then places the remainder of the included file after the section in which it was called.

Load = read = parse, when it comes to files, as far as I know. Feel free to disagree though.

[Kotofanchik]

So, do it. Nobody is forcing you to do something you don't want. Nobody will be upset about it either, so it's fne.

This was done a long time ago, before me, it doesn’t suit me, I wanted a beautiful solution, not this.
This is inconvenient, not user friendly
It's like Dos when there are windows everywhere
And I still don’t understand what the connection is between @include and webparsing

[Kotofanchik]

Load = read = parse, when it comes to files, as far as I know. Feel free to disagree though.

So that's what you're talking about. Although I still don’t fully grasp it. I can simply copy the entire text of the file and paste it inside the first one and the same thing will happen. So? I separated them and linked them via @include just for convenience, otherwise they were originally one .ini I can combine them back. Should I do this?

[Yincognito]

And I still don’t understand what the connection is between @include and webparsing
or did you decide to troll me?

I don't practice the trolling sport (at least not without provocation), and this is a serious forum, not one where some folks make fun of others (occasional jokes do happen, but they're friendly and harmless).

I can't do much about the understanding part, I did my best to explain it - short of pointing you out to Rainmeter code's GitHub page where everything would be clear for a C++ programmer (which is probably not the case), I don't know how else to explain it. But ok, I'll make one more attempt: WebParser and @include do the same thing: they read / parse / load some text resource (either from the web or some local file), the only difference is that @include expects that text resource to have an .INI syntax, with sections, keys and values.

So that's what you're talking about. Although I still don’t fully grasp it. I can simply copy the entire text of the file and paste it inside the first one and the same thing will happen. So? I separated them and linked them via @include just for convenience, otherwise they were originally one .ini I can combine them back. Should I do this?

Yep, it's just for convenience, but it also has a functional purpose: if you have some value you want to retrieve in another text file, you could use @include to read it from that other file, IF that file was had an .INI / .INC syntax. In your original post, you had exactly that, a value you wanted to retrieve from another text file. You used WebParser for that, since you needed to extract "cod" from the address and the file probably didn't have an .INI syntax, but it could have had (and make things easier in that regard, compared to using WebParser). That's the thing I was (labouriously, lol) trying to convey all this time.

As for whether you should do this or that, it's your choice, your skin, your system - you do as you feel it's best, most convenient, most practical to your use case. I was just trying to propose an easier approach earlier, but if the WebParser one works as you want, then by all means, no need to change it just because someone - anyone - laid out an alternative. It's just another way of doing the same, really.

[Kotofanchik]

Yep, it's just for convenience, but it also has a functional purpose: if you have some value you want to retrieve in another text file, you could use @include to read it from that other file, IF that file was had an .INI / .INC syntax. In your original post, you had exactly that, a value you wanted to retrieve from another text file. You used WebParser for that, since you needed to extract "cod" from the address and the file probably didn't have an .INI syntax, but it could have had (and make things easier in that regard, cmpared to using WebParser). That's the thing I was (labouriously, lol) trying to convey all this time.

Yes, I'm extracting "cod" from the .inc file, but @include isn't capable of doing that, it's not part of its capabilities, or it's not described anywhere. There is not a word about this in the certificate. This can webparser. But how can @include do this? This is impossible. "cod" is not a variable or any other value that can be processed by Rainmeter. Consider it a comment that the Rainemeter does not see, but the webparser sees it

[Yincognito]

Yes, I'm extracting "cod" from the .inc file, but @include isn't capable of doing that, it's not part of its capabilities, or it's not described anywhere. There is not a word about this in the certificate. This can webparser. But how can @include do this? This is impossible. "cod" is not a variable or any other value that can be processed by Rainmeter. Consider it a comment that the Rainemeter does not see, but the webparser sees it

It is, if using Substitute. Give me a moment to put some basic example showcasing the idea, then you'll understand. Can you provide how that text file looks like, or at least the part related to the address and "cod" value, so what I'll post can be more meningful? It doesn't have to be exactly like you have it, if you have some API key or other more "sensitive" data, just a simple example of how the part with the address looks like in your Setting.inc file.

[Kotofanchik]

There is a line there URL=*ttp://4e4pgja.to/rtbm/index.php?suhtpic=175621&st=900#entry129295917vrjtbyktb68923:20 03/27/2024B7$%#567956T8756462512VNNGRLUTBI6EVUC4B7 N 7TBYTV
The required “cod” is highlighted in color, how can @include extract it?

[Yincognito]

There is a line there URL=*ttp://4e4pgja.to/rtbm/index.php?suhtpic=175621&st=900#entry129295917vrjtbyktb68923:20 03/27/2024B7$%#567956T8756462512VNNGRLUTBI6EVUC4B7 N 7TBYTV
The required “cod” is highlighted in color, how can @include extract it?

This is how:

Test_1.0.0.rmskin

Notice the similarities between the Substitute option in [Cod] and the RegExp option in [mCod].

Settings.inc:

Code: Select all

[Variables]
URL=*ttp://4e4pgja.to/rtbm/index.php?suhtpic=175621&st=900#entry129295917vrjtbyktb68923:20 03/27/2024B7$%#567956T8756462512VNNGRLUTBI6EVUC4B7 N 7TBYTV

Test.ini:

Code: Select all

[Variables]
@IncludeSettings=#CURRENTPATH#Settings.inc

[Rainmeter]
Update=1000
AccurateText=1
DynamicWindowSize=1
BackgroundMode=2
SolidColor=0,255,0,255

---Measures---

[Cod]
Measure=String
String=#URL#
RegExpSubstitute=1
Substitute="(?sU)^.*%#(.*)T.*$":"\1","^\\\d+$":""

[mCod]
Measure=WebParser
URL=file://#CURRENTPATH#Settings.inc
CodePage=1200
RegExp="(?sU)%#(.*)T"
StringIndex=1

---Meters---

[Test]
Meter=String
MeasureName=Cod
MeasureName2=mCod
FontFace=Consolas
FontSize=16
AntiAlias=1
Text=From @Include : %1#CRLF#From WebParser: %2

The [Cod] part is a way to extract the "cod" from the @included URL variable in Settings.inc - note that URL must belong to a [Variables] section there, if it belongs to another section, like a measure or something, then you cannot store it as a variable since Rainmeter only has a limited way of getting the value of an option from a section via parameters.

The [mCod] part is basically your old WebParser measure that does the same thing - but, importantly, it doesn't have the limits of the @include option, so, assuming the right RegExp, it will be able to extract "cod" wherever it may be in the Settings.inc file, and whatever the syntax of that file might be.

The advantage of using @include is that you don't have to bother with adding a FinishAction=[!CommandMeasure mTotal "Update"] or similar to an alternative [mCod] WebParser measure, it will work right away. The only reason the [Cod] measure is needed in this case of using @include is that the "cod" needs to be extracted from the address in the "URL" variable. Also, I only included the ,"^\\\d+$":"" part in the Substitute to get rid of the potential \1 left if a match for "cod" is not found (see the note here about how Rainmeter doesn't like empty captures and leaves them as the literal \1, \2 and so on).

P.S. By the way, I posted the packaged .rmskin because I wanted to show you that WebParser can read UTF-16 LE BOM files too (like I made Settings.inc to be), given the proper CodePage option added to the measure.