The documentation for VMA (http://www2.wealth-lab.com/WL5Wiki/VMA.ashx) defines the parameters with a DataSeries as input. Bars have volume, but I don't believe a Dataseries has volume. How can it volume weight the calculation?? Since this indicator is in the standard library, I can not review the code.

You're right. If it were written correctly, that indicator should take a Bars object. Consequently, the indicator works only for the current Bars in context. In other words:

CODE:
Please log in to see this code.

I've added a note to the documentation. Keep in mind that you could create a new indicator (like a VMA2) that takes a Bars object too.

Thanks Cone!

QUOTE:
[The VMA] indicator should take a Bars object. Consequently, the indicator works only for the current Bars in context.

Right. So how do I address Volume inside my indicator DLL (VWEMA) which doesn't take a Bars object? I've tried WealthLab.Bars.Volume[0] in the DLL indicator code below, but the VS compiler returns CS0120 An object reference is required for the non-static field, method, or property 'Bars.Volume'. Apparently, WealthLab.Bars. is not a good reference.

CODE:
Please log in to see this code.

I've used the VMA indicator in my strategy code before and have never passed an instance of WealthScript when doing so. So there must be a way of addressing Bars.Volume within my DLL without passing an instance of WealthScript. How is that done in the DLL code implimentation (which VMA employs)?

There's no need to pass an instance of WealthScript in this case. What will work is to pass a Bars object to your constructor like this:

CODE:
Please log in to see this code.

Moreover, the "DataSeries ds" can even be removed and the code refactored if your indicator only operates on the DataSeries inside this Bars object. Every required DataSeries in this case could be "extracted" from the Bars object.

For more (lots of) examples please refer to the open source code of TASCIndicators and Community Indicators. Let me know if any you have any followup questions.

QUOTE:
Moreover, the "DataSeries ds" can even be removed

No it can't be removed because the "DataSeries ds" object is a "computed object" that has nothing to do with the intrinsic Bars object. That won't work here because I'm not interested in taking the VWEMA of the Closes.

QUOTE:
For more (lots of) examples please refer to the open source code

Is there an example in there that grabs the WealthLab.Bars.Volume[...] values without passing in the Bars object or a WealthScript instance? Which indicator in those libraries is doing that? I think the only indicator that does that is VMA, but I don't have the source code for that. How is the VMA indicator accessing the "Context" Volume in its code?

I can overload the VWEMA indicator implementation with a case that does take a lone Bars input for anyone that wants to compute VWEMA(Closes), but I still need one that takes a computed DataSeries input and applies CurrentContext.Volume to it for my own requirements. I can share my code when it's done if you're interested.

It must be using an undocumented way. So what's the problem with passing in the Bars object?

QUOTE:
So what's the problem with passing in the Bars object?

I can pass a Bars object, but I still need to pass a computed DataSeries object as the first parameter input.

If you can't tell me how VMA gets the CurrentContext.Volume, then I can pass a "weighting DataSeries object" instead (as a second parameter), which can be Bars.Volume, but it can be something else too--that's more flexible. That would be better than passing a Bars object, which wouldn't give you a choice on how you're weighting it. But in practice, most users--including me--would be weighting it by CurrentContext.Volume, so just implementing it that way as VMA does makes the most sense. Wouldn't you agree?

QUOTE:
I can pass a Bars object, but I still need to pass a computed DataSeries object as the first parameter input.

Of course you can pass both. No problem and no need to get into undocumented methods.