Редактироваание объекта на графике - страница 3

Новый комментарий
 
solandr:
xnsnet:
Согласись иногда хочется что-то сделать не просто быстро а очень быстро, то есть по горячим клавишам.
Честно говоря по мере накопления опыта работы на Форекс начинаешь всё меньше и меньше принимать во внимание фактор времени. То есть вместо понятий "быстро" и "очень быстро" появляются понятия "правильно" или "рационально", которые по своей сути полностью ликвидируют понятия "быстроты". Форекс - это совсем не та область где нужно или же требуется куда-то спешить! Кстати говоря вот здесь есть отчёт о Чемпионате, в котором чётко прописано что согласно статданным в лидерах находятся обычно те, кто имеет весьма длительное время удержания открытых позиций. Какую роль могут играть 5 минут, если ваш трейд длится несколько суток???
https://championship.mql5.com/2012/ru/news

И опять же я с этим отчасти соглашусь:) Мы врядли говорим о факторе времени, вы абсолютно правельно заметили 5 минут никакой роли не играют. Но мы говорим не о поспешности действий в торговле. А о совокупности действий вообще. Я за пол года проникновения в это дело, уже понял что за пять минут ничего хорошего не случается, однако есть такие случаи когда ты уже предсказываешь ситацию и правельное влияние на нее экономит нервы и деньги. Я предпочитаю не выходить за дневной диапазон, если к этому не распалагает ситуация и то крайне осторожно отношуть к долгосрочным ставкам, а даже если и полагаюсь, то в основном на собственный анализ и полуавтоматику, которая настроена на основе этого анализа, но и она не всегда правельно воспринимает ситуацию, а автомат так я бы сказал и подавно, что плохого в том что ты вовремя снимешь или поставишь ставку, экономя на этом чуть больше прибыли чем возможно, все равно предварительно хотелось бы расчитать потери, возможные скачки, а иногда здравый расчет приносит куда больше чем импульсивность, что плохого в том, что в совокупности расчета ты сэкономишь время, а расчет то все равно делается в уме, зачастую индикаторы только с толку сбивают, ведь они не берут во внимание всех факторов вообще. Получается что действия которые ты делаешь, задумываясь о них, тоже сбивают с толку, меня как разработчика сбивает с толку, например то, что программа работает не так как мне надо, мне не хочется подстраиваться под программу, я хочу чтобы программа подстраивалась под меня. Иначе на кой черт я вообще занимаюсь программированием по жизни, ни ради того ли, чтобы исключить побочные являения и не быть зависимым от всяких мелочей, которые не стоят моего внимания, уж хоть не во время реализации, так хоть по окончанию.
 
xnsnet:
что плохого в том что ты вовремя снимешь или поставишь ставку, экономя на этом чуть больше прибыли чем возможно, все равно предварительно хотелось бы расчитать потери, возможные скачки, а иногда здравый расчет приносит куда больше чем импульсивность, что плохого в том, что в совокупности расчета ты сэкономишь время, а расчет то все равно делается в уме,
Согласно своему опыту (2 года) могу сказать следующее. В большинстве случаев когда я открываю/закрываю позы, то через несколько часов (иногда 1-2 дня) оказывается что позы можно было открыть/закрыть на 50-100 и даже более пунктов выгоднее, чем это сделал я. Те единичные случаи когда действительно удавалось войти/выйти близко к самым экстремумам цены погоды в депозите никакой не сделали. И практически абсолютно ничего бы в состоянии депо не поменялось бы если бы я то же самое сделал бы спустя к примеру пару часов или даже на следующий день. Поэтому проблема увеличения скорости закрытия/открытия сделок - это скорее всего искусственная проблема, которая возникает обычно вследствие отсутствия работоспособной торговой стратегии. Задача которая стоит перед трейдером - это произвести рациональный вход/выход в рынок, который обладает статистическим преимуществом (то есть является неслучайным и приносит профит), а не успеть однажды оторвать лишние 10-20 пипсов у рынка во время скачков цены на новостях. Обычно когда разговор поднимается про скорость исполнения сделок, то подразумеваются в виду именно эти самые лишние 10-20 пипсов и не более того!
 
