[SOLVED] PriceVolDistribution in AmiBroker 6.13 beta

[fxshrat]

By "weird plot" been talked about in this post amibrokerforum.proboards.com/thread/159/volume-price-buying-selling-volumes?page=2&scrollTo=639
I'm referring to plots like in the example picture below.

Those long horizontal bars you see there disappear if i.e. a basic printf like printf( "%g", 1 ); is placed after PriceVolDistribution or if it is removed.
If being placed before PriceVolDistribution then I get those long bars at several zoom/scroll stages.
Not sure what's causing it.

This also can happen if using Tomasz Janeczko's demo code of the ReadMe of AB 6.13
www.amibroker.com/devlog/wp-content/uploads/2016/04/readme6130.html

If you place i.e.

printf( "%g", 1 );

before PriceVolDistribution then plot behaves differently (i.e. if zooming scrolling) compared to not placing it.

Anyone able to confirm this or facing similar observations?

[fxshrat]

Test code.

Uncomment printf line and compare plot.
You should see a plot change

// a demo showing
// re-implementation of VAP overlay using
// PriceVolDistribution and low-level graphics
RequestTimedRefresh( 1 );

bi = BarIndex();
fvb = Max( 0, FirstVisibleValue( bi ) );
lvb = Max( 0, LastVisibleValue( bi ) );

//printf( "%g", 1 );

mx = PriceVolDistribution( H, L, V, 100, False, fvb, lvb );

GfxSetCoordsMode( 1 );

GfxSelectPen( colorRed );

bins = MxGetSize( mx, 0 );
for( i = 0; i < bins; i++ )
{
   price = mx[ i ][ 0 ]; // price level
   relvolume = mx[ i ][ 1 ]; // relative volume 0..1
   relbar = relvolume * (lvb-fvb+1);
   GfxMoveTo( fvb, price );
   GfxLineTo( fvb + relbar, price );
}

Plot( C, "Price", colorDefault, styleBar );

if( ParamToggle("BuildinVAP", "No|Yes") ) PlotVAPOverlay( 100, 100, colorGreen, 2 );

[andwilson]

Confirmed!

printf placed before PriceVolDistribution interferes with display;

[fxshrat]

It seems that at least all string functions that offer some formating seem to cause side effects on PriceVolDistribution.

So far I have figured: printf(), _TraceF(), StrFormat().

That means that while _TraceF() seems to cause effects i.e. _TRACEF( "%g", 1 );
On the other _Trace() does not seem to cause effects i.e. _TRACE( "" + 1 );

So it seems that those functions with format specifiers cause the effects only.

[fxshrat]

FYI, for people using this function I've got informed by AB that this issue has been confirmed and it has already been fixed in AB 6.14 development version. So the fix will be available in the next public beta release.

So you don't need to send further support mails in regards to this issue regarding AB 6.13.

Thank you to the people participating in this matter and thanks to AB for fixing the issue!