Помогите в CPropertySheet добавить CPropertyPage из DLL

TestEXE.cpp


TestDLL.h

TestDLL.cpp

TestDLL.rc
    

Это сообщение отредактировал(а) Bukmop - 1.6.2006, 18:14

Единственная проблема там - ресурсы. Вот пример для родительского диалога в ехе, а child-ового в dll


Делай аналогично 

Не совсем понял, куда это девать.
Поэтому уточнил задачу.
 

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

Нет практически никакой разницы, где определен класс-страница - в другой DLL или в том модуле, где создается PropertySheet. Достаточно просто сделать класс экспортируемым. Можно не весь класс, а только конструктор и деструктор. Дальше все, как у тебя в коде.

Экспортировать можно 2 способами:

1) __declspec( dllimport )\__declspec( dllexport ):
экспортируемая сущность должна быть объявлена в своем модуле как __declspec( dllexport ),
а в чужом - как __declspec( dllimport )
Проще всего это достигается макросом:



Макросимвол _TESTDLL нужно определить для всего проекта TestDll (в свойствах проекта)

2) def - файл. Просто поместить имена всех нужных функций в def-файл.
На самом деле это не очень просто, т.к. имена должны быть декорированными, т.е. такими, как их видит линкер. Но можно сделать так: сначала ничего никуда не пишем, а просто пытаемся собрать приложение. Линкер будет орать насчет неразрешенных ссылок. Акуратно копируем имена, которые он хочет, прямо из сообщения об ошибке, и помещаем их в def- файл. Выглядеть будет примерно так:



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

Это сообщение отредактировал(а) Earnest - 1.6.2006, 17:16

Подобное, я уже пробовал, используя встроенный в MFC макрос AFX_EXT_CLASS. Но я понял так, что это для экспорта класса на стадии компиляции, а не выполнения. Короче, линкер по-прежнему ругался. 

Там весь код включая и PropertySheet? 

Значит, что-то ты сделал неправильно.
Если DLL одна, то вполне можно обойтись макросом AFX_EXT_CLASS, только чтобы он заработал, DLL должна быть создана как ExtensionDLL (кроме всего прочего, в проект добавляется макросимвол _AFXEXT, а без него, конечно, не получится).

В общем, опиши, что ты сделал, и какие ошибки дает линкер.

Добавлено @ 18:19 

Нет, как я понимаю, код Property Sheet находится в EXE.
 

Earnest, ты как всегда всё правильно понимаешь, а я очень извиняюсь за ложную информацию (сам уже начал путаться в результатах попыток, голова уже плохо соображает). В том случае всё скомпилировалось, но вытащить страницу не получилось.
Делал так:

Получал p1=NULL;

А если бы делал всё правильно – то всё бы работало (чудес-то не бывает).   

Это сообщение отредактировал(а) Bukmop - 1.6.2006, 19:08

Да уж, зову не знамо кого...   А оно и не отзывается почему-то...
Вообще-то при такой связи с DLL ее лучше не динамически подключать, а прямо к проекту, чтобы еще линкер все ссылки разрешил.
Так ты разобрался в конце концов? 

Я тычусь как слепой котёнок, т.к. не понимаю, как правильно сделать, сижу и перебираю все мыслимые и немыслимые варианты (пока впустую).
Вот последний:
DLL

EXE

 
Благодарю за терпение, по себе знаю как трудно с такими... Но мне уже начинает казаться, что я хочу невозможного. 

Это сообщение отредактировал(а) Bukmop - 1.6.2006, 19:25

Bukmop, так ответь на простые вопросы:
1. Где находится твой ProperySheet( dll\exe )?
2. Где находится PropertPage( dll\exe )?
3. Где ты создаешь твой PropertySheet( dll\exe )?


P.S. LoadLibrary тут не нужен 

DeadSoul
1. exe
2. dll
3. exe
 
P.S. Смысл: Есть dll-ки - есть странички. Нет dll-ек - нет страничек. Изменились свойства dll-ек - не нужно трогать exe-ник.
   

Это сообщение отредактировал(а) Bukmop - 1.6.2006, 19:43

4. Как ты получаешь доступ к классам\функция в dll
- прописываешь в exe все необходимые *.h+*.lib
- LoadLibrary+GetProcAddress 

4. Пытался - LoadLibrary+GetProcAddress.

lib мне не подходит, т.к. при изменении dll-ки придётся перекомпилировать exe-шник.
 

Это сообщение отредактировал(а) Bukmop - 1.6.2006, 21:01

