How-to-access-the-current-bid-ask

There is no place for bid/ask in the strategy execution model, the backtester works with OHLC.

https://www.wealth-lab.com/blog/anatomy-of-a-wl7-strategy

Right, obtaining historical bid ask would be difficult. However, if you happen to have a source you could add them as “Named Series” either in an ASCII DataSet or a custom provider.

QUOTE:
... obtaining historical bid ask would be difficult. However, if you ... have a source you could add them as ... a custom provider.

I need some clarification. The WL datatype "BarData" defines an Ask and Bid price. Now I'm not interested in using this in a trading simulation, but wouldn't the BarData object return an Ask or Bid price today if I'm subscribed to IQFeed or a broker streaming datafeed? If not, then it should.

BarData is used in other areas, but does not come into play in the historical data framework.

QUOTE:
BarData is used in other areas, but does not come into play in the historical data framework.

We got off on the wrong foot here. I never meant to store BarData on disk as part of a historical dataset. Let's start over.

I would like to fetch the screaming (real-time) BarData Bid and Ask price from the broker for "the moment". I'm sure the broker's API must give that. Now you're saying WL doesn't have a mechanism to pass this information up to say a Chart?

Well, this feature doesn't fit with the backtesting paradigm. What I use this information for in Active Trader Pro (ATP) is to estimate the Bid-Ask spread and whether or not the Bid price is higher than the Close on the previous day. If it is, I'll place a trade with ATP just before the market opens. So this feature is not about about backtesting, but rather about placing trades just before the market opens.

ATP does provide the pre-market Bid and Ask prices okay, but I have to cut and paste the ticker symbol from WL to ATP for each potential trade to see this information. It would be nice to see this information directly on WL without all the cutting and pasting. Can you help?

You're aware of this too, right?

Thanks a bunch! This info is perfect. I hope checking "Regular Session Only" for the IQFeed provider doesn't affect the streaming Chart data for pre-market prices.

Streaming API offers Real-Time Bid/ASK Price of a Bar .

If it is accessible, It is possible to use to run in real-time strategy on WL ??

If yes, what is the method

No, if it means accessing more than one bid/ask value per bar (e.g. 1-minute bar) as Cone has already shown you in Post #6. If you haven't seen the link in Post #1, it's perfect time.

QUOTE:
Streaming API offers Real-Time Bid/Ask Price of a Bar.
It is possible to use to run in real-time strategy on WL?

A backtest is based on complete bars, not the streaming bar. So obviously you can't use it in a backtest run.

But in Reply# 5, I'm not trying to do a backtest in the first place. I'm just trying to place some premarket buys, and one can certainly identify which stocks are candidates for Reply# 5. Read Reply# 5 again, then post some code to ID those stock candidates discussed there. This should be a good exercise. You can use either "WriteToDebugLog" or "PlaceTrade" when you find a stock that meets Reply# 5 criteria. Remember, we are not backtesting here. We are simply fingering some stock candidates in real time.

---
Off topic, but when the real-time premarket Bid price is higher than the previous Close for a buy-low strategy, it's usually a good buy. Apparently, premarket buyers that are bidding up the price know what they are bidding on. I only wish I knew where they are getting their information? (Perhaps all these premarket buyers read the same newspaper.)

QUOTE:
I hope checking "Regular Session Only" for the IQFeed provider doesn't affect the streaming Chart data for pre-market prices.

When "RSO" is selected for IQFeed, only qualified trades are requested - no "Form T" trades. I'd still expect BarData.StreamingBar to be available with Bid/Ask premarket. Let us know what you find out!

@superTicker
Yes you are correct. This is importantly we use in real-time trading strategy not backtesting. It has nothing to do with backtest.

Coding method members of Bar Bid and Ask using TDA data. Do you know how to solve this problem?

QUOTE:
Coding method members of Bar Bid and Ask using TDA data. Do you know how to solve this problem?

First, I don't use TD Ameritrade. I'm using IQFeed for all my streaming data requirements.

Second, the data source shouldn't matter in the first place. The whole point of writing a streaming data provider for WL is to present to the WL application layer a common way to access this information regardless of who the data provider is. So just follow Reply# 6 and craft your code as shown. Who's providing the data won't matter.

