Opening and closing prices

[geoff_olding]

Is there an explicit way to obtain the opening and closing prices for a particular stock for a particular day? It would seem that I can work this out by simply taking the first\last price that I obtain on a particular day, however I would be happier if there was an explicit way of doing so.

[sthornington]

I would suggest a history request going back far enough to include that day. The bar data for that day will have the official open/close prices. (the first and last price you get from time&sales or intraday bars may include afterhours trading, which would not show up for the official open/close prices). The interval for history data is "D" I believe.

Cheers,

Simon.

[geoff_olding]

Thanks - I'll give it a go

[PhelpsDodge]

I am looking at some code where the developer used a "0" in the <number_of_bars> in the syntax below:

historyHandle = esignal.RequestHistory(<symbol>, <interval>, _
<bar_type>, <number_of_bars>, _
<start_time>, <end_time>)

the full parms are ("PD", "D", btDays, 0, -1 -1)

It looks like this was tested successful to having the accurate current price (in the close property), however the open is not right. I don't find any documentation around the use of "O" in the number of bars field. Anyone have any input (I can't play with the code without lots of paperwork because we only have 1 account with API entitled)? TIA

[geoff_olding]

Thanks - I'll do some experiements with calling this routine with different parameters and post my findings.

[PhelpsDodge]

Excellent! Thanks.

[PhelpsDodge]

My process: an EXE requests history and stores the information to a table (so it can be queried for display).

Additional info: it looks like when I start the EXE and make the request, it takes the first open price as the open for the entire interval that I am asking for prices (not the open price for that day). My understanding of the Day interval would be that it would the data spanning that day, however, the open looks like it was since I made the request in the EXE (by design, not sure, maybe so). But my open correlated with an open stock price around 10am yesterday (which is when the app got reloaded after a reboot of that server). The volume also gave me that indication (it was 2.9MM vs 1.9MM so about 2/3 of a day too large). I hope I am seeing this properly, in that, this would at least explain how this made it out of development and onto my production server, in that it worked when running it day to day, but not over a span of days.

My thoughts: I might put a timer to release and re-request at 2am in the morning (not asking for overnite prices, so I should be good). That way, the open would be the true open I beleive.

Any input would be great, I am going to daily stop and start this EXE and I bet it will be fine, but I am looking for a long term solution. TIA

[geoff_olding]

Thanks again, I'll get back to you with my findings

[sthornington]

'day' refers to whether you want X days or X bars of data. You should still search all the results to look for the day you need. If you just need the open of the current day, RequestSymbol and GetBasicQuote might be what you are looking for?

[PhelpsDodge]

My requirements are that I have current and change. Now I could get more complicated and start reviewing my last open. I realy thought the OHLC would do it for me with the RequestHistory.

I originally went up the releaseing each time I got my event triggered (that way I would get that day's open vs the open when I started asking, which could be days/weeks before). However, I also was having the crash issue that has been documented on this forum (plus it wasn't a real nice solution form a programmic "cleanness."

[geoff_olding]

Thanks

[geoff_olding]

OK, I've successfully managed to get the latest day's opening and closing prices, but haven't managed to get any "back history".
E.g. at 10PM on a Thursday, how do I get Wednesday's opening and closing prices? I have tried every combination of parameters I could think of to RequestHistory to no avail.
If anyone thinks they know how to do it, I would be most grateful if they could reply with a complete list of the routines called with their parameters.

[geoff_olding]

I believe I am now successfully receiving back history. The secret appears to be to use the following call in your code (after your call to SetApplication()):
esignal.SetAbsoluteIndexing(1)
I could find no documentation of this call. I came across it when running the following example from Esignal:

http://share.esignal.com/ContentRoot/SimonPrivateDist/simplehist.zip

The following call will return the last 7 days worth of opening and closing prices for the stock “ES”:
esignal.get_RequestHistory(“ES” ,”D”, IESignal.barType.btDAYS , 10, -1 , -1)
There appears to be a strange relationship between the number of days worth of data that you request (10 in this example), and the number of days data that you will actually receive (7 in this example).
I also found that data was not returned for all the stocks for which I requested a history. However, this was not predictable. For example, on my first run I received no data for the stock ‘WMT’, whereas on my 2nd run (which I ran only for the stocks for which data was not returned on the 1st run), I did receive data for ‘WMT’, but not for some other stocks (e.g. ‘ES’). On this run, I received a number of invalid handles in the OnBarsReceived Event.
On another occasion, I received data for all stocks except two (‘ES’ and ‘ONE’).
On another occasion, I received data for only a small number of stocks.

[GenSpoo]

The following call will return the last 7 days worth of opening and closing prices for the stock “ES”:
esignal.get_RequestHistory(“ES” ,”D”, IESignal.barType.btDAYS , 10, -1 , -1)
There appears to be a strange relationship between the number of days worth of data that you request (10 in this example), and the number of days data that you will actually receive (7 in this example).

I'm not entirely sure this is the case, but it seems to be that when you use btDays, weekends are counted. Thus is you request 10 days, you won't get 10 bars as the Saturday and Sunday won't return data. Try esignal.get_RequestHistory(“ES” ,”D”, IESignal.barType.btBARS , 10, -1 , -1) and you should get the 10 days.

I also found that data was not returned for all the stocks for which I requested a history.

I assume you are waiting for the OnBarsReceived, OnBarsChanged, and you check IsHistoryReady after calling RequestHistory to ensure the data isn't already there (as OnBarsReceived won't be called if the history is already there until a new bar is generated). Also, if you haven't already, try upgrading to the 7.7 release candidate as some bugs were fixed in this area (IIRC).

On this run, I received a number of invalid handles in the OnBarsReceived Event.

Are you releasing your handles when your app closes? Or has your app crashed before you released them? If either is the case, then the API will continue to send data for those now "invalid" handles.

Cheers... George

[geoff_olding]

Thanks for your prompt reply.
It looks like it is trying to count weekends, but doesn’t do so correctly. Using btBars as the parameter seems to work.
I wasn’t calling IsHistoryReady, but I am now, however the return value is never true in my tests.
I am calling esignal.ReleaseAllHistory, as per the Multiple Stock Streams Test example. Although undocumented, I am assuming that this routine will, as the name implies, release all history handles. I am calling this when the form initialises, and when it closes down.
I am still perplexed as to why I am not getting all the stocks.