Форум: "Основная";
Текущий архив: 2002.02.28;
Скачать: [xml.tar.bz2];
ВнизНекоторые замечания к статье Найти похожие ветки
← →
Sleepyhead (http://www.excelsior-usa.com/) (2002-02-04 14:26) [4]Здравствуйте!
Целью моих замечаний было не развертывание каких-либо дискуссий насчет целесообразности использования сторонних DLL в Delphi-программах и наоборот, а обозначение действительно существующих проблем в этой "пограничной" области. Как правило, программисты не от хорошей жизни "смешивают" программы, разработанные под разными СП, а из жизненной необходимости. В особенности, когда часть программы используется очень давно, и ее переписывание - слишком дорогое удовольствие. Другой пример - разработка привычных GUI приложений в некоторых СП хотя и возможна, но крайне затруднена и обременительна (писать на чистом Win API, конечно, можно, но не многие это любят - а большиство сейчас просто не умеет). Поэтому экономически целесообразно разработать графический интерфейс, например, на Delphi, и использовать его в существующих программах. Именно такой случай я и имею в виду, говоря об экспорте форм из DLL.
Насчет соглашения о вызовах stdcall, боюсь, что вы в данном случае не правы. Если вы разрабатываете программу на С, то по соглашению о вызовах stdcall, вызываемая функция очищает стек - за исключением случая, когда она принимает переменное число параметров. В этом случае вызываемая функция просто не знает, какое количество аргументов ей передали! Вызывающая функци обязана при вызове функций с переменным числом аргументов сама зачищать стек после вызова. Это одно из, я бы сказал, "болотных" мест в С/C++, которые вам, знатоку Delphi, простительно не знать. Попробуйте написать маленький пример и посмотреть (в дизассемблере), как происходит передача и прием параметров в таких случаях. Очевидно, что попытки использовать такие функции в Delphi (Object Pascal"е) ни к чему хорошему не приведут. Именно на это я постарался обратить внимание.
Конечно, DLL никак не обязана поддерживать чью-либо объектную модель (гм... мне кажется, я нигде и не говорил этого). А RTP (Run-time Package) - это вообще совершенно из другой области, никакого отношения к использованию Delphi-программ в других программах, разработанных под другими системами программирования не имеет.
Что касается "всем сестрам по серьге", т.е. раздачи событий в оконном интерфейсе, то, конечно же, по сравнению с обычным способом (GetMessage -> TranslateMessage -> DispatchMessage), VCL работает не так, для примера могу порекомендовать посмотреть исходники Forms.pas, function TApplication.ProcessMessage, в особенности на используемые функции IsHintMsg, IsMDIMsg, IsKeyMsg, IsDlgMsg. Для корректной работы VCL вы обязаны использовать метод Run (который, впрочем, ничего особого не делает, кроме как крутит цикл пока не надоест). Таким образом, из-за различия в дизайне визуальных библиотек VCL и той, которая используется для "главной" программы (например, хоть MFC) программа не будет работать.
Именно из-за особенностей работы Delphi-программ с графическим контекстом, практически никогда нельзя доступаться (точнее, модифицировать) графические компоненты ИЗ ВТОРИЧНЫХ ПОТОКОВ без Delphi-синхронизации (не спроста рекомендуют все "заворачивать" в Synchronize метод потока, но, к сожалению, в alien-программе нет возможно использовать дельфевый же класс...)
Если вы не сталкивались ни с одной из указанных проблем, то вам крупно повезло! :-) Желаю и дальше с ними не иметь дела!
Надеюсь, что теперь-то уж точно ни вопросов, ни претензий не осталось. :-)
До свидания,
Sleepyhead
P.S. Чтобы такого сдулать плохого? Пойду еще статей почитаю, глядишь к чему-нибудь прикопаюсь... Ну, вот например http://delphi.mastak.ru/articles/Dapi/index.html от Ketmar"а. :-)
P.P.S. Я и правда не хочу докопаться до кого-нибудь. Я только стараюсь не оставить неясностей - потому и написал эти свои замечания к статье про использование DLL.
Страницы: 1 вся ветка
Форум: "Основная";
Текущий архив: 2002.02.28;
Скачать: [xml.tar.bz2];
Память: 0.45 MB
Время: 0.005 c