<<Обычно когда разговор поднимается про скорость исполнения сделок, то подразумеваются в виду именно эти самые лишние 10-20 пипсов и не более того!>>

Именно. Более того, считаю, что достаточно устойчивый и хорошо настроенный алгоритм вообще не должен реагировать на такие вещи (в смысле, открываться/закрываться на новостях), может быть, только подтягивать трейлинг, если цена идет в нужную сторону. При неблагоприятном же развитии событий может спасти только высокое искусство постановки стопов.
 

Все это понятно, сам проходил все это, не раз ошибался и не раз приходилось признавать свои ошибки, но на психологической ситуации иногда удается не плохо играть, и самое интересное не то что ты под воздействием эмоций закрываешь ордера, а удовлетворение от того что стоповые приказы поставлены именно там где ты расчитал. Но опять же вся эта схема условна, это думаю всем понятно, даже самый опытный тредер ошибается.

Думаю что у всех нас примерно одинаковые мысли, например подтягивание стоповых границ все одинакого понимают.

В анализе AG я пришел к тому, что объектная концепция успешно рушится в своем обилии объектов, честно говоря меня этот факт не обрадовал, потому как и сам сначала пришел к такому выводу, кроме того я вижу наиболее правельным взаимодействие ручного управления, вызова скриптов с гарячими клавишами и с помощью советника, не более. Зацикленный скрипт мешает своим висением в воздухе вызовам других скриптов. Я думал о перехвате событий окна, но данная реализация показалась мне еще более ужасающей в связи с неспособностью полноценной реализации, а уже не однократный опыт показывает, что это пустая трата времени и появление фатальных ошибок.

Я подумал как можно избавится от большого количества объектов и не принуждать скрипты и советники зависеть от них. Пришел к тому что ордера с которыми можно работать в графике нужно просто перебирать, одновременно позволяя манипулирование лишь одним ордером, а с помощью тех же горячих клавишь пролистывать список и глобальные переменные позволяют не перекрещивать работу с одним и тем же ордером в разных графиках, а так же их контроль (например подтягивание стоповых приказов) с помощью советника. Тем самым я бы сказал все же можно работать с ордерами с помощью горячих клавишь и не перегружать график объектами в обилии которых пользователь просто теряется. Есть много минусов от сочетания всего в рабочих участках кода, обязаловка в зависимости трех потоков приводит к целому ряду ограничений, я же не вижу в этом ничего хорошего, включая цикличность скрипта, это сковывает пользователя. Кроме того например я люблю видеть чистоту графика, где мне не нужно размышлять где какой объект, а убрать все объекты когда без них можно обойтись гораздо проще. Зависимости, зависимости, не делайте такие сложные зависимости, они очень запутывают пользователей и пугают, нельзя делать программы которые предлогают либо ее использование либо отказ от нее, в связи с неспособностью расширения, путем простого дополнения недостающих действий вне программы.

Спасибо SK за хороший пример реализации, он помог мне в осознании своей цели!

 

Вся бредовость скриптинга заключается в том, что в скриптах нельзя контролировать все то, что может контролировать пользователь, это самое важное, что абсолютно не логично, логично это когда наоборот. Это все равно что сравнивать логику Internet Explorer с Mozilla или Opera, последние два браузера абсолютно не логичны, особенно в первых версиях, а у микрософта с этим все всегда было впорядке. Впрочем ладно, здесь мы не сравниваем программы и их возможности, мы сравниваем логичность.

Блин вместо добавления поста отредактировал, ну ладно:)

 
Управление через программную эмуляцию GUI приложения средствами WinAPI, несомненно, универсальный вариант. Иногда вообще никуда от этого не денешься, например, если брокер то включает потоковое исполнение ордеров, то отключает его и переходит на котирование по запросу (такие примеры есть; не хочу называть конкретные "имена", т.к. здесь это не приветствуется), либо его торговая платформа - вообще не МТ, торговый API недоступен, а автоматику все же хочется задействовать. В таком случае эксперт будет просто вынужден перейти с автоматической отсылки ордеров на имитацию торговли вручную, через соответствующие случаю окна. Однако подобное решение проблемы -- сама по себе довольно трудная задача, требующая высокой квалификации, досконального знания устройства и работы ОС, и чрезвычайной аккуратности, поскольку вся работа по прогнозированию абсолютно всех ошибок и последующей их обработке целиком и полностью ложится на плечи программиста. К примеру, функции WinAPI, как правило, вообще не снабжены никакими средствами контроля корректности передаваемых им параметров. Это означает, что пустяковая ошибка, например, в 1 байт при определении размеров поля какого-нибудь параметра или при вычислении указателя на память для функций обратного вызова вполне может привести, и приводит, к самым серьезным последствиям, вплоть до краха ОС с ее последующим вылетом. Поэтому, если нет соответствующих знаний и опыта, за такую геморройную задачу лучше вообще не браться.
 

