Использование .NET, или как это использовать:)

Новый комментарий
 

Помнится были желающие понять как это можно вообще делать:)

Так вот, для тех кто так и не научился, но очень хочет, могу помоч тем что знаю:)

Что мы получаем при этом, могу сказать, самое главное:

1. Отладку вашего советника или целой программы рожденной советником в визуальной студии, как вы привыкли это делать.

2. Неограниченные возможности, ограниченные лишь вашими знаниями и вашими возможностями.

Что необходимо для этого знать:

1. Знание одного из .NET языков c возможностью применения в управляемом коде неуправляемого MC++, С#

2. Знания и опыт в применении DLL в MetaTrader

Что для это необходимо иметь:

1. Пакет Visual Studio 2005 или 2008 с комплектом С++ и С# если предпочитаете.

2. Терпение, время, и желание делать то что выходит за рамки обычного и привычного, но не менее быстрого, эфективного, а главное отлаживаемого.

Так как я пишу на C# я использую библиотеку прослойку на MC++ с минимальным кодом, который делает редирект API функций, самый удобный способ, я пытался объеденить эти библиотеки в одну и достиг определенных успехов, но не достиг автоматизации этого процесса, желания не хватило... А все что надо сделать это привинтить экспорт одной библиотеки на MC++ к другой на C# путем перекомпиляции с потерей возможности отладки в условиях визуальной студии. Поэтому те кто пишет на MC++ могут обойтись одной библиотекой.

Самый быстрый и простой способ создать промежуточную библиотеку с экспортируемыми функциями, это создать проект VisualC++ - Win32 Project, указать тип приложения DLL и в опциях Export symbols. После создания необходимо включить поддержку Common Language Runtime Support (/clr) и отключить Entry point, так как из точки входа библиотеки нельзя использовать CLR. Для большей четкости характеризации API можно добавить так же .def файл.

Пример .def файла: Объявления модуля

LIBRARY    "myexport.dll"
EXPORTS
    MyFunction

Пример функции вызываемой и продекларированной в советнике .cpp файле:

#include "stdafx.h"
 
using namespace mylibrary;
 
__declspec(dllexport) int __stdcall MyFunction( signed char* symbol ) {
    return mylibrary::MyFunction( symbol );
}

Это единственные два файла которые понадобятся, помимо stdafx, без которых тоже можно обойтись, проект получается мизерным, при условии того что вы хотите использовать C# вы должны использовать два проекта библиотек в одном решении. И указать в экспортном проекте в свойствах связь с проектом библиотеки. Все просто до безумия:)

Вы используете статические функции класов для вызова из экспортных функций. Достаточно одного вызова, чтобы загрузились все библиотеки в терминал GC и AppDomain.

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

P.S.: Если кого-то это интересует, задавайте конкретные вопросы по существу, получите конкретные ответы по существу:)

P.P.S.: Если кто-то знает лучшие способы внедрения .NET кода в пределах советника и того же процесса, поделитесь, а главное C# библиотек, я незнаю. Тема появилась достаточно давно, но вопрос, хоть кто-то ее обуздал?

 
А может стоит статью написать на эту тему?
 
Vinin:
А может стоит статью написать на эту тему?


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

Есть мнения, да, надо написать, а есть ли мнения, а о чем надо написать? О чем бы вы хотели прочитать? Как глубоко нужно написать?

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

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

Предположим что я могу предоставить и открыть эти данные, вопрос тогда заключается в другом, это будет востребовано или об этом нужно написать?

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

 
Уважаемые господа,

такой способ работы, вообще говоря, дает нам к.-л. преимущества перед стандартными средствами (типа файлообмена) совместной работы VS и MQL? Помимо упоминаемой в ранее поднимавшейся теме "производительности файловой системы"?

BRGDS
 
Проще говоря, вспомните что такое отладка при разработке, вспомните что любой участок кода вы можете пройти пошагово, войти в отладчик на стопах или по созданному исключению, увидеть своими глазами где ошибка и моментально ее исправить и т.д. Это касаемо того, что недоступно в MQL и доступно в VS, а что такое совместная работа приложения в памяти процесса, это мнгновенный доступ к информации. Это не файл обмен и не использование виртуальной памяти, это прямой доступ даже не пересекая процесс, такой же, как из скрипта MQL. Управляемая среда в неуправляемом приложении, при больших возможностях, таких же какими обладает разработчик, говорить о производительности не приходится... Приходится думать только о том как получить данные с которыми вы работаете в MQL и что естественно, это тоже реализуемо, вопрос лишь в направлении усилий и обладании необходимыми знаниями для этого. Здесь есть два выхода, либо эти возможности дает разработчик и сам их контролирует, либо эти возможности распространяют сами пользователи и опять же сами их контролируют, последнее, черевато постоянными проблеммами с каждым изменением терминала, в моем случае так и есть, я использую внутренние возможности терминала в обход предложенным. Естественно самому приходится додумываться какие и где в памяти структуры, используя несколько программ для работы в памяти, включая самописные, вылавливать куски информации сравнивать работу нескольких терминалов и разных источников данных, для того чтобы максимально избежать проблемм как при появлении новой сборки терминала, так и при совершенно разных обстоятельствах использования.
 
Можно осуществлять обмен данными такой связкой (MT <-> MQL) <-> UserDLL <-> UserEXE
Я делаю это через WM_COPYDATA. Через файл это медленно.
UserEXE может быть написан и в среде .NET
Я лично так и делаю. Связка получается очень стабильная. Работает сутками без проблем.
Перезапуск одной из сторон связки не требует перезапуска другой (стороны MT и UserEXE)
В UserEXE можно отлаживать по шагам любую свою стратегию,  оптимизацию или ещё что-то служебное.
Если интересно то могу написать статью с примерами исходного кода.
Надеюсь в приложении .NET можно создать обработчик событий (виндус сообщений) - callback function
Win32API можно использовать я это знаю и даже указатели можно использовать а для обмена данными
через WM_COPYDATA без них не обойтись. Реализовать это в C++ и Delphi нет проблем.
 
