Хочу поставить точку на чарт

Новый комментарий
 
Выношу сюда тему "MQL4: Хочу поставить точку на чарт" .

Задача - точно поставить на чарте точку. Разумеется, программно. Фишка в том, что ее нужно поставить не обязательно на бар, а между барами (скажем, с баровым смещением 3.74).

В ветке было предложено сделать это с помощью объекта OBJ_TEXT c дескрипшеном " *", причем количество пробелов нужно, естественно, вычислять. Выяснилось, что в MQL4 не существует программных методов реализации нужных вычислений - если учесть, что юзверь может изменять размеры окна, давить батон "Zoom in/out", да еще и ТФ менять. Да и сами вычисления при этом, честно говоря, какие-то ну совсем уж через задний проход получаются...

Автор ветки склоняется к использованию OBJ_LABEL - единственного объекта, который можно поставить на чарт по пикселам. Проблема в том, чтобы привязать его координаты к координатам нарисованных на чарте баров.

Поэтому предложение в ветке звучит так:

Вот было бы здорово, если бы метаквоты ввели функции типа int WindowGetX( int datetime, int anchor) и int WindowGetY( double price, int anchor), возвращающие пиксельное смещение (по нужной координате) относительно якорной точки.


Думаю, функции можно применять во многих графических задачах.

Рассчитываю на реакцию разработчиков. Спасибо.

P.S. Отправил пожелание стандартной формой. И еще: первый аргумент первой функции вроде как имеет неправильный тип. Хорошо, пусть будет datetime dt...
 
если тебе это надо для проверки правильности построения зигзага на старшем т-ф, то лучше поступать наоборот, строить на младшем путем моделирования старшего, таким образом на младшем ты будешь видеть свои воображаемые точки и если захочешь будешь ставить их над барами
 
Пожалуй, только так и остается. В службе поддержки ответили, что в ближайшее время это делать не будут :(

Чтобы видеть картину старшего ТФ, на младшем придется ставить слишком маленькое расстояние между барами. А отношение старшего ТФ к младшему у меня как дневки к 5-минуткам, т.е. 288.
 
Хех.... Да, в метаквотах, на самом деле, отсутствует целое семейство функций, связанных именно с window-манипуляциями - получение горизонтального масштаба и пр, так что приходится изощряться самыми разными способами, и творческая интуиция обостряется до невозможности ))) - так вот, можно предложить следующий изощренный/извращенный вариант решения:

ставьте крестики ))).

Между двумя соседними барами всегда возможно нарисовать две линии крест-накрест таким образом, чтобы координата X точки их пересечения находилась в верном месте между барами. Этот подход хорош тем, что нужное соотношение сохраняется при изменении вертикального и горизонтального масштабов. Привыкнуть к тому, что нужно обращать внимание на центр крестика, вполне возможно. Вычисления также довольно просты.

Если же нужно именно WindowGetX - попробуйте WinAPI-функцию GetClientRect (ее придется, впрочем, оборачивать в свою функцию, т.к. LPRECT из мт так просто не получишь) . Количество баров на графике вы знаете, поделив одно на другое, можно получить ширину бара... и т.п.
 
ставьте крестики ))).


Это хорошо, если таких точек (пересечений крестиков) несколько штук. А если - несколько десятков или даже сотен?

Если же нужно именно WindowGetX - попробуйте WinAPI-функцию GetClientRect (ее придется, впрочем, оборачивать в свою функцию, т.к. LPRECT из мт так просто не получишь) . Количество баров на графике вы знаете, поделив одно на другое, можно получить ширину бара... и т.п.


Я уже это предлагал. Integer с mql4.com, спасибо ему, грубо обломал мои надежды: клиентская область - это нечто большее, чем область, на которой ставятся бары. Там еще циферки с курсами стоят справа.
 
тысяча линий на графике не слишком страшна. Во всяком случае, графических ресурсов на отображение N меток тратится не меньше (помним про TrueType фонты) и т.п, чем на 2N линий )). Худо начинается от нескольких десятков тысяч.

В чем метаквоты бесспорно молодцы - они весьма удачно оптимизировали отображение, и большое количество объектов не сильно напрягает систему (особенно, если большая часть объектов невидима)

Что касается надежд - полагаю, зря они так быстро рухнули под напором Integer )). Левый и правый margins имеют фиксированную ширину и легко вычитаются из ClientWidth.
 
тысяча линий на графике не слишком страшна.


Безусловно не слишком страшна. Для терминала, но не для человека.

Левый и правый margins имеют фиксированную ширину и легко вычитаются из ClientWidth.


Спасибо, вот же ж ведь как бывает: об использовании линейки я и не подумал...
 
Гм. Мне кажется, по внешнему виду звездочки и крестики вполне сопоставимы:



Впрочем, не зная Вашей ситуации детально, рекомендовать не берусь. "Наше дело предложить, ваше дело отказаться" ))).
 
Признаю, Quod Licet, твое решение действительно великолепно, я убит до смерти (killed to death). Наконец-то я услышал брата по несчастью, которому это "безумие" (нецелое баровое смещение) действительно было нужно и который это реализовал. Я попробую сделать то же самое, но с пятью сотнями крестиков.

А не слишком ли трудно MQ ввести функции int WindowGetZoom(), int WindowSetZoom(), соответственно возвращающую и устанавливающую порядковый номер горизонтального масштаба чарта - от 0 до 5?

Если так, то тогда уже можно будет решить исходную задачу с помощью объекта OBJ_TEXT (мелкий шрифт и вычисление нужного количества пробелов в тексте " *").

Есть подозрение, что существующими средствами MQ его вычислить невозможно - с учетом меняющегося горизонтального размера окна.
 
Спасибо Slawе, прочитал несколько его комиксов насчет PostMessageA(), много думал ( (с) не мой). ОК, теперь зумом можно управлять программно. Внес в WinUser32.mqh пару строчек, определяющих еще две команды:

#define VK_ADD			0x6B
#define VK_SUBTRACT			0x6D


Нарисовал 40 точек x9f на максимальном зуме. Вот то, что получилось:



(Здесь уже 48 точек, но суть картинки не меняется. Очень хотелось вставить картинку сюда...)

Выходит, что с неслабой точностью между двумя барами при максимальном зуме мы можем поставить 8 точек. 8 - степень двойки, и поэтому при изменении зума параметры отображаемого шрифта пересчитывать не нужно, достаточно только умножить/разделить количество пробелов на 2. Кстати, расстояние между соседними точками по горизонтали - порядка 5 пикселов, что очень даже неплохо...

К сожалению, такая красота (именно 8 точек между двумя барами) получается только при заданном разрешении экрана (здесь 1280х1024). К тому же я не умею программно вычислять зум :(

Код скрипта для этой картинки такой (я его не особо причесывал):

#include <WinUser32.mqh>

int init()
{
   ObjectsDeleteAll( 0, OBJ_TEXT );
   return( 0 );
}

string blanks( int qty )
{
   string res = "";
   for ( int i = 0; i < qty; i++ ) res = StringConcatenate( res, " " );
   return( res );
}

void drawOneObject( int number, string name, datetime dt, double baseprice, 
                        double pricedelta, int size, string symbol, color clr )
{
   ObjectCreate( name, OBJ_TEXT, 0, dt, baseprice - pricedelta * number );
   ObjectSetText( name, StringConcatenate( blanks( number + 1 ), symbol ), 
                  size, "Wingdings", clr );
   return( 0 );
}

void drawObjects( int howmany, int size )
{
   for( int i = 0; i < howmany; i++ )
   {
      string name = DoubleToStr( i, 0 );
      drawOneObject( i, name, Time[0] - 28800, 1.3255, 0.0002, 
                    size, "\x9f", Yellow ); 
   }
   return;
}                     

void zoomIn()
{
   int hwnd = WindowHandle( "EURUSD", 0 );
   PostMessageA(hwnd, WM_KEYDOWN, VK_ADD, 0); 
   return;
}

void zoomOut()
{
   int hwnd = WindowHandle( "EURUSD", 0 );
   PostMessageA(hwnd, WM_KEYDOWN, VK_SUBTRACT, 0); 
   return;
}

int start()
{
   for( int i = 0; i < 6; i++ ) zoomIn();
   drawObjects( 40, 5 );
   return(0);
}


Вопрос на засыпку для Quod Licet: если все это нарисовать крестиками, то на какие из пересечений линий надо обращать взгляд?

 
Mathemat, хорошая картинка. А линии от таких точек в нужном направлении рисовать можно? Столкнулся с тем, что некоторые линейные инструменты в метатрейдере невозможно вывести правильно из-за грубой привязки к барам. Например, каналы фибоначчи сейчас нет возможности примерно в половине случаев правильно построить. Что-то свое надо мастерить вместо встроенных в метатрейдер.
12
Новый комментарий