Is tick history available on the server? - page 4

 
I think there is a rational basis in Scholand's suggestion, but personally I need them for research and I'm afraid I can hardly provide anything serious in a week, and I have such an indicator just a week before the appearance of the branch, but there is a problem - he deletes the file with ticks after each initialization, and neither he nor I have managed to finish the task. It forms bars according to a fixed volume, because sometimes a tick comes and the volume has not changed by 1.
//+------------------------------------------------------------------+
//|                                                    TickSaver.mq4 |
//|                               Copyright © 2006, Cherednikov K.M. |
//|                                            mailto:chkm76@mail.ru |
//+------------------------------------------------------------------+
#property copyright "Copyright © 2006, Cherednikov K.M."
#property link      "mailto:chkm76@mail.ru"

#property indicator_chart_window
#property indicator_buffers 1
#property indicator_color1 Black

#include <WinUser32.mqh>
//---- input parameters
extern int NumTicksPerBar=3;
extern int Minutes_for_HSTfilename=3;

//---- buffers
double ExtMapBuffer1[];

//---- глобальные переменные
int hFile=-1;
int iFilePos;
int CurrTickNumber=0;
datetime i_time, i_time_bar0;
double d_open, d_low, d_high, d_close, d_volume;
double d_low_bar0, d_high_bar0, d_volume_bar0;

//+------------------------------------------------------------------+
//| Custom indicator initialization function                         |
//+------------------------------------------------------------------+
int init()
  {
   int    nVersion=400;
   string szCopyright;
   string szSymbol=Symbol();
   int    iDigits=Digits;
   int    iUnused[13];

   //---- indicators
   SetIndexStyle(0,DRAW_LINE);
   SetIndexBuffer(0,ExtMapBuffer1);
   hFile=FileOpenHistory(szSymbol + Minutes_for_HSTfilename + ".hst", FILE_READ);
   if(FileSize(hFile)<0){
   // Дабы не затереть реальные файлы историй, в имя файла добавлен "0" перед периодом
   hFile=FileOpenHistory(szSymbol + Minutes_for_HSTfilename + ".hst", FILE_BIN|FILE_WRITE);
   if(hFile < 0) return(-1);
   //---- Записать заголовок hst-файла
   szCopyright="(C)opyright 2003, MetaQuotes Software Corp.";
   FileWriteInteger(hFile, nVersion, LONG_VALUE);
   FileWriteString(hFile, szCopyright, 64);
   FileWriteString(hFile, szSymbol, 12);
   FileWriteInteger(hFile, Minutes_for_HSTfilename, LONG_VALUE);  //  файл - М2
   FileWriteInteger(hFile, iDigits, LONG_VALUE);
   FileWriteInteger(hFile, 0, LONG_VALUE);
   FileWriteInteger(hFile, 0, LONG_VALUE);
   FileWriteArray(hFile, iUnused, 0, 13);
   FileFlush(hFile);
   iFilePos=FileTell(hFile);
    }
    
    else{ iFilePos=FileTell(hFile); }
   i_time = CurTime();
   i_time_bar0 = Time[0];
   d_open = Close[0];
   d_low = d_open;
   d_high = d_open;
   d_close = d_open;
   d_volume = 1;
   d_volume_bar0 = Volume[0];

   /*d_low_bar0 = Low[0];
   d_high_bar0 = High[0];*/
   
   //----
   return(0);
  }
//+------------------------------------------------------------------+
//| Custom indicator deinitialization function                       |
//+------------------------------------------------------------------+
int deinit()
  {
   if(hFile>=0)
    { 
      FileClose(hFile); 
      hFile=-1; 
    }
   return(0);
  }
//+------------------------------------------------------------------+
//| Custom indicator iteration function                              |
//+------------------------------------------------------------------+
int start()
  {
   CurrTickNumber++;
   //********* Обновление данных в переменных текущего бара **************
   d_close = Close[0];
   if (d_low > d_close) d_low = d_close;
   if (d_high < d_close) d_high = d_close;

   // Объем
   if (i_time_bar0!=Time[0])  // если на реальном графике появился новый бар, а для 
                              //   нас еще не набралось тиков закончить тиковый бар...
    { //расчитать изменение объема с учетом пополнения предыдущего реального бара
      d_volume += Volume[1] + Volume[0] - d_volume_bar0;
      i_time_bar0 = Time[0];
    }
   else
    { //расчитать изменение объема только с учетом текущего реального бара
      d_volume += Volume[0] - d_volume_bar0;
    }
   d_volume_bar0 = Volume[0];

   // Обновление данных последнего бара
   FileSeek(hFile, iFilePos, SEEK_SET);
   FileWriteInteger(hFile, i_time, LONG_VALUE);
   FileWriteDouble(hFile, d_open, DOUBLE_VALUE);
   FileWriteDouble(hFile, d_low, DOUBLE_VALUE);
   FileWriteDouble(hFile, d_high, DOUBLE_VALUE);
   FileWriteDouble(hFile, d_close, DOUBLE_VALUE);
   FileWriteDouble(hFile, d_volume, DOUBLE_VALUE);

   if (CurrTickNumber==NumTicksPerBar)
   {
      iFilePos=FileTell(hFile);
      CurrTickNumber=0;
      i_time = CurTime();// / 60 / Minutes_for_HSTfilename;
      //i_time *= 60 * Minutes_for_HSTfilename;
      d_open = Close[0];
      d_low = d_open;
      d_high = d_open;
      d_close = d_open;
      d_volume = 1;
      FileWriteInteger(hFile, i_time, LONG_VALUE);
      FileWriteDouble(hFile, d_open, DOUBLE_VALUE);
      FileWriteDouble(hFile, d_low, DOUBLE_VALUE);
      FileWriteDouble(hFile, d_high, DOUBLE_VALUE);
      FileWriteDouble(hFile, d_close, DOUBLE_VALUE);
      FileWriteDouble(hFile, d_volume, DOUBLE_VALUE);
   }
   FileFlush(hFile);

   // Обновление окна автономно открытого файла
   int hwnd=WindowHandle(Symbol(), Minutes_for_HSTfilename);
   if (hwnd!=0) PostMessageA(hwnd, WM_COMMAND, 33324, 0);

   Comment("Отладочная Инфа: \n"+
           "Тиков в баре: " + CurrTickNumber +
           "\nOpen=" + d_open + "    Close=" + d_close +
           "\nHigh=" + d_high + "    Low=" + d_low +
           "\nVol=" + d_volume +
           "\nПозиция файла: " + iFilePos
   );

   return(0);
  }
//+------------------------------------------------------------------+


 
Personally it seems to me, that developers artificially invent technical problems to justify themselves in unwillingness (or impossibility) to improve MT in terms of tick history. <br / translate="no">
Tick file string (Time,Close,Volume) = (int,double,double) = (4,8,8,) = 20 bytes.


The quotes can be stored in integers by multiplying them by 10000 and 100 (for Japanese) accordingly.
You can also store key points and the offset relative to the last quote.
All these problems are technical.
The main problem is strategic.
Quotors do NOT WANT and, I think, will not do it. Only if the terminal is squeezed by competitors, there will be a prerequisite for a ticking terminal.
There is another problem. Customers don't pay for the terminal.
It is paid by DTs who buy servers, and DTs are NOT INTERESTED in the tick terminal, because there will be expert pipsers who work on DT quotes peculiarities.
 
The brokerage companies are not interested in a tick terminal, because there will be pipsmiths who work on the peculiarities of the brokerage companies' quotes.

It is unlikely that brokerage companies think about the terminal (tick or time terminal). They have other interests. All that is necessary for brokerage companies, I think, is already given by the developers (permission/prohibition of auto-trading, cancellation of deals at non-market prices and so on). The championship statistics shows that any brokerage company can arrange a good "kitchen" and the appearance of some special tick terminal will not change anything fundamental, at least brokerage companies will hardly oppose its introduction, if it is developed. Well, since there is no detailed proof of the need to introduce tick series yet, the issue will be where it is now.
It would be interesting to look at the results of tick proofs from the Omega platform, which "does anything - any tick and timeframe".

Although the discussion about brokers is already beyond the scope of the forum. I guess they'll clean it all up now?:o)
 
I think there is a rational basis in what solandr suggested, but personally I need them for research and I'm afraid I won't be able to provide anything serious in a week...

"MQL4: Tick collector
The Expert Advisor saves tick history for specified symbols
 