И вам доброе утро:) Я тоже использую подобные связки, но не в этом дело, дело в том, что на подобные реализации используется много времени, много больше чем могло бы быть:) Но меня до сих пор эта тема не отпускает, в виду того, что мои методы основаны на данных с которыми работает терминал, а не которые получает советник, это быстрее и позволяет обрабатывать одновременно множество валютных пар, индексов и т.д. если хотите реализация мультивалютного анализа, которая реагирует на скоротечное изменение рынка сразу же и сразу же можно видеть обстановку на основе, благодаря которой можно делать определенные выводы, большинство заблуждается в том, что работа с тиками не дает результатов, работа с тиками дает ясность в источнике и я бы не сказал, что это обязательно должно быть скальпирование, это предсказуемость непредсказуемого рынка.
 
Ты хочешь сказать что ты имеешь доступ к таймсериям и другим данным необходимым и функциям MQL API напрямую из адресного пространсва MT?
Ну это интересно конечно с учётом того что отладку DLL запретили. Мне ещё не понравилось весь свой код с остратегией в длл размещать потому что если советник вызывающий эту длл был убран с чарта совсем не означает что DLL освобождена будет и скомпилировать новую версию без закрытия терминала нельзя. поэтому у меня всё в моём EXE файле. Но если тебе удалось как то другим способом минуя MQL4 код иметь доступ к данным терминала и вызывать функции то это интересно конечно. Напиши статейку на эту тему если конечно такое хакерство пропустит цензура MQ ;).
Хотя ты сам сетовал на то что вот достум к каким то данным имеешь но если выпусят новый билд или произойдёт изменение размера этого буфера и этот блок будет перемещён в памяти на другое место то твои жёсткие привязки к адресам рассыпятся. Вот такой подход как раз таки не надёжный и потребует много времени на доводку.
 

Отладку DLL не запретили, к этому привело внедрение системы безопасности кода, например, я так понимаю что это защита тех же советников от декомпиляции и т.д. Которую желали видеть разработчики. Причина и следствие. Мне кажется что смысла утаивать информацию, которую получает тот же советник у разработчиков небыло, однако вид предоставления информации оставляет желать лучшего. В то время как терминал работает с последовательным потоком тиков всех выбранных символов, на основе которого так же строит историю, советнику достаются объедки или издержки производства.

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

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

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

 

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

Четвертое, использование и получение данных, которыми владеет терминал.(под вопросом цензуры).

А без цензуры остается доставка данных через функции в цикле поток которого морозится, которой я сам очень относительно пользуюсь. Это обработка строковых данных, то есть значение строки используется как структура доставки обратно. Только в сторону советника, плодить ненужные функции терпения нехватает.

Например для получения события о доставке тиков есть зарегистрированное событие, если взять Spy++ то без труда можно заметить зарегистрированное событие главного окна с wparam == 0x2, самое простой способ получить события главного окна это переназначить процедуру обработки сообщений. После чего я уже достаю сами тики. Дескриптор окна можно получить функцией FindWindowW( "MetaQuotes::MetaTrader::4.00", 0 ), о событие отсеять путем удовлетворения условия внутри процедуры ( msg >= 0xC000 && msg <= 0xFFFF ). Это думаю в рамках цензуры, но думается мне, почему в рамки цензуры попадают данные полученные из адресного пространства терминала и выходят ли они вообще за рамки цензуры.

Как я вообще узнал о том что существует такой буфер, очень просто есть файл ticks.raw, при недолгом рассмотрении, становится ясно что структурно он состоит из 40 байтовых структур, где 12 байт наименование тика, 4 байта дата и время, Bid и Ask по восемь байт, а так же 8 байт или 4 байта индекс поставки, при обычном общении терминала индексы этого файла последовательны, при прерывах наблюдается, что сервер возвращает новый тик с пропущеным числом тиков. Далее, вы ищем с помощью WinHex имя первого символа этого файла. Проще искать всю 40 байтную структуру. И вот мы находим как правило адрес 0x01E70020, мы нашли искомый файл. Но недостаточно иметь файл нужно иметь данные о нем. Так как этот файл, распологается в самом начале элемента кучи, мы ищем этот адрес и находим, коротенькую структу, однако эта структура в зависимости от последовательности загрузки плавает, то бишь перераспределяется в свободном месте, путем несложных операций, мы находим адрес блока памяти который остается постоянным при всех изменениях. И того мы имеем постоянный адрес, данные о буфере и сам буфер, работать с ним не сложно.

Вобщем это пример последовательности поиска данных.

Подобные данные мы превращаем в интерфейсы доступа и систематически используем эти данные, вот и все, это не самое сложное, что можно сделать для удобства.

 
Но я всё же буду использовать подход работы связки а не напрямую обращение к их структурам. Да и вызывать их методы MQL мне всё же нужно и историю баров подкачивать в свой exe
Но смотря у кого какие цели. Думаю надо использовать подходы против которых не против MQ. Не знаю как тебе щас удаётся отлаживать свою длл вызываемую из МТ. Я пробовал подключиться для отладки к их процессу как в делфи так и в вижуал си и ничего не получается. Видимо ты нашёл какой то другой подход для отладки DLL может быть подскажешь как более подробно?
12345
Новый комментарий
Причина обращения: