Kotofanchik wrote: ↑March 27th, 2024, 7:40 pm
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.
Kotofanchik wrote: ↑March 27th, 2024, 7:48 pmSo 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.