Использование .NET, это возможно, задумайтесь над этим.

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

Я здесь на кануне приблизился к законам бытия, на самом деле можно было бы внедрить .NET в треминал при этом обеспечив некоторую поддержку MQL, для этого достаточно добавить в терминал одну опцию: Разрешить использование .NET. Добавляем одну библиотеку, которую напишем на MC++. Для инициализации библиотеки которую можем загрузить как при запуске программы, так и в любое другое время, используем LoadLibrary, но так как правила не позволяют нам использовать точку входа библиотеки, мы используем экспортированную функцию dotnet_init() и dotnet_deinit() для выгрузки библиотеку и всей оснастки CLR. При инициализации библиотеки создается по умочанию AppDomain("DefaultDomain"), который мы можем так же выгрузить с помощью dotnet_deinit(), одновременно со всеми используемыми сборками, проводя вызов AppDomainю.Current.Unload().


При этом в компилятор мы добавляем дерективу для использования сборок #assembly "Имя сборки" например вот такое имя: "XNSNET. Xwe.Module, XNSNET.Xwe, PublicKeyToken=a1eef0445caa076a" в реальность это загрузка экземпляра класса в этой сборке с необходимым контекстом. Его можно пометить атрибутом используя наследование класса из нашей либы. Для использования этой директивы мы к примеру будем применять dotnet_assembly( char* iAssemblyName ). В дальнейшем мы перечисляем функции допустимые к применению в самом языке, это будут функции загруженного экземпляра класса со сходными типами. Для компилятора можно даже добавить сравнение реальности существования этих функций и сопоставление типов.


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

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


Например для того чтобы не передавать контекст класса, в такого рода функции:

// Приблизительно такой способ используется сейчас
 
#import "dotnetex.dll"
    int dotnet_init();
    int dotnet_deinit();
 
    int dotnet_handle( int &context, string assembly );
    bool dotnet_reload( int &context, string assembly );
    bool dotnet_remove( int &context, string assembly );
    bool dotnet_delete( int &context, string assembly );
 
    int dotnet_call( int &context, string method );
#import
 
int Context = 0;
 
int init() {
    return( dotnet_init() );
}
 
int start() {
    dotnet_handle(Context, "Test.MyClass, Test" );
    Print( dotnet_call(Context, "GetNumber" ) );
    return( 1 );
}
 
int deinit() {
    return( dotnet_deinit() );
}
 
// А вот такой способ может быть реализован только в компиляторе
 
#assembly "Test.MyClass, Test" Test
    int GetNumber();
#assembly
 
int start() {
    Print( TestGetNumber() );
}

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

Рефлекторные возможности .NET позволяют отслеживать все существующее и не существующее.

Вобщем отписывайте свои мысли, я отвечу на все вопросы, если вам что-то не до конца понятно.

 
Я нихрена не понял, но тема близка :)
 
dr-Wicked писал (а):
Я нихрена не понял, но тема близка :)

К счастью я понимаю и себя и вас, поэтому конкретнее, что именно вы не поняли, я попытаюсь высказаться на более понятном языке:) Кстати по этой же причине я не буду посвещать для этого дела статей или делать описания, потому как мой текст к сожалению поймут лишь единицы, а двадцать раз переписывать, я могу только программы и посты на форумах, на все остальное терпения нехватает:) К тому же, добровольцев найти не сложно:)
 
После редактирования стало немного понятнее :)
В общем необходимо реализовать CLR хост, как это сделано в эксплорере и MSSQL2005
Но наверное проше :).
 
В точку, но нужно хорошенько подумать как это сделать так чтобы можно было им пользоваться не выходя из логики MQL, при этом давая возможность пользоваться не статическими методами классов, написанных специально для терминала, а уже там можно воротить что необходимо. Вся проблемма со сложностью в том, что это не известно когда будет реализовано, а тут вполне можно обойтись трудом по крайней мере двух разработчиков, причем на интузиазме, самое главное чтобы это имело поддержку, в ином случае это превращается в гиморой, потому что эта часть примера илистрирует лишь основы, попробуй в обе стороны передать Строку, при использовании промежуточной памяти, надо выполнить дополнительно еще по крайней мере одну функцию, чтобы выгрузить память, при не использовании, с доступными методами, это потребует большего времени. И того, такого барахла набирается достаточно, сохранить простоту не удастся.

При передачи в управляемую память все достаточно просто:

bool RetWindowException( Exception^ e ) {

return ( (gcnew WindowException( e ))->ShowDialog( MainWindow::Current ) == DialogResult::Retry );

}