Now there's some "Level I" trading information the broker may provide which WL lacks the API to pass through to its application layer. For example, how many traders have outstanding Bids (buy orders) and how many traders have outstanding Asks (sell orders). If you want that information, then you should use the broker's tools to get that directly. (I suppose one could write a special WL extension to provide this supplemental information, but what would WL do with it in the first place? ... not to mention this is way outside of WL's backtesting paradigm.) Remember, WL is a backtesting platform, not a trading platform.

The Bid method is not working in the code. Does anyone know how to fix it ?

CODE:

using WealthLab.Backtest;
using System;
using WealthLab.Core;
using WealthLab.Indicators;
using System.Collections.Generic;


namespace WealthScript8 
{
   public class MyStrategy : UserStrategyBase
   {
      public MyStrategy() : base()
      {
      }

      public override void Initialize(BarHistory bars)
      {
         StartIndex = 0;
      }

      public override void Execute(BarHistory bars, int idx)
      {
         int index = idx;
         Position foundPosition0 = FindOpenPosition(0);
         //   bool condition0;
         if (idx == bars.Count - 1)
         {
               //   BarData bd = bars.StreamingBar;
             val = bars.StreamingBar.Bid;
         //   val = bars.AveragePriceOHLC[idx];


            PlaceTrade(bars, TransactionType.Buy, OrderType.Limit, val, "Buy At Limit (Bid)");

            ClosePosition(foundPosition0, OrderType.Limit, val, "Sell At Limit (Bid)");

         }

      }


         public override void NewWFOInterval(BarHistory bars)   { }


      private Transaction _transaction;
      private double val;

   }
}

Hi Crash, it’s not intended to be used that way.

The Bid property you’re referencing will only work in a streaming chart, and it returns a snapshot of whatever the bid happens to be at that moment in time.

The Strategy Monitor is not a streaming chart.

@Glitch
Thanks for answer. It would be appreciated if you can in addition answer this question

I need to define the following order:
Buy-Limit at the current Bid
Sell-Limit at the current Ask

CODE:

// How to code these lines correctly ?
val1 = bars.Bid[idx];
val2 = bars.Ask[idx]
PlaceTrade(bars, TransactionType.Buy, OrderType.Limit, val1,  "Buy At Limit (Bid)");
ClosePosition(foundPosition0, OrderType.Limit, val2,  "Sell At Limit (Ask)");

See code in Post #6 and copy its relevant part without omissions. That should fix your compiler errors (but can't do anything about the randomness in the execution of such code, of course).

We don't have anything to buy/sell at the bid/ask, it's not supported and doesn't meld with the backtest-first philosophy of WL.

The code

CODE:
BarData bd = bars.StreamingBar;

always returns "null" even when the StreamingBar is present on the Chart. Why would that be? I'm running WL8 Build 16 and IQFeed Build 6.

CODE:
      public override void Execute(BarHistory bars, int idx)
      {
         if (idx == bars.Count-1)
         {
            BarData bd = bars.StreamingBar;
            if (bd == null)
               DrawHeaderText("No Bid/Ask data streaming", WLColor.Red, 14);
            else
            {
               double difference = bd.Bid - bars.Close[bars.Count-2];
               DrawHeaderText(difference.ToString("Bid-prevClose: 0.00") + (bd.Ask-bd.Bid).ToString("Spread: 0.00"), WLColor.Fuchsia, 14);
               if (difference >= 0)
                  WriteToDebugLog(bars.Symbol + difference.ToString("\tBid > prevClose by\t0.00"));
            }
         }
      }

QUOTE:
always returns "null" even when the StreamingBar is present on the Chart. Why would that be? I'm running WL8 Build 16.

Answered here:

What's your streaming provider? Bars.HasStreamingBar should work if the streaming provider is IB, TD or Alpaca.

QUOTE:
Bars.HasStreamingBar should work if the streaming provider is IB, TD or Alpaca.

My streaming provider is IQFeed Build 6. I thought IQFeed was the very best (includes tick updates). Now I'm getting the feeling it's second rate. The WPF Chart knows about the StreamingBar and the Bid and Ask prices. If WPF knows about this, why doesn't the WL8 framework also know about it? (Yes, I know the two are separate entities, but wouldn't one implement StreamingBar awareness for both in lower level code?)

Can we add StreamingBar awareness to the IQFeed provider, or does this need to be a formal feature request?

Also keep in mind that you won't see a result just because you see the streaming bar - the code needs to run, so you have to wait for the end of interval.

Of course it works for IQFeed already. Wait for the end of bar - test with a 1 minute chart.

QUOTE:
you won't see a result just because you see the streaming bar - the code needs to run, so you have to wait for the end of interval.

So you're saying WPF (the "Chart") will display premarket Bid and Ask prices on the Chart in real-time (which it does; I can confirm that), but the WL8 framework has no idea what WPF is seeing? I assume this arrangement is done for efficiency since WPF has real-time (tick level) awareness and the WL8 framework does not.

I wanted to "try" to get the WL framework to return a list of stocks during the premarket period where their current Bid price was higher than their previous day Close. But you're saying that's impossible with the current design of the WL framework, which only operates on a bar-by-bar instance (and isn't real-time). So to do this, I must use the WPF Chart, which is real-time and operates on a tick-by-tick bases. And that's my only option under the present day architecture.

I'm trying to decide if it makes sense to have WPF flag a "conditional event" where the Bid price meets some special condition defined by the WL framework (and user). But such a real-time "watchdog feature" might just confuse WL users since it falls outside of the bar-by-bar service paradigm they are use to--and I "think" that's a problem--unless you have a slick solution.

You shouldn't use Wealth-Lab at all for this. Make your own little IQFeed client app that does it. You could just run it in a console window and doesn't even need a U.I.

It's not possible with the current product. But it could be a custom extension that would leverage the WL8's framework of historical and streaming data. Creating a custom extension tool would probably be simpler than a complete standalone client app in a console window. We could even develop it for you if you're willing to fund the effort, as part of the new Concierge Development/Support Service.

QUOTE:
... it [the watchdog feature] could be a custom extension that would leverage the WL8's framework of historical and streaming data.

Well, the leveraging part sounds very interesting. So there is a framework-based real-time back end (API) that manages the streaming data.

I'm assuming if I pay for the coding, then I own the source code and can extend it as I want. Let me think about it. I do like the idea of making it an extension so it can integrated into the WL framework at some future point.

>>I'm assuming if I pay for the coding, then I own the source code and can extend it as I want. <<

Yes that’s right.

QUOTE:
Of course it works for IQFeed ... the code needs to run, so you have to wait for the end of interval [such as a new 1-minute bar].

You are correct. It works with IQFeed and 1-minute bars.

What it doesn't do is run immediately when switching to a new symbol. This prevents me from stepping through a dataset of symbols quickly. I have to wait for the next bar each time I change symbols.

It would be nice if WL would immediately establish a new StreamingBar as soon as one switched to a different Chart symbol.