Так бы сразу и сказал, что тебе обязательно нужно загружать DLL динамически.
Тогда действительно, LoadLibrary + GetProcAddress. НО: получить через GetProcAddress можно только то, что есть в таблице экспорта. Поскольку экспортировать придется через def-файл, то с классами возиться сложно (надо ведь декорированные имена записывать для всех функций),
Поэтому делаем так:
1) К EXE ничего не подключаем (h-файла с описанием страницы), придется ему довольствоваться интерфейсом CPropertyPage.
2) В DLL создаем функцию CPropertyPage* CreatePage(/* нужные параметры */). Причем объявляем ее как extern "C", чтобы не мучиться с именами. И записываем в def-файл. Вот только не помню, это будет просто CreatePage или _CreatePage, нужно уточнить. Впрочем, с неправильной записью в def-файле DLL не соберется.Еще можно уточнить имя с помощью map-файла.
3) Дальше все как ты делал, GetProcAddress c тем именем, что записано в def.
4) Только теперь у тебя выделена память под страницу, поэтому не забудь ее удалить после DoModal.
5) Не уверена, что по delete будет вызван правильный деструктор. Я бы проверила, поставив туда точку прерывания...

 

Достаточно второго.


Нужно добавить вторую функцию DestroyPage

Вчера вечером попробывал. Там действительно неслабые траблы(похоже, с ресурсами). Сегодня еще поковыряюсь 

Не совсем. 
Запись в def - необходима, без extern "C" можно обойтись, но имена C++ функций довольно сложно декорируются, именно декорированные имена и надо указывать в def (а потом в GetProcAddress). Если в def написать просто CreatePage, DLL не соберется (с точки зрения линкера, такой функции нет).


Хоть и написала сама, что проверить надо, но как-то это странно: ведь деструктор-то виртуальный. Тогда что, и другие виртуальные ф-и работать не будут? Как же интересно COM работает на одних виртуальных вызовах без всяких экспортов...
Наверняка "трабла" не в этом. И не в ресурсах. Не может быть там никаких проблем, если все правильно делать. 

У меня почему-то собралось и успшно работало....



Выделять\освобождать память нужно внутри одного модуля, т.е. не рекомендуется выделять память в exe, а осовобождать в dll(и наоборот)



Это абсолютно другая история.



В них. Только в них. Готов показать кодом. 

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


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

Давай, только желательно покороче.   Если про ресурсы. Если про delete - не надо, согласна, что проблемы могут быть. 

Насколько помню все зависит от линковки рантайма(динамическая\статическая)



Так у меня все падает при попытке создания страницы



Сейчас нарисуем
 

Вот пример(Компилятор - 8-ая студия).

P.S.  Заметь extern "C" нигде нет 

Присоединённый файл ( Кол-во скачиваний: 6 )
 TestPropPage.rar 62,74 Kb

Нашёл два отличия с тем, что делал я:
1. Мой EXE-шник - Use MFC in a Static Library
2. Моя DLL-ка - MFC extension DLL

Но и после всего этого выдаёт - "A required resource was unavailable".
 

Bukmop, я знаю. Я и хотел показать, что там проблема ровно одна - ресурсы.

Добавлено @ 16:25 
Сейчас покопаюсь еще. Может смогу ресурсы победить.

Добавлено @ 16:33 
В общем, выход ровно один. Отнаследоватся от CPropertySheet и переопределить BuildPropPageArray 

СПАСИБО!
Твой вариант я работать заставил.

И он таки нашёл ресурс.

Теперь буду воевать со своим Static Library.
   

Это сообщение отредактировал(а) Bukmop - 2.6.2006, 17:03

DeadSoul, не могу загрузить твой проект, т.к. у меня нет 8й студии, а в 7 эта зараза грузиться не желает... 
Так что придется всухую...


Это неправильно, все должно использовать Shared MFC DLL, это приведет к Shared RunTime DLL. Тогда, по идее проблем с памятью не должно быть.
Кроме того, динамически загружаемая DLL лучше делать Regular, хотя все равно не понимаю, откуда проблемы с ресурсами.

... Посмотрела код ...  Как насчет вот этого?


В смысле, в начало кода CreatePage нужно вставить
 AFX_MANAGE_STATE(AfxGetStaticModuleState());

Не знаю, почему extern "C" перестал быть нужен... раньше (в 6-ке) было нужно ... 

Посмотри  просто cpp\h\def файлы. Там добавления к стандартным проектам минимальны.


Не спасет. Доступ к ресурсу нужен в момент создания окна, а окно создается совсем не там

Рад за тебя. Я-то слона не заметил.... 

Была не права:  лучше делать Extension DLL из-за проблем со картой окон...
Тогда, конечно, AFX_MANAGE_STATE(AfxGetStaticModuleState()) не надо.
Руками сделала проекты в 7 студии (диалоговое приложение + extension DLL), добавила туда файлы, все нормально трудится. Желаете проект?

