Possible issue with Buy, sell, and net volume - futures io
futures io



Possible issue with Buy, sell, and net volume


Discussion in NinjaTrader

Updated
      Top Posters
    1. looks_one ratfink with 8 posts (4 thanks)
    2. looks_two Cheech with 7 posts (4 thanks)
    3. looks_3 Cilla with 3 posts (2 thanks)
    4. looks_4 memonic with 3 posts (0 thanks)
    1. trending_up 1,895 views
    2. thumb_up 10 thanks given
    3. group 5 followers
    1. forum 22 posts
    2. attach_file 2 attachments




Welcome to futures io: the largest futures trading community on the planet, with well over 125,000 members
  • Genuine reviews from real traders, not fake reviews from stealth vendors
  • Quality education from leading professional traders
  • We are a friendly, helpful, and positive community
  • We do not tolerate rude behavior, trolling, or vendors advertising in posts
  • We are here to help, just let us know what you need
You'll need to register in order to view the content of the threads and start contributing to our community.  It's free and simple.

-- Big Mike, Site Administrator

(If you already have an account, login at the top of the page)

 
Search this Thread
 

Possible issue with Buy, sell, and net volume

(login for full post details)
  #1 (permalink)
 Cheech 
Mesa, AZ/USA
 
Experience: Intermediate
Platform: NinjaTrader, ThinkorSwim
Broker: AMP Futures/CQG, TDA
Trading: Currency Futures, my Harley Davidson
 
Posts: 107 since Jun 2012
Thanks: 43 given, 132 received

I am really perplexed on the condition stated here and request some input.