А с гуями все достаточно просто:)

Для примера пишем такой код в эксперте:

#import "wcontrol.dll"
    int _init( int hwindow );
    int _start( int whandle );
    int _deinit( int whandle );
#import
 
int whandle;
 
int init() {
    whandle = _init( WindowHandle( Symbol(), 0 ) );
    return(0);
}
 
int start() {
    return( _start( whandle ) );
}
 
int deinit() {
    return( _deinit( whandle ) );
}
Затем пишем такой код в либе:

LRESULT CALLBACK WndProc( HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam );
 
HWND mainWindow;
WNDPROC mainWndProc;
 
 
BOOL APIENTRY DllMain( HMODULE hModule, DWORD  ul_reason_for_call, LPVOID lpReserved ) {
    switch ( ul_reason_for_call ) {
      case DLL_PROCESS_ATTACH:
      case DLL_THREAD_ATTACH:
      case DLL_THREAD_DETACH:
      case DLL_PROCESS_DETACH:
          break;
    }
  return TRUE;
}
 
__declspec(dllexport) int __stdcall _init( HWND hWindow ) {
  if ( hWindow != NULL ) {
    mainWindow = hWindow;
    mainWndProc = (WNDPROC)SetWindowLong( hWindow, GWL_WNDPROC, (LONG)&WndProc );
  }
    return 1;
}
 
__declspec(dllexport) int __stdcall _start( int wHandle ) {
    return 2;
}
 
__declspec(dllexport) int __stdcall _deinit( int wHandle ) {
  SetWindowLong( mainWindow, GWL_WNDPROC, (LONG)mainWndProc );
    return 3;
}
 
LRESULT CALLBACK WndProc( HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam ) {
  LRESULT _result = 0;
  if ( uMsg != WM_PAINT ) {
    _result = CallWindowProc( mainWndProc, hWnd, uMsg, wParam, lParam );
  } else {
    _result = DefWindowProcA( hWnd, uMsg, wParam, lParam );
  }
  return _result;
}
Проверяем и видим отключение отрисовки... А раз этот маленький тестик работает на отлично, значит не обязательно даже окна вставлять, отрисовать по верх, все что надо и контролировать виртуально, а вот синхронизия, это целая история...
 
xnsnet:


В анализе AG я пришел к тому, что объектная концепция успешно рушится в своем обилии объектов, честно говоря меня этот факт не обрадовал, потому как и сам сначала пришел к такому выводу, кроме того я вижу наиболее правельным взаимодействие ручного управления, вызова скриптов с гарячими клавишами и с помощью советника, не более. Зацикленный скрипт мешает своим висением в воздухе вызовам других скриптов. Я думал о перехвате событий окна, но данная реализация показалась мне еще более ужасающей в связи с неспособностью полноценной реализации, а уже не однократный опыт показывает, что это пустая трата времени и появление фатальных ошибок.

Я подумал как можно избавится от большого количества объектов и не принуждать скрипты и советники зависеть от них. Пришел к тому что ордера с которыми можно работать в графике нужно просто перебирать, одновременно позволяя манипулирование лишь одним ордером, а с помощью тех же горячих клавишь пролистывать список и глобальные переменные позволяют не перекрещивать работу с одним и тем же ордером в разных графиках, а так же их контроль (например подтягивание стоповых приказов) с помощью советника. Тем самым я бы сказал все же можно работать с ордерами с помощью горячих клавишь и не перегружать график объектами в обилии которых пользователь просто теряется. Есть много минусов от сочетания всего в рабочих участках кода, обязаловка в зависимости трех потоков приводит к целому ряду ограничений, я же не вижу в этом ничего хорошего, включая цикличность скрипта, это сковывает пользователя. Кроме того например я люблю видеть чистоту графика, где мне не нужно размышлять где какой объект, а убрать все объекты когда без них можно обойтись гораздо проще. Зависимости, зависимости, не делайте такие сложные зависимости, они очень запутывают пользователей и пугают, нельзя делать программы которые предлогают либо ее использование либо отказ от нее, в связи с неспособностью расширения, путем простого дополнения недостающих действий вне программы.

