Disabling WebParser Child

[VasTex]

Ah, so essentially avoiding the errors that I'm having with the Child Measures are more or less unavoidable without either lua or my hacked-up, multi-skin monstrosity?

Either way, I'm liking lua more and more each time I mess with it. I've always had some issue with a 'purist' mentality it that I would like the things I work with to more or less self-contained, but I can't argue with the results that lua can offer.

At any rate, I'll probably stick to my grotesque whatchamacallit while I dig through that lua.

Thanks again by the way.

[jsmorley]

So maybe VasTex could use Download=1 and Download the E-Mail-Text to a Local File and read it with a second parent which he Triggers with the FinishAction on the Pseudo-Child?

You don't really have to fool it though. Just use RegExp=(?siU)^(.*)$ and the entire feed will be download and will be the value of that parent. You can use FinishAction on that, use that value in a Lua script, whatever you like.

[jsmorley]

Ah, so essentially avoiding the errors that I'm having with the Child Measures are more or less unavoidable without either lua or my hacked-up, multi-skin monstrosity?

Either way, I'm liking lua more and more each time I mess with it. I've always had some issue with a 'purist' mentality it that I would like the things I work with to more or less self-contained, but I can't argue with the results that lua can offer.

At any rate, I'll probably stick to my grotesque whatchamacallit while I dig through that lua.

Thanks again by the way.

Sure. There may be something interesting you could do with two trips to the site. Just get the "count" with the first parent, and get the "subject" lines with a second parent. Then use the parent with the "count" to drive IfConditions to enable or disable child measures that are children of the second parent.

Sounds like it should work, although if you in fact can't in any way "disable" a child measure to avoid Not enough substring errors, guess it doesn't help. If so, we should really fix that.

[rm_lion]

Didn't want to fool anything it was a serious question. But maybe i'm to stoned to realize that i am a fool?

[VasTex]

I feel like I've tried that though.

The current set up has the FullCount and the 'Feed' measures set as separate Parents. I attempted to enable and disable Child Measures based on the count, but it didn't seem to help as even though I set them to be disabled they would still spit out errors.

I disabled them via !SetOption and also by physically placing Disabled=1 on the Child Measures as a sort of test, but they still produced errors. I could just be terribly misinformed about everything I'm trying to accomplish, but it seems like lua may be the way to get this done now.

[jsmorley]

I feel like I've tried that though.

The current set up has the FullCount and the 'Feed' measures set as separate Parents. I attempted to enable and disable Child Measures based on the count, but it didn't seem to help as even though I set them to be disabled they would still spit out errors.

I disabled them via !SetOption and also by physically placing Disabled=1 on the Child Measures as a sort of test, but they still produced errors. I could just be terribly misinformed about everything I'm trying to accomplish, but it seems like lua may be the way to get this done now.

Huh. Could be. Can't say I have ever tested, but I suspect it is WebParser itself that is ultimately generating the errors, not Rainmeter proper. That makes it difficult as WebParser has no idea what "disabled" even means. We should look into that. There must be some fix. A lot of the complexity comes from the fact that child measures are really just dependent "entities" of the parent measure.

Guess this whole thing is why at some point, long ago, I just went "grrrr" and bailed on WebParser parent / child and just did the whole thing in Lua.

[VasTex]

It's entirely possible that WebParser just ignores those particular options and I wouldn't be surprised either. I spent a good 3-4 hours trying different methods of enabling / disabling both Parent and Child measures, but nothing seemed to stop the errors.

I may try and work out a small example skin demonstrating the issue when I get home from work if I get the chance. I'd be interested to know if others could reproduce the issue.

A lot of the complexity comes from the fact that child measures are really just dependent "entities" of the parent measure.

Also, I feel like this sums up what I was trying to get across in my original post.

[jsmorley]

It's entirely possible that WebParser just ignores those particular options and I wouldn't be surprised either. I spent a good 3-4 hours trying different methods of enabling / disabling both Parent and Child measures, but nothing seemed to stop the errors.

I may try and work out a small example skin demonstrating the issue when I get home from work if I get the chance. I'd be interested to know if others could reproduce the issue.

If I am right, it's not so much that WebParser ignores those options. Those are Rainmeter "measure" options and in a sense WebParser has no role to play. If you initially disable the parent measure, then I suspect you get no errors, as WebParser is never even kicked off. I believe the issue is that WebParser is "pushing" the values to the "child" measures, in a sense outside (behind, under?) the normal measure update functionality. So I think WebParser, when the parent is "running", will get the information and parse it into StringIndexes. Then, STILL inside of WebParser, the child processing in the plugin is attempting to populate the child measures with values. When a child measure has a StringIndex that doesn't exist, the plugin itself is generating the error. A child WebParser measure is much less dependent on the "update" that Rainmeter does on the measure.

This may be close but not quite right, or maybe even complete crap. We should wait to see if Brian or Poiru weighs in on this.

[VasTex]

This is actually my exact thought towards it.

You are correct in assuming that no errors show when the Parent is Disabled. It also seems that according to Rainmeter the Children are, for all intents and purposes, disabled, but the Parent Measure doesn't seem to care and still attempts to fill any indices requested by Children.

I would agree that it's most likely a WebParser specific issue in that the Parent essentially has the last say in what does and doesn't get sent to a Child. Again, when the Parent is disabled, all errors vanish.

Regardless, we should probably wait for those who understand the mechanics of WebParser on a code level to chime in here.

[Brian]

It can be quite confusing to get a handle on what happens when with certain measure options with respect to plugins. It is very important to remember that plugins do not know what "state" they are currently in, they just do what Rainmeter tells them (ie, when to update, what value to return, etc.). Plugins are generally not exposed to the general measure options (except MaxValue).

The manual states that a disabled measure will not update, and just return 0. However, it is easy to forget that the string value is maintained (and not reset to an empty string). This is not Webparser specific, but for all measures and plugins.

The reason why the string value is updated on a disabled Webparser measure is because (like jsmorley said above) the parent measure manually sets its child's string value. This is why a child's string value updates so quickly once the file was downloaded.

At the end of the day, this is really a design flaw in Webparser that cannot be fixed without huge backwards-compatibility issues.

-Brian