DLL и Thread проблема
Есть у меня программка которая работает с COM портом. Чтение из порта выполняется в отдельном Thread. Решил я написать плагин к TotalCommander примерно такого же назначения что и прога. Взял тот же модуль для работы с COM портами, и он не работает из DLL. После вызова Synchronize в методе Thread.Execute поток почему то сам завершается, хотя тот же модуль в программе работает прекрасно. Подскажите в чем проблема может быть?
Откуда ты знаешь что делает TotalCommander с твоим потоком?
в этом и вся проблема
надо читать руководство по написанию плагинов к тоталу (или как оно там называется руководство или SDK или Manual)
в этом и вся проблема
надо читать руководство по написанию плагинов к тоталу (или как оно там называется руководство или SDK или Manual)
[quote=ahilles]
Откуда ты знаешь что делает TotalCommander с твоим потоком?
в этом и вся проблема
надо читать руководство по написанию плагинов к тоталу (или как оно там называется руководство или SDK или Manual)
[/quote]
Plugin Interface Description
можно скачать тут: http://www.ghisler.com/plugins.htm
Откуда ты знаешь что делает TotalCommander с твоим потоком?
в этом и вся проблема
надо читать руководство по написанию плагинов к тоталу (или как оно там называется руководство или SDK или Manual)
[/quote]
Plugin Interface Description
можно скачать тут: http://www.ghisler.com/plugins.htm
Цитата: o_serg
После вызова Synchronize в методе Thread.Execute поток почему то сам завершается, хотя тот же модуль в программе работает прекрасно.
Synchronize - это чисто дельфийский метод. Он производит синхронизацию (для выполнения потенциально потоконебезопасных действий), с главным потоком дельфийского приложения.
Тотал коммандер написан не на Делфи. Потому синхронизация скорее всего порождает неоке исключение, которое никем не перехватывается и вследствие этого поток завершается.
Тебе следует пересмотреть потоковую модель - возможно синхронизация вообще не нужна, а если и нужна, то производить её с помощью Вин32 АПИ.
Офтоп, конечно, но...
Цитата:
Тотал коммандер написан не на Делфи.
Откуда такие данные? Как раз таки тотал написан на дельфи (только версия ранняя).
только Win32 API
Total Commande v5 вроде написан на Delphi 4 (если я не ошибаюсь)
Total Commande v5 вроде написан на Delphi 4 (если я не ошибаюсь)
Немного погуглив, обнаружил, что он написан на Delphi 2 :)
Я тоже слышал что он на Делфи написан.
Plugin Interface Description - тут ничего по поводу Thread не написано.
А вообще есть какие то особые правила работы с Thread из DLL, может дело не в тотале?
Plugin Interface Description - тут ничего по поводу Thread не написано.
А вообще есть какие то особые правила работы с Thread из DLL, может дело не в тотале?
Тут может быть дело именно в Synchronize, который по сути является методом синхронизации с помощью оконного сообщения. Упрощенно это выглядит примерно так:
1. Экземпляр класса Thread формирует сообщение WM_XXX, которое содержит указатель на метод (тот самый, который передается в Synchronize) + еще некоторая служебная информация;
2. Сообщение посылается классу Application, который распознает это сообщение, и умеет его обрабатывать;
3. Thread ожидает результат обработки сообщения (используется SendMessage)
4. Экземпляр класса Application получает сообщение и вызывает метод по указателю (получается, что он вызывается в контексте оконного потока);
5. После обработки возвращается результат;
6. Экземпляр Thread возобновляет свою работу.
Здесь может быть несколько проблем:
Во первых, скорее всего Total не поддерживает данный механизм. Во вторых, в DLL создается свой объект Application. Ну и в третьих, есть такая штука, как менеджер кучи, который отвечает за распределение динамической памяти приложения, и хотя в твоя dll загружается в одно адресное пространство с total'ом, эти менеджеры у них разные. Отсюда ошибки при работе с динамической памятью (см. справку по borlandmm.dll).
1. Экземпляр класса Thread формирует сообщение WM_XXX, которое содержит указатель на метод (тот самый, который передается в Synchronize) + еще некоторая служебная информация;
2. Сообщение посылается классу Application, который распознает это сообщение, и умеет его обрабатывать;
3. Thread ожидает результат обработки сообщения (используется SendMessage)
4. Экземпляр класса Application получает сообщение и вызывает метод по указателю (получается, что он вызывается в контексте оконного потока);
5. После обработки возвращается результат;
6. Экземпляр Thread возобновляет свою работу.
Здесь может быть несколько проблем:
Во первых, скорее всего Total не поддерживает данный механизм. Во вторых, в DLL создается свой объект Application. Ну и в третьих, есть такая штука, как менеджер кучи, который отвечает за распределение динамической памяти приложения, и хотя в твоя dll загружается в одно адресное пространство с total'ом, эти менеджеры у них разные. Отсюда ошибки при работе с динамической памятью (см. справку по borlandmm.dll).
Я просто напросто убрал Synchronize, и вместо него вызвал процедуру напрямую. Вроде все работает, глюков не заметил. Но хотелось бы знать правильно ли это? Если нет, то чем можно заменить Synchronize в DLL.
Цитата: o_serg
Но хотелось бы знать правильно ли это? Если нет, то чем можно заменить Synchronize в DLL.
Synchronyze нужен для того чтобы изменять содержимое оконных компонентов. Если твоя процедура не производит операций с окнами, то скорее всего будет это безболезненно.