I suggest that we move on from the endless and pointless verbal debate on the tic-tac-toe issue to detailed evidence. To do this, we need to do the following. If you want, you can write a simple script that generates tick-series with chosen amount of ticks and writes data into a CSV file. Further, you can open this file in EXCEL and use the standard EXCEL tools to draw the tick-series diagram. If such a chart is available for a week, for example for a specified tick-frame, you can compare it with a standard MT4 chart and show that the tick-frame chart has given some additional entry/exit points that could not have been received in some way from standard time series, for example using the trend support/resistance lines or something else.

Dear solandr!
Why are you so irritated by this polemic? Why do you persist in believing that you know everything about the future - both what to do and what not to do?

The "proof building" program proposed by you is wrong in principle. You want to make the success of tick trading the only credible argument. If you reason like that, then none of the existing t/fs are needed at all - no one has yet reported radical success thanks to a particular t/f.

I inform you. I have long ago written an Expert Advisor, which not only writes the tick history, but also displays it in real time on the chart. So, everything that can be done in other frames can be done in a tick chart. It once again shows what a powerful tool MT4+MCL4 is. It also shows that it's not so difficult to make this service built-in.

Besides, I've spent a lot of time on researching tick data. It absolutely does not matter whether I succeeded in the market because of it or not. People achieve something or not because of their ability and hard work. But in order for a result to be achieved, they must FIRST have the ability. This condition is not sufficient, but necessary ! :-)

Why the question is there a possibility to work with timeframes, and not with tick-frames? This situation is understandable due to limited capabilities (time, human, etc.) of developers. But it is completely unacceptable in terms of service completeness and strategy. Therefore, if it more or less suits the market today, it will not do so tomorrow.
 
2 Jhonny
I think there is a rational basis in Scholand's suggestion, but personally I need them for research and I'm afraid I won't be able to provide anything serious in a week, but I have a pre-production indicator of that kind


Exactly! That's my point exactly.

By the way, this thing should be implemented as an EA. The indicator skips ticks !
To avoid rubbing the file it has to be opened like this: FILE_BIN|FILE_READ|FILE_WRITE
And before you write into it, set the write pointer to the end of the file.
 
Yurixx, I was only expressing my point of view! This is a free forum and everyone has the right to express their opinion, isn't it? Or should we always listen to the opinion of the majority? But the majority "leak" - look at the Championship!

People have asked the developers to make a ticking history, the developers categorically refused. So what next? You will just write here a mountain of complaints that the developers have not listened to the "wishes of the working people"? I, for my part, simply suggested a rational option for applying pressure on the developers - that's all! If everyone just wants endless verbal complaints without any real progress on the issue, then, please, I personally have nothing against it.
 
"MQL4: Tick collector <br / translate="no"> The Expert Advisor saves the tick history for the specified symbols


Of course, I want to thank for the Expert Advisor, but I just looked it up, it saves data in csv, while mine was designed to store it in history and then the chart can be opened and analyzed offline.
 
Of course thanks for the Expert Advisor, but I just looked it up, it saves in csv, while mine was designed to save in history and this chart can be opened and analyzed offline.

"MQL4: simple_csv2fxt".
Simple csv to fxt converter.


It is necessary to combine my Expert Advisor and this script, and patch it up a bit - it will be perfect ;)
 
It seems to me that asking if we need tick data is useless because the answer is obvious - the more possibilities are provided, the more complete and high-quality the service is and there will always be people who need one or the other... The answer to the question will this feature be implemented in the near future? - Obviously not... There is in my opinion one important reason... Namely - will be implemented only what brings Metakvotes revenue at this stage in the form of new contracts and this is logical and correct ... As income brings intermediary companies (brokers, DC, etc.) then will be implemented that simplifies their lives, but not what will complicate their lives ...
Tick data will complicate their lives for the following reasons:
1. If tick data is available, the Expert Advisors trading on tick symbol are sure to appear, and therefore there will be huge difficulties with the overlapping of such experts.
2) if reliable tick data is available, the possibility of testing tick experts in the tester will become available (which will also increase their number)
3. After access to tick data, the public will demand access to REAL volumes :))))))
4. 4th place is occupied by unwillingness or busyness of developers (if there were demand of brokerage companies, they would create it in a fortnight :))
5. And finally a "trump" argument about insane traffic and disk space...