DOTNETEX int WINAPI dotnet_handle( int* iContex, char* iName ) {

Retry:

try {

return Global::Assemblies->AddContext( iContex, gcnew String( iName ) )->Handle;

} catch( Exception^ e ) {

if ( RetWindowException( e ) ) goto Retry;

}

return 0;

}


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

Кроме того есть такие правила, которые используются, запрет DLL для участия в конкурсах, неужели их запрещают просто так, уж не потому ли что это возможность распространения вредоносного кода, который не возможно контролировать, но .NET контролировать можно в отличии от низкоуровневого кода. Хоть и не так просто как в MQL. Однако мы сейчас говорим не о полной замене MQL, пускай все то, что есть останется и будет востребовано, пускай потребуется исполозовать это чудо юдо, внутри скриптов, но совсем не поддерживать, это больше похоже на незнание и не хотение, нежели чем на разумное расширение возможностей и удобства реализации потребностей:) Простыми словами я не люблю и не хочу предлагать данный контекст решения как неофициальное раширение возможностей терминала, для этого потребуется поддержка каждой новой версии терминала, в измененной адресации, все это хорошо известно и единственный выход, повлиять на развитие ситуации. Чем я собственно и занимаюсь:)

Мои действия в этом направлении, это моя собственная необходимость и инициатива, все остальное носит исключительно рекомендательный характер:) Хоть и выглядит это жестко:)
 
xnsnet:



Так и не понял - зачем все это нужно? Может дождаться MQL5? Там по
слухам уже будут классы. Может и возможности расширятся.
 
Может и поддержка .NET будет? Вы это имели ввиду? Или вы считаете что можно переработать существующие разработки, под условия среды разработки? Бесконечно писать и повторять существующий код? Изобретать велосипед, одной модели, затем другой модели, может наладить серийный выпуск велосипедов?

Я не пойму о чем именно вы говорите:)

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

Я могу, но боюсь они озадачат, зачем мне все это надо было, на этот вопрос я сам не могу ответить... В итоге я даже SQL запросы перевожу в .NET и этому даже нашлась полноценная поддержка в С# 3.0 проект LINQ, что означает что не только я пытаюсь придти к чему-то одному в достижении всех поставленных задач. Это было ясно с начала перехода на .NET. Поэтому его поддержка является для многих удобоваримым звеном во всем, что касается межплатформенного и межязывого взаимодействия. Вы же не думаете что на MetaTrader все клином сошлось. Да, MetaTrader является одним из интересующих меня направлений, но почему я каждый раз должен жертвовать своим удобством и каждый раз все переписывать, жертвуя своим удобством, упираясь в новые границы или другие побочные факторы. Многие за свою жизнь написали не один десяток программ и пришли к определенным результатам в своих трудах, помимо реализации конкретного проекта, которые хотят использовать и в других программах. А бывают такие случаи как, как в случае с MQL, которые составляют большую часть проблеммы. Так как это не написание самой программы, и разработчику не положено знать код этой программы, несмотря на то что приходилось и взломом заниматься ради благих целей, но я считаю это самым последним что должен знать разработчик, потому как на такой подход можно угробить еще больше времени, чем на суть решения этого вопроса, спрашивается зачем, если сейчас проще найти что-то другое, но тогда возникает еще один вопрос, зачем искать что-то другое.
 
xnsnet:
Может и поддержка .NET будет? Вы это имели ввиду?

Сколько языков программирования вы изучили, сколько сменили, ради удовлетворения собственных потребностей? Сколько технологий вам известно, сколько вы используете? Вы знаете что такое повторно используемый код? Вы знаете лучший способ в погоне за технологическим превосходством?

Звиняйте! Я не програмер, а технарь. Почти всю жизнь кодил на СИ - для моих сугубо прикладных
задач этого было более чем достаточно. На мой взгляд инструментов и возможностей для
реализации изощренного автоматического трейдинга даже в MQL4 более чем достаточно.
Запросы особых эстетов наверное сможет удовлетворить MQL5, хотя поддержки .NET там
насколько я понял не будет.

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

А если уж вам так нравится .NET технологии , ну есть ведь торговые платфомы построенные
на их основе (конкретно писать не буду - обсуждение брокеров запрещено, но есть) , может
попробовать себя там?
 