Спасибо SK за хороший пример реализации, он помог мне в осознании своей цели!


В целом в Ваших рассуждениях есть смысл, но по-моему, Вы не прослеживаете до конца каждую мысль и делаете скоропостижные выводы..

Почему концепция рушится при обилии объектов? Почему пользователь теряется при обилии объектов?
По-моему, это совсем не так. Существуют же такие понятия, как необходимость, удобство, навык, привычка.
Если повариху с замусоленным брюхом или конюха с колхозной водокачки посадить в кресло пилота вертолёта МИ-8, то наверное и правда им покажется, что приборов, рычажков и лампочек многовато, глаза разбегаются!:) Обилие средств управления шандарахнет по их неподготовленному мировосприятию и они выскочат из вертолёта как ошпаренные, что-то бормоча про концепцию в вертолётостроении:)

Что касается конкретной реализации, то приложение AG-1 делалось в условиях, когда в составе MQL4 ещё не было некоторых функций, например, IsExpertEnabled() ('Голубая мечта.'). В AG-2 вопросы доступа к панели настроек эксперта и свободного переключения между ТФ успешно решены. И скрипт не висит - можно подгружать любые скрипты, не нарушая непрерывную(!) работу приложения.

А как "пролистывать" ордерные лини? Это что, просто подряд по всем, пока не дойдёшь до нужной? Это если, например, в окне 5 ордеров, каждый имеет по 3 линии, то надо 15 раз клацнуть некоторую комбинацию клавиш, чтоб добраться до последнего? А чтоб потом подправить ещё какой-то ордерок, снова по списочку? Я не говорю про психику, клавиатура выдержит такую нагрузку? (Зачем вообще они сделали мышу?)

"..я люблю видеть чистоту графика, где мне не нужно размышлять. ."
И как в этом случае пользователь может отличить ордерную линию, управляемую функцией подтяжки, от неуправляемой? Или никак, т.е. не надо?Удивительно, зачем вообще пользователю компьютер? Пусть бы работал на калькуляторе!:) Кнопок меньше, всё чётко и просто. Размышлять (ну почти) не нужно. В конце концов есть телефонный дилинг:)

За пример пожалуйста. Не знаю какую цель Вы осознали, но очень быстро. Мне бы так, но я так быстро не умею..

 
В целом в Ваших рассуждениях есть смысл, но по-моему, Вы не прослеживаете до конца каждую мысль и делаете скоропостижные выводы..

Почему концепция рушится при обилии объектов? Почему пользователь теряется при обилии объектов?
По-моему, это совсем не так. Существуют же такие понятия, как необходимость, удобство, навык, привычка.
Если повариху с замусоленным брюхом или конюха с колхозной водокачки посадить в кресло пилота вертолёта МИ-8, то наверное и правда им покажется, что приборов, рычажков и лампочек многовато, глаза разбегаются!:) Обилие средств управления шандарахнет по их неподготовленному мировосприятию и они выскочат из вертолёта как ошпаренные, что-то бормоча про концепцию в вертолётостроении:)

Что касается конкретной реализации, то приложение AG-1 делалось в условиях, когда в составе MQL4 ещё не было некоторых функций, например, IsExpertEnabled() ('Голубая мечта.'). В AG-2 вопросы доступа к панели настроек эксперта и свободного переключения между ТФ успешно решены. И скрипт не висит - можно подгружать любые скрипты, не нарушая непрерывную(!) работу приложения.

