Kate and TSSupport,
At the beggining of this topic I noted that there seems to be three 'bugs' needing some attention. In this topic's discussion, so far, we have only focused on the first one of the three. You recently acknowledged the first mentioned 'bug' as being repeatable, and you gave it a 'label'. Now can we address the other two issues as well?
To refresh your memory I list the three again:
So we have a 'cascade' of three bugs/issues?
(1) An inappropriate request for reloading data, triggered by just changing a display attribute, and
(2) such request for reloads are requesting Real-time data, when there is none available, and
(3) A non-responsive data-request is allowed to CONTINUE-indefinitely, without any chance for user to intervene/cancel.
The second and third 'bugs' in this list (above) were issues that probably don't have a direct connection with the inappropriately triggered download issue. However, in my experience the other two issues were what made the mistakenly-triggered-downloads so VERY 'irratating', namely the triggered download would just hang-up the system.... and then it required a long and waisted time period of closing and re-opening the whole application.
So after this display-attribute-changed->triggering-a-download bug is 'fixed'
I suspect that we will still have to deal with some other kind of 'trigger' of downloads that are going to lead to the same outcome of waiting for data the will 'never' arrive (relatively speaking, of coarse). I say this because there have been other instances of having to wait and wait .... for data the never arrives
![Confused :?](./images/smilies/icon_confused.gif)
. I cannot point to a specific case right now, but I am sure this has occurred, and most likely it has occurred on the weekend when the market(s) are closed.
So consider a situation where the user does ANYTHING to initiate a download on the weekend. Regardless of whether it is the first 'bug' we've been discussing, or any other reason for a download or reload of data. So here is my question for that situation:
How does MC and/or QuoteManager make 'sure' that the kind of data being requested, say on a weekend, can only (maybe) be available from a 'history' server? So if real-time data service is being requested, then the software is 'smart enough' to 'gracefully' convert the request to whatever is really available (if any), and otherwise it must 'gracefully' end the request rather than hang-up the system. Since different data vendors do not all have both history and real-time data-servers, AND even when they do they may NOT be functioning (because of scheduled or non-scheduled reasons).
I'm sure you people have already given very much study and design effort to these issues, but somehow, sometimes, the software still gets into one of those very 'ungracefull' hang-ups waiting for data that will probably not be forthcoming until maybe the next day, or whatever
![Wink :wink:](./images/smilies/icon_wink.gif)
.
So, all of this is to make my point: Please remind the developers that we need a 'better way' to process request for downloads so that we are assured of a 'graceful' handling of those cases where the data being requested is not available. Any comments on whether this is an 'active' action item already, or it is 'waiting' for more 'repeatable' cases?
Cheers,
denizen2