Первый вопрос, а чего я тогда делал здесь? Второй вопрос, а в чем суть идеи без удобства? И что такое удобство?

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

 
Вероятность того что в мт4 будет реализована возможность поддержки NET = 0.
Разработчики уже не раз давали понять что никаких изменений (кроме исправления ошибок) вносится не будет.
Возможно разработчики прислушаются к вашим пожеланиям и в мт5 это реализуют.
На подобные темы вопрос вставал уже многократно - ответ всегда один - нет.
У меня есть встречный вопрос - вы писали что у вас есть опыт работы с различными языками,
вот я и хотел спросить (возможно у вас есть подобный опыт) есть ли возможность подключить к mql обекты ActiveX используя встроенные средства windows а не создавать для этого спец dll.

 
 
xeon:
Вероятность того что в мт4 будет реализована возможность поддержки NET = 0.
Разработчики уже не раз давали понять что никаких изменений (кроме исправления ошибок) вносится не будет.
Возможно разработчики прислушаются к вашим пожеланиям и в мт5 это реализуют.
На подобные темы вопрос вставал уже многократно - ответ всегда один - нет.
У меня есть встречный вопрос - вы писали что у вас есть опыт работы с различными языками,
вот я и хотел спросить (возможно у вас есть подобный опыт) есть ли возможность подключить к mql обекты ActiveX используя встроенные средства windows а не создавать для этого спец dll.


Уж что касаемо ActiveX что равносильно COM я ушел от этого, еще при переходе на .NET.
В остальном что толку спрашивать? Если вы берете MSDN и изучаете, хотя на мой взгляд
время для подобных попыток кончилось еще лет шесть назад вместе с таким языком как VB 6:)
Первая проблемма, требуется обязательная регистрация такого компонента в системе, в папку просто не положешь.
Хотя для постоянных компонентов это удобно, библиотеку с места не сдвинешь, тот же Flash = ActiveX, и каков
его уровень востребованности. Когда-то я пытался написать что-то на подобие флеша, по свойму, но в одиночку
так никуда и пришел, так эксперементы не более. ActiveX на .NET для одного куда реальнее.
Надо помнить что объектное программирование без объектной среды или без адаптера не возможно.

Кроме того как вы представляете использование ActiveX в MetaTrader, без библиотеки, как вы реализуете интерфейсы?
Я еще понимаю по смещениям в памяти, a MQL разве позволяет работать с памятью по адресам?
Попробуйте извратится со стандартными функциями Kernel32.dll, но это разве не Библиотека?
Помойму .NET гораздо проще использовать в таком же маштабе, даже не смотря на задачу и то
без библиотеки не обойтись, хотя возможно с выходом "Orcas" это будет меньшей проблеммой, пока только слухи,
много видео роликов и тестовая версия "Orcas" на виртуалке, которую мне тестить совсем не хочется, хватило
бета экспириенса 2005 студии, по частям я уже поюзал все лучшие новшества того же C# 3.0 этого мне хватит.
Да и с помощью того же .NET это делается в два прихлопа, вам бы понравилось, потому как это следующий этап,
а следующий этап в микрософте означает поддержку всех приведущих. Кроме того, все эти техногии еще долго
будут на ходу, потому что на корпоративном уровне они не заменимы, по той причине что писать что-то новое, это затраты
и потребность в большей производительности, которая зачастую не своевременна. Но время то идет:)

Для реализации хоста в CLR по большому счету тоже надо использовать интерфейсы, того же MSCOREE.h но для всего
этого нет полноценной документации, а методом тыка много не добьешься, равносильно взлому, все методом тыка, чуть проще.
Хотя я могу сказать что набор предельно простой и понятный, получается намного проще написать библиотеку на MC++.
Все идет к упрощению и поверьте, это не просто так, лениво становится все, что делается намного проще. Написав одну строчку,
гораздо приятнее получить сразу все то, для чего требовалось написание сотен строк, а то и тысяч...

Вы зачем-то пытаетесь идти к прошлому, гироморой на душу брать, спрашивается зачем, если надо идти только вперед и не оглядываться?
В конце концов я не просто так опустил список технологий с которыми я имел дело, по той причине что все они прошлое...
А вот технологии настоящего вполне уместны для рассмотрения, хотя чаще всего только со стороны реализации для .NET.
Я бы так же не указывал и языки, все равно я сейчас максимум на что соглашаюсь это на MC++ и то только по причине
совместимости DLL в сотальном только C#, еще иногда приходился в IDAPro ковырятся, где без знаний ASM никуда...

Хотя за ЗП в 10 штук евро в месяц я готов писать на любом языке:))) И то не факт, смотря что:)))
12345
Новый комментарий