Announcement

Collapse
No announcement yet.

new functionnality request

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • new functionnality request

    Hi,

    I would like to submit a modification to the api.

    could you add to the
    Hooks1BarsReceived(ASender: TObject; lHandle: Integer)
    Hooks1BarsChanged(ASender: TObject; lHandle: Integer)

    events the symbol, which would look like
    Hooks1BarsReceived(ASender: TObject; lHandle: Integer; symbol:string)
    Hooks1BarsChanged(ASender: TObject; lHandle: Integer; symbol:string)

    I'm going to try to explain why:

    after a request history I associate the handle with a symbol so that I can retreive the symbol when I get the event but sometimes the active x goes so fast that I go straight in the event before I could even associate the handle with the symbol. this is very disturbing.

    Is anybody else having the same issue?

    I certainly do not want to associate the data with the handle because I have to free the handle just after retreiving my data and get a new one very often...

    Thanks,
    Nicolas.
    Last edited by nedibe; 03-17-2004, 02:59 PM.

  • #2
    symbol with handle

    nedibe,

    You make a good point. I am currently working with our developers to make some helpful changes in our API that you all find very, very helpful.

    I do have some suggestions for the time being. Since you are dealing with historical information, I am going to make the assumption that speed is not a great concern. If that is true, have the application sleep for a few seconds until the response comes back. Take advantage of the IsHistoryReady() function to determine how long your applicaiton should wait. Secondly, the symbol is in the return data type, so I am not sure why you are associating the handle to the symbol. They do not really need be associated to each other.

    Comment


    • #3
      Hi Robi,

      I do take advantage of the ishistoryready, it's a very useful function. Even if for the time and sales and futures, it stops on symbols with no history yet.

      I also open only one handle at a time I noticed that if I open multiple history handle, my application does not respond anymore.

      Thanks,
      Nick.

      Comment


      • #4
        By the way where is the symbol in a return data type, and which function?

        I would be interested to know it, maybe there is a way to get the symbol from the handle that I ignore?

        Thanks.

        Comment


        • #5
          nedibe,

          I was incorrect is stating that the symbol is in the return data structure. It is not and is marked as an enhancement for the next version. Nonetheless, I think that your issue can be solved without having the symbol returned. If you place all of the symbols you are seeking to retrieve information for in an array, simply loop through the array, make a request, receive a response and store the data as you wish, then go to the next one.

          See page 4-6 in the Reference Guide.

          Robi

          Comment


          • #6
            Re: symbol with handle

            Originally posted by eSignal Robi
            Since you are dealing with historical information, I am going to make the assumption that speed is not a great concern.
            This is not true for me. For historical daily maybe, but when I want to pull up a one minute ES chart because something is happening, I want that back fill (historical data that happened one minute ago, two minutes ago, etc.) instantly. I guess the word "historical" is a little confusing when talking about the current day and intraday data.

            I would avoid using more than one handle, especially for a large list of stocks.


            As a programmer, I gotta just say "huh?"... The purpose of handles in programming is to doing exactly this. Tell the system what you need in as many different requests and in whatever order, and the system hands back an identifier for each request so that when the system returns the data asynchronously and in seemingly random order, you can tell which request the data is being returned for. Or, maybe I am completely misunderstanding what you meant by this?

            BTW, when my app starts it throws about 10 to 15 historical requests at the API quickly without waiting for the first bit of data to come in. I'm not noticing any problems.

            Cheers... George
            Last edited by GenSpoo; 03-18-2004, 01:45 PM.

            Comment


            • #7
              GenSpoo,

              Thanks for finding my error. I meant to state that I would avoid using too many threads in the application - I got the postings mixed. I think that nedibe is having trouble with handling many responses and was offering a way to simplify his code. Maybe you can help him?

              I'm glad to hear that you are sending 10-15 requests without problems. That is the way it is supposed to work.

              Can you tell me what upper limits as far as number of request, number of stocks, etc. that you are facing? It sounds like you're able to do what you want to do (and you're a pretty advanced developer).

              Robi

              Comment


              • #8
                Hi Robi,

                Good advice regarding keeping the number of threads down. For most apps like ours, it only takes two or three threads to keep things humming along smoothly.

                There are really two issues here, and I'm not entirely sure which is the most pressing reason for this thread. There was a bug (as I would call it) in 7.5 where the data received event would trigger before the initial request call returned. Thus, no way to match up the event recieved handle to the request (since the request hadn't had a chance to give us a handle). I think I'm starting to repeat myself. Anyway, I believe this was marked down as being a fixed issue by Simon for 7.6. I myself have not tested for the fix yet as I coded around it in my app.

                If this is the problem that Nick is referring to, my first question to him is whether he is using 7.6 yet. If he is, then we (I) need to see if I misunderstood what the bug that was mentioned as being fixed was.

                In my app I just keep a linked list of objects. Each object contains all the info about a particular request (symbol, request handle, data array, etc.). When I get a barchanged event (or anything else that sends a handle), I just walked the link list until I find the object with the matching handle. If I were to watch thousands of different handles at once, I might not use a linear linked list, but for what I do, this is more than fast enough.

                BTW, I would propose we DO NOT add the symbol to the OnBarsReceived and similar events. That data is redundant (if we are going to keep using handles). Redundancy slows things down. Also, finding a numerical match in a computer search is much much faster than string matching, so I say stick with handles. Just my two cents on this. Of course, all this assumes that "the event received before handle is returned bug" has been (or will indeed be) fixed.

                I haven't pushed the upper limits of the ActiveX control as I stopped my 500+ stock watch style of trading a while back. These days I just keep 10-15 handles running at all times (various futures and indices, time and sales and bars). I could probably work up a little test sometime though and try and watch the full S&P 500 to see what happens.

                Cheers... George

                Comment


                • #9
                  It seems as the error you described is what is causing nedibe's problem. This info really clears things up for me because I didn't see why things weren't working. A linked list is great way to it - a loop will work for the more novice developers.

                  As far as adding the symbol, I think that I still may do it - I think it will help the more novice developers. BUT, I will only add it if we drastically improve the performance overhead required for each and every function call (we think we know the problem, but have not attempted to fix it). Hopefully, this satisfies both your requests.

                  Thanks for your feedback GenSpoo.

                  Comment


                  • #10
                    Originally posted by eSignal Robi
                    As far as adding the symbol, I think that I still may do it - I think it will help the more novice developers. BUT, I will only add it if we drastically improve the performance overhead required for each and every function call (we think we know the problem, but have not attempted to fix it).
                    Hi Robi,

                    If performance is taken out of the equation, I really don't have a problem with the symbol being there. My only other point regarding that would be to say that even with the symbol there, it doesn't give enough information for a lot of folks regarding what the received data is. For example, my app requests daily and 1 minute bars for ES when it starts up. In order for the symbol to be useful in the return argument list, I would also need the period of the data as well (i.e. "D" or "1"). You could also make an argument for every other argument to the Request functions being returned as well. At which point, I would go back to the question related to why bother when we have a handle.

                    What might be nice, IMHO, and could solve this issue is a HandleToSymbol function, or something like that if folks want it. Then they could do something like:

                    onBarsReceived(long handle)
                    {
                    symbol = HandleToSymbol(handle);
                    if (symbol == "ES #F") do this;
                    else if (symbol == "NQ #F") do that;
                    else etc.
                    }

                    That would be my prefered solution to this issue. Of course, then those folks could argue that they are making an extra function call, but if speed is their concern then they should probably be using the handles anyway.

                    Cheers... George

                    Comment


                    • #11
                      Excellent suggestion GenSpoo! That's a good way to provide the same functionality without affecting the current data structure.

                      I am still trying to get a handle on what we currently have, then develop a list of enhancements. I will post the list to the forum to get feedback (and further suggestions). You developers will help drive the new features in upcoming releases.

                      If you have any other suggestions or requests, please start a new thread. I know that it was done before, but now there is a dedicated resource to the evolution of the Desktop API and I need your feedback to ensure that we deliver what you all want.

                      Thanks,

                      Robi

                      Comment


                      • #12
                        Genspoo,

                        A developer is attempting to receive quotes on multiple symbols and I know that you have been able to implement this? Would you be willing to share a piece of your code?

                        Comment


                        • #13
                          Originally posted by eSignal Robi
                          Genspoo,

                          A developer is attempting to receive quotes on multiple symbols and I know that you have been able to implement this? Would you be willing to share a piece of your code?
                          Hi Robi,

                          Is this in reference to another thread and if so which one? Specifically, are we looking for multiple RequestSymbol, RequestHistory, or RequestTimeSales calls? I am assuming RequestSymbol since you specifically say "quotes". Does it matter what language (C++ or C#)? I don't currently have code I can distribute that does multiple symbols (unless people want to start purchasing my app ), but I might be able to modify one of the sample projects I have released before.

                          Cheers... George

                          Comment

                          Working...
                          X