А как "пролистывать" ордерные лини? Это что, просто подряд по всем, пока не дойдёшь до нужной? Это если, например, в окне 5 ордеров, каждый имеет по 3 линии, то надо 15 раз клацнуть некоторую комбинацию клавиш, чтоб добраться до последнего? А чтоб потом подправить ещё какой-то ордерок, снова по списочку? Я не говорю про психику, клавиатура выдержит такую нагрузку? (Зачем вообще они сделали мышу?)

"..я люблю видеть чистоту графика, где мне не нужно размышлять. ."
И как в этом случае пользователь может отличить ордерную линию, управляемую функцией подтяжки, от неуправляемой? Или никак, т.е. не надо?Удивительно, зачем вообще пользователю компьютер? Пусть бы работал на калькуляторе!:) Кнопок меньше, всё чётко и просто. Размышлять (ну почти) не нужно. В конце концов есть телефонный дилинг:)

За пример пожалуйста. Не знаю какую цель Вы осознали, но очень быстро. Мне бы так, но я так быстро не умею..
Скорее не ордерные линии а сами ордера:) Выделяешь так сказать ордер, который можно выбрать с помощью, Alt+A (Next) и Alt+Z (Prev), к примеру можно пролистывать все ордера по кругу по нажатию Alt+Z Alt+A или использовать другие скрипты например выбрать первый установленный ордер или последний, а так же снять выделение или востановить. Выбирая Отрисовываются текущие данные в объектах на графике, сразу все для выбранного ордера. При этом к примеру не может быть выбран один и тот же ордер в двух графиках. По выбранному ордеру действуют другие горячие клавиши, например закрыть ордер, модифицировать, добавить стоплуз - тейкпрофит или снять или другое, но самое главное что все это можно делать без подтвержений. Размахнутся можно на все. Но каждому свое, все это можно реализовать по разному и каждый возьмет что ему больше понравится. Используя или отказываясь от разнообразия скриптов, главное единые правила.

Например для установки ордера на покупку я использую Alt+B нажимаю один раз появляются линии тейк профит и стоп луз, второй раз, убирается тейк профит, третий стоп луз, и по кругу. Потом выполняю установку, нажатием Ctrl+B. Все это делается за пару секунд и я при этом не путаюсь и даже не думаю. В это же дело можно добавить и отложенный ордер, путем добавления вертикальной линии, либо назначить отдельный скрипт. Что может быть проще этого? При этом я вижу линии только на момент выбора действий. Потом я в них больше не нуждаюсь, и могу для изменения этого ордера, использовать выделение последнего ордера. Все дополнительные фичи для советника устанавливаются в момент выбора ордера. И опять же для изменения ордера достаточно несколько раз счелнуть по одной горячей клавише. Есть только одно неудобство, графики имеют иногда границы достаточно неудобные в расположении для всех этих действий, в связи с этим приходится пользоваться стандартными средствами, но думаю такая проблемма не только у меня.

На данный момент я все еще эксперементирую, отрабатываю последовательности, как проще и как лучше.

У меня есть друг у которого на рабочем столе вообще ничего нет, кроме панели задач, да и в пуске ничего почти нет, хоть программ как у всех под сотню наберется, что вы думаете они все на горячих клавишах, я даже не осмеливаюсь трогать его бук, зная только как запустить IE и некоторые другие программки. Нет я так не могу, у меня проще, выставлена панель быстрого запуска слева от рабочего стола, в которой в три ряда огромное количество значков, почти на всех компах одно и то же, особенно удобно когда пара мониторов, иконки почти не меняют свои позиции на протяжении многих лет, но в программах я все же использую набор горячих клавишь. Программ много а горячие клавиши почти одни и те же. В итоге, мы не говорим о том какая программа лучше и какая имеет больше возможностей, мы сравниваем удобство, привычки и все это вкладывается в понятие ВОЗМОЖНОСТЬ ВЫБОРА, не более того. Все мы делаем выводы на основе своих пристрастий и привычек.

А касательно второй версии AG, хорошо что прогресс не стоит на месте, то что программа не зависит от скриптов, это уже хорошо, будем ждать, авось что-нить придумается на основе новой версии и не будет смысла писать свое:) А я пока со своим хламом поразвлекаюсь:) Я согласен с вами, я действительно не прослеживаю все мысли до конца, а выводы, я бы не сказал что они скоропостижные, я бы сказал они свойственные, а значит наиболее распространенные среди основной массы людей, я стараюсь на все свомтреть со стороны масс, но это не говорит о том, что я в действительности так делаю, в связи с этим я могу сказать, что вы поступаете точно также:)))