I recently wrote and posted an indicator to plot buy, sell, net, and total volumes which was based on NT’s BuySellVolume (BSV) indicator. No issues with the indicator as is however, as I was writing another indicator to do more analysis on the buy and sell volume I realized there was something that I completely missed because I did not bother investigating why the BSV indicator categorized the trade volume as either a Buy or Sell. The basis for that decision can be seen in the code below (directly from the BSV indicator in a truncated form) which is in the OnMarketData section:
if(e.Price >= e.Ask)
buys += (Instrument.MasterInstrument.InstrumentType == … (truncated here)
else if (e.Price <= e.Bid)
sells += (Instrument.MasterInstrument.InstrumentType == … (truncated here)
While it looks pretty straight forward notice that both “if” statements test for the “=” condition. This would mean that when the condition is such that the Price = Ask = Bid the volume for that trade is put into the Buy Volume. If the order of condition test were reversed, then that volume under the same conditions would be Sell Volume.

Is this an arbitrary condition or is there a legitimate reason for testing in this order, a question I have raised with NT support (and have not heard back yet other than it is being investigated)? It seems to me that if there isn’t a legitimate reason for testing in this order that the volume, under the mentioned condition, would be skewed to the buy volume.
To see how prevalent this condition might occur, I modified the inprogress of Version 2 of my indicator with the code below (again truncated for clarity and in the same section):
if(e.Price > e.Ask)
buys += (Instrument.MasterInstrument.InstrumentType == … (truncated here)
else if (e.Price < e.Bid)
sells += (Instrument.MasterInstrument.InstrumentType == … (truncated here)
else if ( counter == 0 )
{
buys += (Instrument.MasterInstrument.InstrumentType == … (truncated here)
counter++;
buyCounter++;
}
else
{
sells += (Instrument.MasterInstrument.InstrumentType == … (truncated here)
counter--;
sellCounter++;
}
This code handles the Price=Ask=Sell condition differently by splitting the matches equally between the Buys and Sells, arbitrarily putting the even trades as buys and the odd trades as sells. It also counts the number of times each section of the code was entered for each bar which get printed when the bar is closed. The results surprised me.

Using a 300 tick bar (with tick replay) on over 5000 bars all but 3 or 4 matched the condition. This count included both historical and real time data with the historical making up a major part of the count. The screen shot shows how different the results are with only the code change above.

Unless I am missing something (entirely possible), the issue is that unless there is a justifiable reason for categorizing the trades that meets the condition as Buy volume then it must be arbitrary therefore is not justified. Does this or does it not call into question the value of even using buy/sell volume under these circumstances?

Thoughts!

Attached Thumbnails
Click image for larger version

Name:	Buy-Sell_issue.png
Views:	75
Size:	299.6 KB
ID:	264734  
Started this thread Reply With Quote

Journal Challenge April 2021 results (now extended!):
Competing for $1800 in prizes from Jigsaw
looks_oneMaking a Living with the Microsby sstheo
(106 thanks from 17 posts)
looks_twoSalao's Journalby Salao
(33 thanks from 8 posts)
looks_3Deetee’s DAX Trading Journal (time based)by Deetee
(28 thanks from 11 posts)
looks_4Learning to Profit - A journey in algorithms and optionsby Syntax
(14 thanks from 9 posts)
looks_5Maybe a little bit different journalby Malykubo
(9 thanks from 8 posts)
 
Best Threads (Most Thanked)
in the last 7 days on futures io
Would You Sell Your System?
73 thanks
The Crude Dude Oil Trading System
44 thanks
Big Mike in Ecuador
41 thanks
The New Micro Contract - MICRO BITCOIN coming May 2021
25 thanks
futures io site changelog and issues/problem reporting
24 thanks
 
(login for full post details)
  #2 (permalink)
 ratfink 
Birmingham UK
 
Experience: Intermediate
Platform: NinjaTrader
Broker: TST/Rithmic
Trading: YM/Gold
 
ratfink's Avatar
 
Posts: 3,651 since Dec 2012
Thanks: 17,422 given, 8,403 received


Cheech View Post

While it looks pretty straight forward notice that both “if” statements test for the “=” condition.

Not so, one condition is testing for >= and the other is testing for <=.

i.e. the code caters for prices equal to or worse than the ask, and equal to or worse than the bid.

There are many ways to code this area but the original is an ok one.

Travel Well
Visit my futures io Trade Journal Reply With Quote
 
(login for full post details)
  #3 (permalink)
 Cheech 
Mesa, AZ/USA
 
Experience: Intermediate
Platform: NinjaTrader, ThinkorSwim
Broker: AMP Futures/CQG, TDA
Trading: Currency Futures, my Harley Davidson
 
Posts: 107 since Jun 2012
Thanks: 43 given, 132 received



ratfink View Post
Not so, one condition is testing for >= and the other is testing for <=.

i.e. the code caters for prices equal to or worse than the ask, and equal to or worse than the bid.

There are many ways to code this area but the original is an ok one.

Well, but what about the condition that I mentioned when Bid and Ask are both equal to Price?? It seems to me that the first "if" would detect the equal condition therefore put the volume in the Buy category.

Started this thread Reply With Quote
 
(login for full post details)
  #4 (permalink)
 Cheech 
Mesa, AZ/USA
 
Experience: Intermediate
Platform: NinjaTrader, ThinkorSwim
Broker: AMP Futures/CQG, TDA
Trading: Currency Futures, my Harley Davidson
 
Posts: 107 since Jun 2012
Thanks: 43 given, 132 received


ratfink View Post
Not so, one condition is testing for >= and the other is testing for <=.

i.e. the code caters for prices equal to or worse than the ask, and equal to or worse than the bid.

There are many ways to code this area but the original is an ok one.

Also, maybe you missed the part where the equal tests were removed from the NT tests and fell through to the added code. This would mean the neither the Price was > Ask nor the Price was < Bid, therefore both Bid and Ask were equal to Price.

That is the condition that I'm questioning.

I suppose one could question why the other possible conditions (Price < Ask or Price > Bid) weren't included in any test but neither of those would make sense to me in a completed trade.

Am I still missing something here?

Started this thread Reply With Quote
 
(login for full post details)
  #5 (permalink)
 ratfink 
Birmingham UK
 
Experience: Intermediate
Platform: NinjaTrader
Broker: TST/Rithmic
Trading: YM/Gold
 
ratfink's Avatar
 
Posts: 3,651 since Dec 2012
Thanks: 17,422 given, 8,403 received

Here's my NT7 code (non=PC 'returns' because it's c30% faster)

 
Code
protected override void OnMarketData(MarketDataEventArgs e)
{
    if (e.Price == 0)
        return;
			
    if (e.MarketDataType == MarketDataType.Ask)
    {
        askPrice = e.Price;
        return;
    }
			
    if (e.MarketDataType == MarketDataType.Bid)
    {
         bidPrice = e.Price;
         return;
    }
			
    if (e.MarketDataType != MarketDataType.Last)
	 return;
					
    if (e.Price >= askPrice)
    {
        upVol += e.Volume;
        buying = true;
        return;
    }
			
    if (e.Price <= bidPrice)
    {
        downVol += e.Volume;
        buying = false;
        return;
    }

    if (buying)
    {
        upVol += e.Volume;
        return;
    }

    downVol += e.Volume;
}
As an aside I've stopped using OMD in more recent stuff and use separate Ask and Bid series in OBU where needed.

Travel Well
Visit my futures io Trade Journal Reply With Quote
 
(login for full post details)
  #6 (permalink)
 ratfink 
Birmingham UK
 
Experience: Intermediate
Platform: NinjaTrader
Broker: TST/Rithmic
Trading: YM/Gold
 
ratfink's Avatar
 
Posts: 3,651 since Dec 2012
Thanks: 17,422 given, 8,403 received


Cheech View Post
Am I still missing something here?

Just that Price can be in between a widened spread Ask and Bid (i.e. neutral and therefore not registered in some code variants), or equal to Bid or equal to Ask (and be valid Buys or Sells but therefore forced into your modified code arbitrary second version allocation scheme counters), or less than Bid or greater than Ask and be rightly classed as desperate Sells or Buys. Furthermore Bid/Ask should never meet or cross or the exchange screwed up. Notwithstanding OMD also gets hit with lots of other stuff as well as what you want to see, including zero prices (meaning unchanged Bid/Ask) from some datafeeds.

Hope that and the code helps, TGIF + beer or wine also does, Cheers @Cheech.

Travel Well
Visit my futures io Trade Journal Reply With Quote
The following user says Thank You to ratfink for this post:
 
(login for full post details)
  #7 (permalink)
 Cheech 
Mesa, AZ/USA
 
Experience: Intermediate
Platform: NinjaTrader, ThinkorSwim
Broker: AMP Futures/CQG, TDA
Trading: Currency Futures, my Harley Davidson
 
Posts: 107 since Jun 2012
Thanks: 43 given, 132 received


ratfink View Post
Here's my NT7 code (non=PC 'returns' because it's c30% faster)

 
Code
protected override void OnMarketData(MarketDataEventArgs e)
{
    if (e.Price == 0)
        return;
			
    if (e.MarketDataType == MarketDataType.Ask)
    {
        askPrice = e.Price;
        return;
    }
			
    if (e.MarketDataType == MarketDataType.Bid)
    {
         bidPrice = e.Price;
         return;
    }
			
    if (e.MarketDataType != MarketDataType.Last)
	 return;
					
    if (e.Price >= askPrice)
    {
        upVol += e.Volume;
        buying = true;
        return;
    }
			
    if (e.Price <= bidPrice)
    {
        downVol += e.Volume;
        buying = false;
        return;
    }

    if (buying)
    {
        upVol += e.Volume;
        return;
    }

    downVol += e.Volume;
}
As an aside I've stopped using OMD in more recent stuff and use separate Ask and Bid series in OBU where needed.

Sorry, maybe I'm being dense here but I would like to see those rules in English as I still don't understand what it is you are doing and under what premise. I'm not saying they are wrong or anything but it still isn't clear to me that when a trade is completed when Bid=Ask=Price as per the NT code under what rules can be it classified as either a buy or sell trade

Started this thread Reply With Quote
 
(login for full post details)
  #8 (permalink)
Cilla
Oxford UK
 
 
Posts: 10 since Apr 2019
Thanks: 4 given, 5 received


Cheech View Post
Also, maybe you missed the part where the equal tests were removed from the NT tests and fell through to the added code. This would mean the neither the Price was > Ask nor the Price was < Bid, therefore both Bid and Ask were equal to Price.

That is the condition that I'm questioning.

I suppose one could question why the other possible conditions (Price < Ask or Price > Bid) weren't included in any test but neither of those would make sense to me in a completed trade.

Am I still missing something here?

I think it would mean that the Price was somewhere between the Bid and the Ask, not that the Bid and Ask were the same.

Reply With Quote
The following user says Thank You to Cilla for this post:
 
(login for full post details)
  #9 (permalink)
Cilla
Oxford UK
 
 
Posts: 10 since Apr 2019
Thanks: 4 given, 5 received


ratfink View Post
Just that Price can be in between a widened spread Ask and Bid (i.e. neutral and therefore not registered in some code variants), or equal to Bid or equal to Ask (and be valid Buys or Sells but therefore forced into your modified code arbitrary second version allocation scheme counters), or less than Bid or greater than Ask and be rightly classed as desperate Sells or Buys. Furthermore Bid/Ask should never meet or cross or the exchange screwed up. Notwithstanding OMD also gets hit with lots of other stuff as well as what you want to see, including zero prices (meaning unchanged Bid/Ask) from some datafeeds.

Hope that and the code helps, TGIF + beer or wine also does, Cheers @Cheech.

Sorry - newbie error - missed Ratfink's post!

Reply With Quote
The following user says Thank You to Cilla for this post:
 
(login for full post details)
  #10 (permalink)
 ratfink 
Birmingham UK
 
Experience: Intermediate
Platform: NinjaTrader
Broker: TST/Rithmic
Trading: YM/Gold
 
ratfink's Avatar
 
Posts: 3,651 since Dec 2012
Thanks: 17,422 given, 8,403 received



Cilla View Post
Sorry - newbie error - missed Ratfink's post!

No problem, you clarified a point I only covered indirectly anyway.

Travel Well
Visit my futures io Trade Journal Reply With Quote
The following user says Thank You to ratfink for this post:
 
(login for full post details)
  #11 (permalink)
 m20alberto 
sevilla España
 
Experience: Intermediate
Platform: Ninjatrader
Trading: indicadores
 
Posts: 26 since Mar 2016
Thanks: 2 given, 7 received

Hello, a possible solution would be telling you that the previous candle close if the bid vol is "bearish" adds to the sales, and the vol. of ask subtracts purchases, and vice versa, according to the closing of the previous candle.
I'm not a programmer, can you code it for N8 ???? Thank you.

Reply With Quote
 
(login for full post details)
  #12 (permalink)
 ratfink 
Birmingham UK
 
Experience: Intermediate
Platform: NinjaTrader
Broker: TST/Rithmic
Trading: YM/Gold
 
ratfink's Avatar
 
Posts: 3,651 since Dec 2012
Thanks: 17,422 given, 8,403 received


m20alberto View Post
Hello, a possible solution would be telling you that the previous candle close if the bid vol is "bearish" adds to the sales, and the vol. of ask subtracts purchases, and vice versa, according to the closing of the previous candle.
I'm not a programmer, can you code it for N8 ???? Thank you.

There isn't really a problem needing a solution, only a misunderstanding.

I'm not currently working with NT8 but the code ideas are just the same, in the code I posted the 'buying' flag does what you suggest with a candle close, only tighter. I would think there are plenty of other correct NT8 solutions already out there, sorry I can't help more at this time.

Travel Well
Visit my futures io Trade Journal Reply With Quote
 
(login for full post details)
  #13 (permalink)
 m20alberto 
sevilla España
 
Experience: Intermediate
Platform: Ninjatrader
Trading: indicadores
 
Posts: 26 since Mar 2016
Thanks: 2 given, 7 received

I want to make a vol indicator, but I'm not a programmer, someone can help me ... I've been in the markets for years and I'm looking for a way to "know or approach" contracts that are not closed and that are stuck ... for N8

Reply With Quote
 
(login for full post details)
  #14 (permalink)
Cilla
Oxford UK
 
 
Posts: 10 since Apr 2019
Thanks: 4 given, 5 received


ratfink View Post
No problem, you clarified a point I only covered indirectly anyway.

Thank you, Ratfink. I also have a question about onMarketData, but it's a little "involved" so might take me a while to work out a clear description of my issue - I'll put it as a separate post.

Reply With Quote
 
(login for full post details)
  #15 (permalink)
 Cheech 
Mesa, AZ/USA
 
Experience: Intermediate
Platform: NinjaTrader, ThinkorSwim
Broker: AMP Futures/CQG, TDA
Trading: Currency Futures, my Harley Davidson
 
Posts: 107 since Jun 2012
Thanks: 43 given, 132 received


Cilla View Post
I think it would mean that the Price was somewhere between the Bid and the Ask, not that the Bid and Ask were the same.


I thought about some more after the post and realized I made an incorrect assumption that they would be equal and gave it more thought. There are a number of possible combinations of Bid$, Ask$, and Price tests, some of which I believe to be irrational. So, I changed the code to test for Bid = Ask just to see if that condition really occurred and although in the test that I ran the counts of that condition were in the minority (but did occur) the rest would fall into some other categories some of which would be the in between category you mentioned.

Knowing what I do now I will do individual tests for each of what I believe to be "rational" combinations while still counting the others and see what happens. If no counts show up in either the other category or what I tested as a rational combination then between the two at least I would have identified the "rational" combinations that could occur.

The next thing would to be determined what might be rules for counting the volume as either a buy or sell for each condition and see how it matches to what the NT code does now. I suspect that the only fall out would be the original issue of the Bid=Ask = Price condition, which although it does not happen frequently (at least with the ES), it does happen. For that condition I have no idea why one choice (buy vs. sell) would be more correct than the other.

Also, the test was using historical data (with tick replay) which may or may not be the same as the real time data, potentially a whole other issue.



*** Update ***

Just finished the additional combination tests. Checking again 30 days of tick replay data against the ES there were hits on 3 conditions; (1) Price equal ask and Price Greater than Bid, (2) Price Equal Bid and Price Less than Ask, and, (3) Price equal to both Bid and Ask.

Concerning the last condition of the 44,000 plus bars processed (unknown number of trades, there were only 85 hits with a volume of 9,907 against a total volume of 2.8 M, a very small percentage. I'll collect some data on real time trades but unless something is amiss I suspect it too will have a low percentage. With such a small percentage of hits I doubt NT will make any changes so unless something is radically off with the real time data I'll consider this issue closed.

Started this thread Reply With Quote
The following user says Thank You to Cheech for this post:
 
(login for full post details)
  #16 (permalink)
 ratfink 
Birmingham UK
 
Experience: Intermediate
Platform: NinjaTrader
Broker: TST/Rithmic
Trading: YM/Gold
 
ratfink's Avatar
 
Posts: 3,651 since Dec 2012
Thanks: 17,422 given, 8,403 received

@Cheech, @Cilla

As I just posted in another thread the point being missed is that the relative position of Ask and Bid is only relevant when the Last event occurs, regardless of how many times or where either or both of them move prior to the next Last event. Hence the need for local variable storage for correct handling.

Travel Well
Visit my futures io Trade Journal Reply With Quote
The following user says Thank You to ratfink for this post:
 
(login for full post details)
  #17 (permalink)
 Cheech 
Mesa, AZ/USA
 
Experience: Intermediate
Platform: NinjaTrader, ThinkorSwim
Broker: AMP Futures/CQG, TDA
Trading: Currency Futures, my Harley Davidson
 
Posts: 107 since Jun 2012
Thanks: 43 given, 132 received


ratfink View Post
@Cheech, @Cilla

As I just posted in another thread the point being missed is that the relative position of Ask and Bid is only relevant when the Last event occurs, regardless of how many times or where either or both of them move prior to the next Last event. Hence the need for local variable storage for correct handling.

Anything done in either my testing or the indicator was only on the Last event as I wasn't concerned what happened prior to that time.

Started this thread Reply With Quote
The following 2 users say Thank You to Cheech for this post:
 
(login for full post details)
  #18 (permalink)
 ratfink 
Birmingham UK
 
Experience: Intermediate
Platform: NinjaTrader
Broker: TST/Rithmic
Trading: YM/Gold
 
ratfink's Avatar
 
Posts: 3,651 since Dec 2012
Thanks: 17,422 given, 8,403 received


Cheech View Post
Anything done in either my testing or the indicator was only on the Last event as I wasn't concerned what happened prior to that time.

Yes, I just checked and NT8 is giving you the e.Ask and e.Bid prices separately in the event so that makes sense, NT7 did not do that.

Travel Well
Visit my futures io Trade Journal Reply With Quote
 
(login for full post details)
  #19 (permalink)
 ratfink 
Birmingham UK
 
Experience: Intermediate
Platform: NinjaTrader
Broker: TST/Rithmic
Trading: YM/Gold
 
ratfink's Avatar
 
Posts: 3,651 since Dec 2012
Thanks: 17,422 given, 8,403 received

@Cheech, @Cilla

Thinking more about this issue it would seem that we are missing the time precedence factor, such that in the case where Bid = Ask = Price is *really* seen, then it must be the most recent event change that takes precedence (i.e. whichever of Bid or Ask changed right before the Last event. That should take the arbitrary factor out of the volume allocation that you have seen.

As such the NT8 OMD interface cannot be used in its object form (with e.Bid and e.Ask delivered concurrent with the 'Last' event e.Price) and it must be used in the old NT7 manner with a new precedence flag needed for both versions. (Here I am assuming that NT8 does also deliver separate events for Bid and Ask as well as Last in the same way as NT7.)

It may of course just be a historical data artefact (which NT8 was supposed to correct with millisecond timestamping since NT7 is flawed in both Historical and Market Replay modes for Bid/Ask behaviour).

However this NT8 caveat:

Prevents this issue being addressed in Tick Replay mode anyway, since we cannot separate the order of Ask and Bid arrival - end of story.

Regardless of historical data issues the time precedence should be usable in NT7 and NT8 in live running, although in the grand scheme I agree it is not likely to be a big deal, but it is more interesting than I first thought.

Cheers

Travel Well
Visit my futures io Trade Journal Reply With Quote
The following user says Thank You to ratfink for this post:
 
(login for full post details)
  #20 (permalink)
 memonic 
Jaén Spain
 
Experience: Intermediate
Platform: NinjaTrader
Trading: Emini ES
 
Posts: 8 since Aug 2017
Thanks: 9 given, 0 received


Cheech View Post
Anything done in either my testing or the indicator was only on the Last event as I wasn't concerned what happened prior to that time.

Hi Cheech
thanks for your indicator. I would like to use in strategy backtesting with Tick replay. Nt8 ask me an erro "on state change"

fpgBuySellNetVolume_V21 = fpgBuySellNetVolume_V2(Close, fpgBuySellNetVolumeMAsType.EMA, 15, 50, 0, fpgBuySellNetVolumeMAsSmoothType.SMA, 5, 0, 0);

Do you know where could be the error.
thanks in advance

Reply With Quote
 
(login for full post details)
  #21 (permalink)
 Cheech 
Mesa, AZ/USA
 
Experience: Intermediate
Platform: NinjaTrader, ThinkorSwim
Broker: AMP Futures/CQG, TDA
Trading: Currency Futures, my Harley Davidson
 
Posts: 107 since Jun 2012
Thanks: 43 given, 132 received


memonic View Post
Hi Cheech
thanks for your indicator. I would like to use in strategy backtesting with Tick replay. Nt8 ask me an erro "on state change"

fpgBuySellNetVolume_V21 = fpgBuySellNetVolume_V2(Close, fpgBuySellNetVolumeMAsType.EMA, 15, 50, 0, fpgBuySellNetVolumeMAsSmoothType.SMA, 5, 0, 0);

Do you know where could be the error.
thanks in advance


Hi:

Please give me more setup details (instrument, indicator, chart settings, etc.) and I'll try to replicate the problem on my system.

Thx

Started this thread Reply With Quote
The following user says Thank You to Cheech for this post:
 
(login for full post details)
  #22 (permalink)
 memonic 
Jaén Spain
 
Experience: Intermediate
Platform: NinjaTrader
Trading: Emini ES
 
Posts: 8 since Aug 2017
Thanks: 9 given, 0 received

Hi cheech.

Thanks for your answer, at following you can view the strategy, the problen is onstatechage

regards




#region Using declarations
using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.ComponentModel.DataAnnotations;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.Windows;
using System.Windows.Input;
using System.Windows.Media;
using System.Xml.Serialization;
using NinjaTrader.Cbi;
using NinjaTrader.Gui;
using NinjaTrader.Gui.Chart;
using NinjaTrader.Gui.SuperDom;
using NinjaTrader.Gui.Tools;
using NinjaTrader.Data;
using NinjaTrader.NinjaScript;
using NinjaTrader.Core.FloatingPoint;
using NinjaTrader.NinjaScript.Indicators;
using NinjaTrader.NinjaScript.DrawingTools;
#endregion

//This namespace holds Strategies in this folder and is required. Do not change it.
namespace NinjaTrader.NinjaScript.Strategies
{
public class estrategiabuyselpower : Strategy
{
private NinjaTrader.NinjaScript.Indicators.Cheech.fpgBuySellNetVolume_V2 fpgBuySellNetVolume_V21;

protected override void OnStateChange()
{
if (State == State.SetDefaults)
{
Description = @"Enter the description for your new custom Strategy here.";
Name = "estrategiabuyselpower";
Calculate = Calculate.OnBarClose;
EntriesPerDirection = 1;
EntryHandling = EntryHandling.AllEntries;
IsExitOnSessionCloseStrategy = false;
ExitOnSessionCloseSeconds = 30;
IsFillLimitOnTouch = false;
MaximumBarsLookBack = MaximumBarsLookBack.Infinite;
OrderFillResolution = OrderFillResolution.Standard;
Slippage = 1;
StartBehavior = StartBehavior.WaitUntilFlat;
TimeInForce = TimeInForce.Gtc;
TraceOrders = false;
RealtimeErrorHandling = RealtimeErrorHandling.StopCancelClose;
StopTargetHandling = StopTargetHandling.PerEntryExecution;
BarsRequiredToTrade = 20;
// Disable this property for performance gains in Strategy Analyzer optimizations
// See the Help Guide for additional information
IsInstantiatedOnEachOptimizationIteration = true;
}
else if (State == State.Configure)
{
SetStopLoss(CalculationMode.Ticks, SLc);
//SetParabolicStop(CalculationMode.Ticks, SLc);
SetProfitTarget(CalculationMode.Ticks, PTc);
}
else if (State == State.DataLoaded)
{
fpgBuySellNetVolume_V21 = fpgBuySellNetVolume_V2(Close, fpgBuySellNetVolumeMAsType.EMA, 15, 50, 0, fpgBuySellNetVolumeMAsSmoothType.SMA, 5, 0, 0);
}
}

protected override void OnBarUpdate()
{
if (BarsInProgress != 0)
return;

if (CurrentBars[0] < 1)
return;

// Set 1
if ((IsRising(fpgBuySellNetVolume_V21.FastNetMA[0])==true)
{
EnterLong(Convert.ToInt32(DefaultQuantity), "");
}


}

#region Properties
[NinjaScriptProperty]
[Range(double.MinValue, double.MaxValue)]
[Display(Name="Limite", Order=1, GroupName="Parameters")]
public double Limite
{ get; set; }

[NinjaScriptProperty]
[Range(int.MinValue, int.MaxValue)]
[Display(Name="Uno", Order=2, GroupName="Parameters")]
public int Uno
{ get; set; }

[NinjaScriptProperty]
[Range(int.MinValue, int.MaxValue)]
[Display(Name="Dos", Order=3, GroupName="Parameters")]
public int Dos
{ get; set; }

[NinjaScriptProperty]
[Range(int.MinValue, int.MaxValue)]
[Display(Name="periododema", Order=4, GroupName="Parameters")]
public int periododema
{ get; set; }

[NinjaScriptProperty]
[Range(int.MinValue, int.MaxValue)]
[Display(Name="PTc", Order=5, GroupName="Parameters")]
public int PTc
{ get; set; }

[NinjaScriptProperty]
[Range(int.MinValue, int.MaxValue)]
[Display(Name="SLc", Order=6, GroupName="Parameters")]
public int SLc
{ get; set; }
#endregion

}
}

Reply With Quote
 
(login for full post details)
  #23 (permalink)
 memonic 
Jaén Spain
 
Experience: Intermediate
Platform: NinjaTrader
Trading: Emini ES
 
Posts: 8 since Aug 2017
Thanks: 9 given, 0 received


Cheech View Post
Hi:

Please give me more setup details (instrument, indicator, chart settings, etc.) and I'll try to replicate the problem on my system.

Thx

hi cheech do you have any idea what the problem is?

thanks in advance

Reply With Quote


futures io Trading Community Platforms and Indicators NinjaTrader > Possible issue with Buy, sell, and net volume


Last Updated on July 12, 2019


Upcoming Webinars and Events
 

NinjaTrader Indicator Challenge!

Ongoing
 

Journal Challenge w/$1,800 in prizes!

April

Seven Trading Mistakes Solved With Smart Trading Tools w/Brannigan Barrett

Elite only
     



Copyright © 2021 by futures io, s.a., Av Ricardo J. Alfaro, Century Tower, Panama, +507 833-9432, info@futures.io
All information is for educational use only and is not investment advice.
There is a substantial risk of loss in trading commodity futures, stocks, options and foreign exchange products. Past performance is not indicative of future results.
no new posts