Добавлено @ 17:30 

Меня спасло, но потом пошли ASSERTы из-за WndMap, и пришлось переделывать на Extension DLL. 
  

Это сообщение отредактировал(а) Earnest - 2.6.2006, 17:31

Earnest, у меня тоже 7.1, но т.к. в проекте нет ничего навороченного я просто в файлах vcproj исправил Version="8,00" на "7.10", а в sln ...Format Version 9.00 на 8.00
И VS это всё прекрасно переварила.

А проблема с ресурсами видимо из-за того, что сама Page  крейтится уже в Sheet-е. 

(Безобразие!!! Мало того, что до четырёх часов вообще не мог достучаться до форума. И сейчас перебои. Не успеваю за жизнью.) 

Проект конечно желаю!
 

Это сообщение отредактировал(а) Bukmop - 2.6.2006, 17:44

Bukmop, нет там проблем: я просто сделала свой проект и добавила туда файлы, все получилось. Вот проект, под 7.1.
А насет экспорта я тоже поняла: DeadSoul использовал нумерацию (@1). Действительно, в этом случае линкер как-то без декораций обходится, но я так никогда не делала, поэтому и забыла    

Упс! Не глядя заархивировала прямо с объектниками... То смотрю никак загрузиться не может. 

Это сообщение отредактировал(а) Earnest - 2.6.2006, 17:56

Присоединённый файл ( Кол-во скачиваний: 8 )
 DeadSoul.rar 121,65 Kb

Ужас! Это получается, что я почти неделю стоял на ушах, дошёл до полного маразма и Вас на два дня озадачил. И всё только потому, что  у меня основной проект - Static (так уж давно повелось, таковы были требования).

И что теперь делать? Я так понял, что в Static - это без шансов.

Спасибо всем за помощь и глубокие знания.
Надеюсь, я Вам не мешал (ШУТКА).
  

Это сообщение отредактировал(а) Bukmop - 2.6.2006, 21:42

Не только. С моей точки зрения основная трабла была в ресурсах.



   

В Static она так и осталась.
 

При статической линковки MFC-ей?

Добавлено @ 22:18 
Bukmop, ты можешь показать как победил ресурсы? Что и куда ты вписал? 

DeadSoul, именно при статической линковке MFC-ей я проблему так и не решил. Теперь буду решать, продолжать биться как рыба об лёд или переписывать все ранее созданные библиотеки этого проекта на Shared DLL.

О ресурсах:
В твоём примере (как я уже упоминал) после получения в EXE-ке указателя на "CPropertyPage" из DLL-ки, принудительно поменял HINSTANCE в структуре PROPSHEETPAGE на DLL-ный.
А пример Earnest и так работает.
 

Не знаю, получится ли победить ситуацию, если оставить MFC DLL статически прилинкованной. Думаю, что нет. Там ведь в чем дело-то: в MFC есть объект (какой-то трам-пам-пам-state, который синхронизирует доступ к различным ресурсам, в том числе к ресурсам-RC, а также картам окон (т.е. HWND-CWnd) и т.д. Чтобы все работало, нужно, чтобы эта штука была в приложениии одна. Если каждый модуль будет использовать свой экземляр статически прилинкованной MFC DLL, то и этот менеджер у всех будет свой... В общем, не договорятся. Кроме того, использование статической MFC влечет за собой статический RunTime, т.е. у каждого модуля будет свой распределитель памяти, и отсюда проблемы с освобождением "чужой" памяти.
Таким образом, статическая линковка MFC подходит только для приложения, которое состоит из одного EXE. 

Earnest, почему в твоем примере нет проблем с ресурсами?


В каком месте ты это менял? 

 
Строка - 21.
 

Это сообщение отредактировал(а) Bukmop - 3.6.2006, 12:48

Bukmop, thanks. Как-то не посмотрел, что этот мембер открытый. 

       

Earnest, честно говоря, хотеось бы более развернутый ответ 

DeadSoul, там всё оказалось просто. Earnest использовала MFC extension DLL, а там создаётся CDynLinkLibrary и по этому AfxFindResourceHandle находит нужный ресурс.
 

Извини, я просто не очень поняла, вопрос это или наезд   

В дополнение к тому, что уже сказал Bukmop:
WinAPI, чтобы найти ресурс, нужно указать точно в каком модуле он лежит.
MFC это дело слегка скрывает: ExtensionDLL связываются в цепочку, которая хранится во внутренней глобальной переменной. Когда ты запрашиваешь ресурс, MFC проходит по цепочке, опрашивая все библиотеки по очереди, пока не найдет нужный. 

 

Bukmop, Earnest, спасибо.