Обсуждение статьи "Руководство по написанию DLL для MQL5 на Delphi" - страница 2

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

Спасибо за комментарий. Думаю, что этот раздел можно расширить дополнив его наиболее популярными ошибками. Однако, чтобы не искать ошибки "долго и безуспешно" сделайте всё как написано в статье. Примеры в ней работоспособные. Кроме того, используйте отладчик в MetaEditor, он довольно приличный, с пошаговой отладкой и точками останова! 

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

 

Здравствуйте HideYourRichess

Какой Вы шустрый! Столько написали! Вам бы писать собственные статьи на тематику Delphi.

 Постараюсь ответить кратко и по порядку:

1. Юниты SysUtils и Classes  нужно было оставить в проекте.

SysUtils есть в проекте! Classes ни к чему! Обработчик исключений помимо SysUtils реализован в System который подключен по умолчанию, так что не вижу повода для беспокойств. 

2.      Не следует использовать в рамках DllEntryPoint (он же DllMain) всякие процедуры.

Пример с DllEntryPoint  приведен в интернете на каждом углу. Это штатный способ создания событий DLL, к которым, например, можно привязать выделение и освобождение памяти из кучи. Если у Вас с этим методом работы с памятью будут реальные ошибки, готов рассмотреть.

На счёт всего остального, чего нельзя делать в DllEntryPoint, я не спорю, т.к. не часто это использую.

3.      На счёт менеджера памяти Вы много писали. Выделю лишь ваш вывод:

Таким образом можно сделать так, что у DLL и приложения будет единый менеджер памяти, и это будет менеджер памяти MT4.

Проблема в том, что никто из нас не знает, как устроен менеджер памяти в MT5(MT4). И даже если бы мы узнали имена функций реализующий этот менеджер, как Вы собираетесь его использовать, ведь API для MT5 закрытый! Так что идея единого менеджера MT5 и DLL это утопия.

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

 Очень рассчитываю на то, что вместо цитирования здесь книг и статей по Delphi, автору статьи будут высказаны претензии только в связи с тем, что реально не работает из того что описано в статье. Желательно с примерами.

 

 
avoitenko :

Спасибо за комментарий. Думаю, что этот раздел можно расширить дополнив его наиболее популярными ошибками. Однако, чтобы не искать ошибки "долго и безуспешно" сделайте всё как написано в статье. Примеры в ней работоспособные. Кроме того, используйте отладчик в MetaEditor, он довольно приличный, с пошаговой отладкой и точками останова! 

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

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

Матчасть тут ни при чем, зато при чем средства отладки. Вспомним известную статистику "80 на 20": 80% времени уходит на отладку, и лишь 20% на написание кода. Задача статьи, насколько я понимаю, научить написанию работоспособной DLL, т.е. не только того конкретного примера, который приведен, но и гипотетического другого кода. Разумеется, невозможно рассмотреть все потенциальные ошибки, но нужна информация, как их в принципе ловить. В противном случае, читатели не смогут ничего сделать кроме воспроизведения примера.

MetaEditor тут тоже ни при чем, т.к. мы говорим об отладке DLL, т.е. её внутренностей.

Вы автор - Вам виднее. Я всего лишь высказал свое мнение относительно некоторой незавершенности в изложении.

 
"Какой Вы шустрый! Столько написали! Вам бы писать собственные статьи на тематику Delphi."

Это отрывки из старой статьи по длл для мт4, недописанной. Сюда я просто скопипастил отрывки. Это не сложно и недолго.

"SysUtils есть в проекте! Classes ни к чему! Обработчик исключений помимо SysUtils реализован в System который подключен по умолчанию, так что не вижу повода для беспокойств. "

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

"Пример с DllEntryPoint  приведен в интернете на каждом углу. Это штатный способ создания событий DLL, к которым, например,"

Борланды не случайно скрыли DllMain, от шаловливых ручек. Штатный способ создания Dll в Дельфи - со скрытым DllMain. Подумайте, - почему так. И почитайте, что там сам майкрософт рекомендует.

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

Дело хозяйское. Но моя рекомендация состоит в том, что в DllMain вообще ничего не нужно делать.

"Проблема в том, что никто из нас не знает, как устроен менеджер памяти в MT5(MT4). И даже если бы мы узнали имена функций реализующий этот менеджер, как Вы собираетесь его использовать, ведь API для MT5 закрытый! Так что идея единого менеджера MT5 и DLL это утопия."

;-) для кого то "закрыто" и "утопия" -а у кого то "всё работает". речь о четвёрке. как в пятёрке - не смотрел.

 

в статье есть такая процедура :

//----------------------------------------------------------+
procedure DLLEntryPoint(dwReason: DWord); // обработчик событий
//----------------------------------------------------------+
begin
    case dwReason of

      DLL_PROCESS_ATTACH: // DLL присоединена к процессу;
          // выделение памяти
          Buffer:=AllocMem(BUFFER_SIZE);

      DLL_PROCESS_DETACH: // DLL отсоединена от процесса;
          // освобождение памяти
          FreeMem(Buffer);

    end;
end;

На что компилятор мне задает вопрос что за необьявленная переменная BUFFER_SIZE

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

 
lucka88:

На что компилятор мне задает вопрос что за необьявленная переменная BUFFER_SIZE

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

В файле проекта dll_mql5.dpr присутствует объявление

const BUFFER_SIZE = 255;

Строкой кода

Buffer:=AllocMem(BUFFER_SIZE); 

в куче выделяется память для хранения строки.

А сам указатель Buffer используется в функции GetStringBuffer, которая демонстрирует работу со строками.

 

При подключении эксперта в МТ5 пишет ошибку "dll is not 64-bit version".

Можно ли как-то использовать 32bit dll?

Если нет, может кто подскажет, как в Delphi XE скомпилировать 64it dll?

 
meneo:

как в Delphi XE скомпилировать 64it dll?

Поддержка 64 bit появлась в Delphi XE2 и Lazarus.
 

помогите кто может ..

в delphi 7 dll процедура.. 

procedure test1(var data: array of Double); stdcall;
begin
  ShowMessage('Вошли ');   

end;

в mt4 :

#import "gayss.dll"
   void test1( double &data[] );
#import

ArrayResize(data, 6);
data[0]= 2;
data[1]= 4;
data[2]= 8;
data[3]= 16;
data[4]= 21;

data[5]= 3;

test1(data);

и ошибка вылазит.. 2014.02.06 17:39:04.241  stack damaged, check DLL function call in 'SOG_2014.mq4' (80,7)

может кто знает как надо по правильному..

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