Hi.
I had previously been using a translated version of a WL4 chartscript that plots Pivot Points. I was trying to work out all the translator particularities to have it working natively in WealthLab 6.0 and at the same time encapsulate the code into an object which could be easily reusable between different strategies. HOwever I am new to the C# world so I am still struggling a little.

Apparently the compiler doesn't recognize the functions SetScaleDaily, RestoreScale, Synchronize, PlotSeries, PricePane outside of the WealthScript context. I already figured that the Bars object doesn't exist until the WealthScript class instantiates it, so I thought passing it as a paramter to the constructor would give me access to all it's properties, which it does. But the functions I need to call in the object are not available there.

Any suggestions to a newbie?

CODE:
Please log in to see this code.

The compiler errors I am getting are:

QUOTE:
error CS0103(60,11) : The name 'SetScaleDaily'does not exist in the current context
error CS0103 (68,17): the name 'Synchronize' does not exist in the current context
error CS0103 (97,5): Then name 'PlotSeries' does not exist in the current context

It's not a good idea to mix WSTL translated output with pure WealthScript. Not only it's unsupported but most likely, won't work at all. WSTL library intercepting method calls and internally mapping them into its own logic creates havoc.

To remove the WSTL remnants (you don't seem to need it here anyway), do the following:

1. Inherit your strategy from WealthScript instead of WealthScriptTL
2. Delete the void Init method
3. Remove the call to Init

Thanks Eugene. I've done that but my problem remains: The compiler doesn't let me call the indicated functions above in the PivotLevels class. The compiler error remains the same.

This is how the updated code looks like:

CODE:
Please log in to see this code.

Apparently the compiler doesn't like me calling PlotSeries, SetScaleDaily, RestoreScale and Synchronize from outside the Execute method or WealthScript classes.

As a workaround, you can pass an instance of the WealthScript class to the constructor of your class (when creating it in your strategy) as e.g. "obj". Then you'd call obj.PlotSeries and so on. However, note that you won't be able to utilize this construct in a "formal" (compiled) indicator (like the ones in Standard, Community or TASCIndicators libraries).

Thank Eugene. That solved all the compilation problems. But I can't help but wonder the following two items:
1) What would be the correct way of coding a formal Indicator that has this 7 components (S3 thru R3) without resorting to this clever workaround. I can imagine that many functions should be available to be called from a namespace outside the WealthScript.

2) I've seen the source code for multi line indicators and they have been coded as each Data Series as a separate DataSeries object (e.g. Bollinger Upper and Bollinger Lower). In the case of the pivot lines the calculation of each line is so interdependent on the other ones that I believe the best design would call for a single object whose constructor would calculate every single Data Series in one fell swoop and then provide methods to access those Data Series. Would it be possible to incoporporate to the compiled Indicators such an Indicator so that it could be dragged and dropped into charts without resorting to coding? How do you suggest we could do that?

Thanks a lot.

Jorge

Here is the simplifed code that ended up working with your idea.

CODE:
Please log in to see this code.

1 - If you ever find a way, let us know.
2 - No.

I have one more coding question on this matter. I eventually got it to work, but not without running into a little confusion.
This code does work:

CODE:
Please log in to see this code.

However this code doesn't work (it plots the pivots as if they had been calculated on the intraday data and not the compressed daily data:

CODE:
Please log in to see this code.

The only difference between these two versions are in line 34 and in line 41 - 44.
In the first (working) version I am referring to the Bars object through a local private object variable (BaseStrategy) which is initialized with the strategy brought by the parameter.
In the 2nd (non-working) version I am storing the Bars object referred to in the 1st version in another local private variable (BarsBaseSeries) and then using that one to calculate the pivots. The 2nd version seems to make the calculations on the expanded Bars data instead of on the compressed Bars data. This leads me to believe that the SetScaleDaily() had effect on the BaseStrategy object and it's Bars component, but since it left untouched the BarsBaseSeries (in it's expanded form) it seems that an assignment of the object of type Bars actually performs a copy of the object and not just a copy of the reference for that object. I thought that in C# object assignments copied only the reference for the object and not the object itself.

Can someone help me clarify this?

Thanks.