К примеру взять реакции людей, которые прочитали что-то непонятное, каждый посоветует, как ему более понятно, особенно если точка зрения совершенно иная, никто же не разбирается в причинах подобных выводов, а причины есть, они всегда есть если мы сталкиваемся с чем-то иным. К примеру мне сразу понятно когда люди не понимают того о чем я говорю, и мне даже понятно почему они не понимают, потому что у каждого свой набор знаний и свой опыт и даже глубина мышления. Я не делаю выводов об этом и не недооцениваю людей, потому что меня часто недооценивают, а зачастую в конечном итоге всегда выходит ровно наоборот. Именно поэтому я не чуть не сомневаюсь что AG будет намного лучше, чем он есть сейчас и даже на это надеюсь, потому что мы идем примерно в одном и том же направлении, только по разному.
 

Вот к чему меня приводят изыскания:

1. Я пришел к выводу что лучший способ контроля, это зацикливание советника еще на инициализации и использование одного или нескольких индикаторов в качестве тикового обработчика, скрипты соотвественно, только без зацикливания, советник делает основную работу, синхронизируясь с индикаторами и скриптами, но при этом торговля может происходить из индикатора, но не в прямую а через эвенты обрабатываемые в цикле советника, скрипты могут торговать как через советника, так и через эвенты. При этом все компоненты могут работать как раздельно так и совместно. другое дело, что от одного советника толку нет, если он предварительно не параметризирован с помощью глобальных переменных.

2. Для реализации синхронизации и обмена данными используются две библиотеки Control.ex4 и Control.dll, при этом глобальные переменные используются в минимальном объеме, только самые необходимые для работы советника, для реализации синхронизации построена объектная модель, благодаря которой я целостно могу обеспечивать данными все компоненты во всем терминале. На основе оконных дескрипторов осуществляется доступ к объектной модели. Глобальные переменные в этом плане не столь удобны, учитывая что строки приходилось хранить в названии, да и сохранение синхронизационных данных мне совсем не кстати, при этом объектная модель построена целеком на связанных коллекциях, не одного массива, кроме строковых переменных.

Хотелось бы конечно обойтись без MQL либа, но предпологаемый маштаб кода, слишком переполняет все компоненты, поэтому чувствую так и останется две либы.

К примеру контроль использования объектной модели для окна осуществляется тремя процедурами в либе EX4 и транслируется в DLL в таком виде:

#import "Control.dll"
    int GlobalControlInitialize( int iWindow, string iSymbol );
    int GlobalControlState( int iWindow, string iSymbol );
    int GlobalControlFinalize( int iWindow );
#import
 
int ControlInitialize() {
    string _Symbol = Symbol();
    int _Window = WindowHandle( _Symbol, 0 );
    return ( GlobalControlInitialize( _Window, _Symbol ) );
}
 
int ControlState() {
    string _Symbol = Symbol();
    int _Window = WindowHandle( _Symbol, 0 );
    return ( GlobalControlState( _Window, _Symbol ) );
}
 
int ControlFinalize() {
    int _Window = WindowHandle( Symbol(), 0 );
    return ( GlobalControlFinalize( _Window ) );
}

3. Эксперт и главный индикатор называются " .mq4" скомпиленные " .ex4" благодяря тому что их можно называть пробелом, я убрал лишние надписи:)))) Назвать мона как хочешь, а вот без лишних наименований сверху окон гораздо приятнее, освобождение пространство для своих меток:) Мелоч а приятно:)

А самое главное конечно результат, над которым пока работаю, без C++ обойтись не удалось, хоть и не люблю я его. Все такое громоздкое получалось, избыток глобальных переменных и их обработчиков, со строками одни мучения, тьфу:) Короче, вот так мы развлекаемся, как говорится по черному:) С графическим управлением ничего мутить не буду (на уровне девайса окна), зарание знаю что лажа получится, а влезать в память терминала не горю большим желанием, чтобы сделать все салидно, слишком много надо рыть...

123
Новый комментарий
Причина обращения: