What should the price glass be like? - page 12

New comment
 
The delay in the release of tumbler has arisen because a new type of engine needs to be made. Beaker, as a standalone application working as an independent engine, needs to provide a user API, otherwise, as a closed program, its value will be much less. The engines I've made in the past were completely dependent on user commands and had no functionality of their own. The new type of engine, must work independently as well as controlled from the outside. I'm solving this problem now.
 

Today marked another important step forward. The engine can now operate as a standalone application, synchronising its parameter values with the user application connected to it. The application is connected as before, but now it can request values that are set by the engine functionality. Thus, this is a transition to a new level of interaction between the programs. The engine as a standalone program can accumulate its functionality and extend the API provided to the applications.

In the case of the price stack, - it has become a standalone application (which I will finish tomorrow, the day after tomorrow), and works as an indicator. Using the connection, users can retrieve the values of this cup and override them, returning them to the cup in a modified form. For example: The price in one of the glass fields has been analysed by the user code and it turns out to be the level of some important indicator. The user sends their string marker to that field and it will appear next to that price. This opens up interesting new possibilities for the development of both engines and user programs.

SZZ. The GUI slider events, previously only sent to the app, now also go into the engine's internal functionality and parallel handling of events is performed at both ends - in the engine (according to my code) and in the user application (according to user code). Clicking the button triggers both the engine functionality and the functionality of the connected application.
 
Another thing that is missing in the cup is the profit if you close now on the market, i.e. accounting for cup filling - relevant for positions slightly larger than small ones (e.g. 100-150 lots).
 
Will there be any hotkeys?
 
Andrey Gladyshev:
Will there be hotkeys?
Absolutely.
 
Aleksey Vyazmikin:
Another thing missing from the cup is the profit if you close now on the market, i.e. filling the cup - relevant for positions slightly larger than small (e.g. 100-150 lots).
Account of the cup filling. I will think after the release of the basic version, so as not to delay.
 
The price cup will be ready. The documentation of the API connection was very delayed. It is extremely time consuming to write your documentation in your own markup language. And the documentation of the tumbler has to be done too. And the glass itself. And at the same time optimize the code, constructor, fix bugs and add features. That's why it's so long. But then everything will be faster and quicker.
 
What language is the programme written in?
What is the actual processing speed of the incoming data?
How is the data allocated to the price levels?
Is it a for loop or is there a variable with data for each level?
The fact that you have chosen the type of mapping of the cup on the Western terminals is correct.
I would suggest to add to the cup, management of linked OCO orders up to three levels.
And in general you can take any functional western Market Dock and see what is implemented in it.
Or see how QScalp scalper drive is implemented.
 
Roman:
What language is the program written in?
What is the actual processing speed of the incoming data?
How is the data distributed by price levels?
In a for loop or for each level has its own variable with data?
The fact that you have chosen the type of mapping of the cup, like in the Western terminals, is correct.
I would suggest to add to the glass, management of linked OCO bids up to three levels.

1. The programme is written in two languages. The base language is MQL5, and on top of that, my markup language.

2. Distributed in the same way as sent. I mean in the right cells. It's hard to explain in words. I'll send you the code later. Of course, I had to sweat to get the data into the right cells, but this issue was resolved.

3. I will add everything I will be asked for and that has sense and importance.
 

Here is the code for distributing the data to the cells in my cup:

