Then that can be ruled out. I asked because that causes an error in Setup with me (most probably because it is installed but not connected).
“Unexpected Error”. And the StreamDeck is all about triggering PRT functionalities via Shortcuts, that’s why. But ruled out, I’d say.
I have had an error message show up frequently on the Settings window, likely same as you show in your screen shot, but I can’t read Dutch. I’ll copy and post here next time I see the error message.
(Hey as an aside, I’ve been watching a Dutch Series (using subtitles) called ‘The Swingers’! I’m enjoyng it! It’s not at all as the title may suggest, one episode involved swinging and it was because the neighbour wanted a baby and the husband was infertile! 🙂 )
Here’s another oddity that happens, I think only on this one Account!
When I first go into the ProOrder AutoTrading window it shows as blank (see attached) but clearly Systems are running! When I click on the + on the non-running menu bar then all the Systems show / pop up!
This is the same Account I lost 74 non-running Systems on Monday night! The two non-running Systems not lost are / were showing the yellow warning triangle!!
When I first go into the ProOrder AutoTrading window it shows as blank (see attached) but clearly Systems are running!
Oh wait. For months I had planned to create a topic in here and ask how on earth the click-sequence should be to open these two treeviews as quickly as possible (because most often they are both closed). I still don’t know the sequence, but the number of clicks (on the plus and minus sign) to do it, will on average be 10 ?
I don’t understand what you are saying above? 10 clicks??
I only need to click once on the + on the non-running menu and all my Systems appear.
It has been like this for many many months, could be since v11, yes most likely since v11.
I don’t think the ‘initial blank screen’ (see 2 posts above) is related to me losing Systems (I say losing because I don’t consider that I am deleting by mistake … something weird is happening).
Ok Thanks. I will open a topic for that when I have some spare time.
N.b.: Prerequisite is that all starts with a blank screen like you see below, but then with minuses instead of pluses. This situation (which is wrong in the first place – minuses should collapse hence show the lists in the first place) may occur after startup.
Same thing just happened again – Flash Disconnect – it happens that quick that there is not even enough time to read the warning message!
This time I took screenshot of the ticked boxes after the Flash Disconnect! NONE of the boxes were ticked before the Flash Disconnect, but see the box ticked above the non-running window (non-run menu tick box) ! But none of the non-running Systems are ticked. Now if you tick the non-run menu tick box normally then all of the non-running Systems are automatically ticked, BUT not after a weird Flash Disconnect!!
I did the same as this morning … stopped a running System with a trade open showing a loss. Then I deleted that same System from the non-running section using the bin icon then got the Flash Disconnect then got ALL the boxes ticked in the running section and the SINGLE non-run menu tick box … see attached.
It’s restored my confidence that I am not losing it after all!!!! 🙂 (never thought I was anyway, just trying to make you laugh!! 🙂 )
Just done same action as above (I’m having a clear out of old Systems) but on a different Account … same Flash Disconnect followed by same ticked boxes as on the screenshot above!
We should be confident that it is related to that “reset”. But let’s also agree that this reset in itself can be caused by different environmental happenings, because I did not have anything running or started / stopped something. But the reset I sure had with the same exhibit (I did not pay notice to the detailed combination of the checkboxes you just nicely laid out).
Look below. Did you every see that weird combination of colours ? The white/grey-ish should not be. This is visible in all my platforms during start up. As if they changed something in the start-up sequence (which is partly similar to a reset). Thus, it happens to several forms (windows) briefly and then goes to the normal by you set color (green in this case for me). But for this particular form it some times sticks, like in this case. Do notice that I had it collapse, thus (?) that something could not “touch” it to give it its normal colour and now it sticks ? Later (I am confident) it will be normally green, but I can not invoke that that I know. However, a reset may …
This exhibit is there since ? … 2 months or so ? prior to that it never happened. Don’t ask me whether it comes along with the checkbox thing, but what if you noticed the same since a couple of months ? It could be convenient for PRT to know where to look (what part of the software they changed and which may relate to the checkbox thing).
Btw, this is a typical thing that may happen because of video drivers. But believe it or not, more stuff depends on video drivers, because it is about “capability”. I did not change a thing. But I (we all these days) are subject to W10 updates. So it is not even so that PRT is the cause of this. Obviously, it is also not so that this colour-thing is related in the first place. But I can see that it is something that “sticks” which should not, and this is often related to “capability” (speed, possibility to synchronise within the given time).
Probably this post is about nothing important. Still I notice it and it will definitely be so that it is unintended. Plus, I regard PRT 100% decent regarding these kind of issues. So graphically it is “the best”. Resetting/Saving/Restoring it is the worst. And the checkboxes are in that realm. How is it that a few weeks ago I was unable NOT to have the all checked after startup ? (it’s all written in this topic) while today I would not be able to have them checked at startup ? … so possibly someone is even reading along with us, TELLS NOTHING but is trying to solve it ? PRT never ever tells anything about changes. The most annoying of it all …
Regarding this resetting, try to keep this in the back of your mind :
You may recall that elsewhere I told about this resetting and how this was built in in certain places (of situations happening) because I myself asked for that. This is particularly about PRT not knowing the status of an order, and a reset will incur for a recall to the broker of the status of all orders. So it is a synchronisation action. Now, with this thus in the back of your mind, always think of what needs to happen regarding this, if you do “something” which is more weird. Like killing a Strategy. It would be a rough action, incurring uncertainty about the status of all orders (you could have thrown out 69 Strategies at once) and so it would be good habit to imply this “re-sync”. So this is why you see this happening (no need to bet about it – haha). Now :
You may just as well flip that setting that allows to let the position be open (never mind your current setting) and see a different behaviour when you apply the same again (your last two posts). Thus, if nothing needed to be killed, there is also no reset necessary … that it … won’t it ? I am not 100% sure because I can’t think of Limits etc. which may be bound to the Strategy. But because at this moment I can’t think of any, no reset will be necessary if I am right. And thus when positions are allowed to stay, you won’t see checkbox changes.
Off topic regarding the subject above : It can well be that a couple of weeks back I had open positions in this account, and that that causes the checkboxes to be checked at startup. I know, this does not make sense, but assumed PRT did not change a thing regarding this (and are not trying to solve anything regarding this (I did not file a bug here)), it has to be something which caused that. I should be able to trace this back.
Off topic regarding the subject above : It can well be that a couple of weeks back I had open positions in this account, and that that causes the checkboxes to be checked at startup. I know, this does not make sense, but assumed PRT did not change a thing regarding this (and are not trying to solve anything regarding this (I did not file a bug here)), it has to be something which caused that. I should be able to trace this back.
All right. I did not have open AutoTrade positions (on Jan 11 regarding my posts about it in this topic). But I had a couple of manual open positions. And I don’t have those now either. So that could be a difference regarding the checkboxes defaulting to checked at startup.
I get this message often … “broker does not know the status of your last order” (or similar words).
I wish I knew what to do (re code on individual strategies) to stop this happening as it corrupts my Forward Test performance history as the strategies stop each time I get that error message!
I just checked and I have a manual position open on my Demo SB Account. I left it open for now and I will check my Demo CFD Account later and report back.
Maybe we are getting somewhere/ narrowing it down … with or without PRT! 🙂
But I am none the wiser (Nicolas did not respond) so I keep getting the same error message!
OK, for what I know about that situation :
This should not be related to what I described; what you describe is merely the other way around (I have had that message too);
What I describe is that ProRealTime is uncertain about the status of your order. This in itself is (for what I know) in 100% of cases the fault of the broker, he mostly not timely responding. Think of PRT handing an order, the broker not responding for 10 seconds, then PRT must give up because this “can’t be” (I would agree with that). Well, I have examples of 90 seconds the broker not responding, and I think I told elsewhere that I can copy such a situation each day early in the morning for Futures (say 6am my time). The “reset” is then a general means for the platform to re-call the status of all orders, so all will be in sync again. Well, not, because what happens in that 6am situation is that the broker does not tell anything of a new order, so PRT removes it from the chart (after it has been grey for a few seconds), but voilá, after one minute the order appears after all. A real mess which PRT can’t solve BUT what the resets are supposed to be for. This is the fault of the broker.
The message you refer to seems to spring from I-don’t-know wild actions in the program code, which collide with what a broker is doing. At least that is my thinking. In my case this is always about Market orders, and I think something along the lines of : my order was not filled, so at the next bar-call the code re-attempts (hey, I *did* give that market order !) and meanwhile the broker has filled the order, me attempting the same for actually same order …
This is hard to explain, but each order receives a unique idea and a Market order is supposed to just have that, assuming it gets filled.
1
2
3
4
5
6
7
IfnotOnMarketthen
Buy10sharesatmarket
endif
// Next second back to above. It will still say not OnMarket when no fill
// but the order is at the broker already !!
// And acting like OnMarket while not for real will also not work well. :-(
I can recognize that when my program itself becomes more “hectic” (too hard to explain), this message pops out sooner (more easy). I think I can see that this correlates with higher volatility. This too is something PRT should be able to solve, because it is a most annoying thing. But at PRT there’s hardly anyone really trading, so how can they know and how can they copy the behaviour …
Hey you there, can’t you try to obtain 4 pieces of DAX for only over 1.5million euros, of which I predict you that the broker (or exchange ?) has issues with at 6 am ?
Now you know at least one (theoretical) reason why things remain unsolved.
If I as a software developer can’t copy the behaviour, I should be ensured that I won’t solve the problem. And in this case it is about money, so I’d better let it be (nobody loses money) before *I* will be held responsible for your money … … … But the sad case about this example, is that when I attempt 4x DAX which seemed not to work out (no order appears), I end up with 8x or even 12x (because of my re-attempts). And might someone from PRT ever read this, I keep on referring to this as The Zalando Experience, because that is where it happened the first time. The experience was a happy one, because Zalando (after March 2020) rose and rose and rose and I was a happy camper from the second it happened. But it shouldn’t happen to anyone, because it can also drop in a second and you won’t be able to get out because you MUST have back that money and don’t know what to do really. And so you will lose more. Call the broker or PRT with this issue and that you want back your money, and they will “be able to” tell you that you should have gone out earlier. Yeah, sure.
Btw, yes, I am a Marked man, because I never ever complain (nag) about these things. But you really don’t want to know how much $ it has costed me.
The other day -in a scratched post (I did not post it)- I mentioned the example of losing 25K in 30 seconds because the order did not want to come through and actually PRT failed on it. I don’t complain, but …
(but I think I will get it back again – hahaha)
To help us continually offer you the best experience on ProRealCode, we use cookies. By clicking on "Continue" you are agreeing to our use of them. You can also check our "privacy policy" page for more information.Continue
.
