Developers! Do you even test what you create? - page 5
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
Please answer 2 simple questions:
1. If the trade is done, should I get TRADE_TRANSACTION_DEAL_ADD --> ORDER_STATE_STARTED or not?
2. After the message that the order has been modified TRADE_TRANSACTION_ORDER_UPDATE --> ORDER_STATE_REQUEST_MODIFY
should I get the TRADE_TRANSACTION_ORDER_UPDATE --> ORDER_STATE_PLACED message or not?
Although the question is not for me, but I'll try to answer it :)
Working with events means that expected events may not happen, for example, you may get lost in transit, or you may not wait in queue, and very few things can happen (including terminal's bug). So you need to back up your event model to work reliably. I, for example, build a waiting list for especially important events and control it not only by related events, but also by indirect confirmation that the expected event has happened.
Artem, I don't want to take you at your word, but it's not a
a deliberate move on your part. The fact is that the current bugs will not
will not allow you to write an EA according to my TOR.
Right now my Expert Advisor is working and brings profit of 1% per day.
I wanted to thoroughly upgrade it, but because of bugs in
MT-5 errors do not work.
And second, what is the upfront fee if we are testing on your account with 5000 euro depo?
I always put my preliminary terms. After agreeing to my preliminary conditions, I read ToR, then I say - it will cost less / will cost more / not realistic. After agreement we discuss ToR down to the smallest detail. And only after complete mutual understanding, we confirm our willingness to work. During the work closely work with the customer. Always in touch. We continue discussions and clarifications on each of the "cogs" of the algorithm. Until the next "cog" is honed and tested, we will not proceed to the next one. Before passing the final solution, I test the algorithm for errors myself, but only in the tester, and only for the correctness of the algorithm. Testing on the account - only for bugs and only by the customer, and only at his expense.
I understand that this is a conversation about nothing. Let's get it over with.
P/S What high level language do you speak?
Have we started a "pissing contest" already?
I'll tell you, it's a swear word.
Good afternoon, Yuri!
Yes, of course you are right, an event may not come once, well twice or even three times.
But they come, but OTHER!
Can you please tell me how do you control that the order was modified (without server's response)?
Have we started a "pissing contest" already?
I'm answering - with a swear word.
Artyom, you have a twisted understanding of questions!
I simply thought that it is possible to offer you to write (instead of the adviser)
I just thought I could offer you to write (instead of advisor) a small terminal for Plaza II, it will be difficult...
Artyom, you have a twisted understanding of the questions!
I just thought that it is possible to offer you to write (instead of the adviser)
I just thought I could offer you to write (instead of advisor) a small terminal for Plaza II, it would be hard to do it alone...
I apologize. I have understood you wrong. Tiredness is affecting me - I am working on a complicated order, I do not sleep much....
Thanks for the offer. My plans are a little different. I think I'll pass.
Although the question is not for me, but I'll try to answer it :)
Working with events means that the expected events may not happen, for example, get lost on the way, or the queue may not wait, and very few things can happen (including a terminal bug). So you need to back up your event model to work reliably. For example, I create for very important events waiting list and control it not only by related events, but also by indirect confirmation that the expected event has happened.
No, it doesn't work. The event model has to be absolutely reliable. If the event didn't get there, it didn't happen. On FORTS the events should be executed particularly clearly because order changes can generate dozens of trades.
Thank you too, but I think I'll
"to Plaza II.
I don't recommend this. It's much easier to fix this bug with MQ than to build a new terminal for Plaza by yourself. Get bogged down in endless fixes of bugs and writing the "standard functionality". I'm speaking from my own experience. Partially developed one of such self-made complexes based on Stock# - the result is another "bicycle" for specific tasks. You'd better fight with the support service, it will be easier and cheaper.
Good afternoon, Yuri!
Yes, of course you are right, an event may not come once, well twice or even three times.
But they come, but OTHER times!
Nevertheless, those one, two or three times can happen at the most inopportune moment, which is exactly what happened to you. The Help, by the way, covers this in detail. The developers do not recommendto build your trading algorithm on waiting for some trade transactions to arrive after others.
One trade request manually sent from the terminal or via OrderSend()/OrderSendAsync() functions can generate several consecutive transactions on the trade server. The order of these transactions arrival into the terminal is not guaranteed, so we cannot build our trading algorithm on waiting for the arrival of some trade transactions after others. Besides, transactions may be lost when delivering them from the server to the terminal.
//---
Could you please tell me how do you control if an order is modified (without server's response)?
For example, compare the previous values with the current values.
No, it doesn't work. The event model must be absolutely reliable. If the event didn't get there, then it didn't happen. On FORTS the events must be executed particularly accurately because order changes can generate dozens of trades.
The event-driven model by definition cannot be absolutely reliable, if the event did not get there, it does not mean that it did not happen.
tol64!
Yes, it doesn't matter how they come (although, it's not logical that the "order placed" event comes first, followed by "order in modification state" )
Not right?
If you look carefully at my picture, you'll see that the "order partially executed" message came (there are two in a row), instead of "order placed"!
P/S And no need to "tear out the text" and the whole sentence that starts like that:
Knowing the type of trade, you can decide to analyse the current status of orders, positions and trades in your trading account.