void On_DOM_Event()
{
 int t = 0;
 //----------------------------
 MqlTick last_tick;
 SymbolInfoTick(Symbol(),last_tick);
 //----------------------------
 MarketBookGet(NULL,priceArray); 
 //----------------------------
 double p = 0;
 long   ask_size = 0, bid_size = 0;
 int    s = ArraySize(priceArray);
 //----------------------------
 if(s > 0)
   {
    //-------------------------   ---
    for(int i1 = 0; i1 < 100; i1++)prices[i1]  = NULL;
    for(int i1 = 0; i1 < 100; i1++)ask_vol[i1] = NULL;
    for(int i1 = 0; i1 < 100; i1++)bid_vol[i1] = NULL; 
    //----------------------------
    int Closest_to_ask = 0;
    //----------------------------
    for(int a1 = 0; a1 < s; a1++)
      {
       if(
              priceArray[a1].price == last_tick.ask
          || (priceArray[a1].price < last_tick.ask && (((a1 + 1 < s) && priceArray[a1 + 1].price >= last_tick.bid) || (a1 + 1 == s)))
         )
         {
          Closest_to_ask = a1;
          break;
         } 
      } 
    //----------------------------
    for(int a2 = Closest_to_ask; a2 >= 0; a2--)
      { //Alert("t ",t,"  a2  ",a2);
       prices[49-t]  =  Normalize_Double(priceArray[a2].price,_Digits,_Point);
       ask_size     +=  priceArray[a2].volume;
       ask_vol[49-t] =  (string)priceArray[a2].volume;
       t++;
      }
    //--------------------------------  
    t = 0;
    //Alert("_Digits   ",_Digits);
    //--------------------------------  
    for(int a3 = Closest_to_ask + 1; a3 < s; a3++)
      { 
       prices[50+t]  =   Normalize_Double(priceArray[a3].price,_Digits,_Point);
       bid_size      +=  priceArray[a3].volume;
       bid_vol[50+t] =   (string)priceArray[a3].volume;
       t++;
      }         
 //------------------------------------------------       
 //------------------------------------------------ 
 E_DOM_1_Price(prices[40]);    E_DOM_1_Ask_size(ask_vol[40]);
 E_DOM_2_Price(prices[41]);    E_DOM_2_Ask_size(ask_vol[41]); 
 E_DOM_3_Price(prices[42]);    E_DOM_3_Ask_size(ask_vol[42]); 
 E_DOM_4_Price(prices[43]);    E_DOM_4_Ask_size(ask_vol[43]); 
 E_DOM_5_Price(prices[44]);    E_DOM_5_Ask_size(ask_vol[44]);
 E_DOM_6_Price(prices[45]);    E_DOM_6_Ask_size(ask_vol[45]);
 E_DOM_7_Price(prices[46]);    E_DOM_7_Ask_size(ask_vol[46]);
 E_DOM_8_Price(prices[47]);    E_DOM_8_Ask_size(ask_vol[47]);  
 E_DOM_9_Price(prices[48]);    E_DOM_9_Ask_size(ask_vol[48]); 
 E_DOM_10_Price(prices[49]);   E_DOM_10_Ask_size(ask_vol[49]);
 //-------------------------------------------------
 E_DOM_11_Price(prices[50]);  E_DOM_11_Bid_size(bid_vol[50]);
 E_DOM_12_Price(prices[51]);  E_DOM_12_Bid_size(bid_vol[51]);
 E_DOM_13_Price(prices[52]);  E_DOM_13_Bid_size(bid_vol[52]); 
 E_DOM_14_Price(prices[53]);  E_DOM_14_Bid_size(bid_vol[53]); 
 E_DOM_15_Price(prices[54]);  E_DOM_15_Bid_size(bid_vol[54]); 
 E_DOM_16_Price(prices[55]);  E_DOM_16_Bid_size(bid_vol[55]); 
 E_DOM_17_Price(prices[56]);  E_DOM_17_Bid_size(bid_vol[56]); 
 E_DOM_18_Price(prices[57]);  E_DOM_18_Bid_size(bid_vol[57]);    
 E_DOM_19_Price(prices[58]);  E_DOM_19_Bid_size(bid_vol[58]); 
 E_DOM_20_Price(prices[59]);  E_DOM_20_Bid_size(bid_vol[59]);
 //------------------------------------------------- 
 }
 RMSG(1);
}


To record incoming data, I made a 100-cell array. I distribute incoming data from the centre of the array (cell 49) to the asc and bid side, calculating the closest price to the asc and bid side beforehand.

1...567891011121314
New comment