Вообщем зхадача не из легких.
Есть SDI где-то с 20 представлениями. К каждому классу представления подключены еще отдельные заголовки других классов, для кнопочек, баз данных, и прочеих женских прелестей.
Мне нужно ВЕСЬ проект разбить на либы-каждое представление - либа.
1.Как по умному перенести готовые классы представлений.
2.Как быть с подключенными файлами других классов
У меня уже начинает болеть голова..

Если конечно есть веские причины тогда конечно можно разнести. берешь бумажку и рисуешь все классы проги и смотришь как они взаимодействуют друг с другом. А потом пытаешься делить.. Какие-то общие классы выделяешь в отдельную dll и потом подключаешь ее к exe и всем dll-кам представлений.. примерно так.

Это сообщение отредактировал(а) nikf - 3.11.2005, 15:26

Цитата(nikf @ 3.11.2005, 15:25)

Какие-то общие классы выделяешь в отдельную dll и потом подключаешь ее к exe и всем dll-кам представлений.. примерно так.

Вот у меня есть общие классы, которые подключаются к окнам.
Я их выношу в отдельную dll.
Что дальше? нужно подгружать их вв dll ,в которой они используются?
Т.е. получается паровоз? А что делать в ехе? Будет ли видеть прога функции dll. которые присоединяются к другой dll? Или надо все подключать в ехе?

Цитата(Coocky @ 3.11.2005, 15:51)

Что дальше? нужно подгружать их вв dll ,в которой они используются?

Просто dependences установи. Ты не сказал, но я надеюсь, все это можно оставить в одном воркспэйсе (солюшене).

Цитата(Coocky @ 3.11.2005, 15:51)

Будет ли видеть прога функции dll. которые присоединяются к другой dll? Или надо все подключать в ехе?

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

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

Цитата(Coocky @ 3.11.2005, 15:51)

нужно подгружать их вв dll ,в которой они используются?

ты же используешь неявное подключение dll(я так думаю) Тогда тебе не надо заботится ни о каких "подгрузках". Честно скажу у мня солюшн был максимум четыре проекта 1exe и 3dll(vs7). насчет двадцати не знаю - потянет ли, главное чтобы все компилировалось в один каталог и были доступны lib-ы и хидеры. все прозрачно для отладчика, работаешь как с одним проектом и проблем быть не должно..

Это сообщение отредактировал(а) nikf - 3.11.2005, 20:27

Цитата(Coocky @ 3.11.2005, 14:51)

Т.е. получается паровоз? А что делать в ехе? Будет ли видеть прога функции dll. которые присоединяются к другой dll? Или надо все подключать в ехе?

На самом деле разбить все на ДЛЛ это очень хорошо. Все идет паровозом Главное про SHARED_DATA не забывать. Желательно не использовать MFC классы на стыке Application<->DLL (интерфейс)

А что за SDI? Если это однотипные диалоги, то продумать интерфейс вызова этих ДЛЛ.

К примеру, у меня есть "проект пустышка", его задача держать связь с сервером и запускать нужные ДЛЛ по запросу пользователя. Продумал интерфес, который должны соблюдать все длл и последовательность вызова. Все... Теперь несколько человек пишут свои независимые ДЛЛ, а я лишь в xml файле создаю ассоциации: событие - ДЛЛ, т.е. по такому-то событию должна вызываться такая-то ДЛЛ.

У меня типа такого интерфейса:

Код

... #if defined (_WINDLL) && defined (_AFXDLL) AFX_EXT_API int   WINAPI _TInit(LPCTSTR pNameWindow,int iMode, void* pBufer, UINT Length ); AFX_EXT_API int   WINAPI _TDeInit(void* pBufer, UINT Length ); AFX_EXT_API int   WINAPI _TStart(int iPar); AFX_EXT_API int   WINAPI _TStop(int iPar); ... #endif ...

pBufer - это структура для инициализации ДЛЛ, или данные с которыми должна работать данная длл.

А вот, такой меню файл (xml), где прописываю очередной пункт меню, ДЛЛ и путь к ней:

Код

<menu name="&Tests">   <item name="COSU-11 rev. 2 ( CDSP6B / SP 059 410 )" sp="SP059410" dir="\Tests\M20\" dll=WS.dll" />    <item name="COSU-11 rev. 4 ( CDSP6B / SP 059 410 )" sp="SP059410" dir="\Tests\M21\" dll="SD.dll" />    <item name="COSU-12 rev. 2 ( CDSP6B / SP 059 430 )" sp="SP059430" dir="\Tests\M22\" dll="WS.dll" />    <item name="COSU-12 rev. 4 ( CDSP6B / SP 059 430 )" sp="SP059430" dir="\Tests\M20 Test1\AllCPCI\" dll="SD.dll" />    <item name="COSU-14 ( CDSP6B / SP 059 481 )" sp="SP059481" dir="\Tests\AllCPCI\" dll="DF.dll" />    <item name="MOSU-11 ( CDSP6B / SP 051 307 )" sp="SP051307" dir="\Tests\AllCPCI\" dll="KL.dll" />    <item name="PMC D2 ( PMCD2 / SP 059 477 )" sp="SP059477" dir="\Tests\M19\" dll="OP.dll" />  </menu>

Так же можно указывать свои иницилизационные параметры, для каждой отдельной ДЛЛ.
Добавлено @ 21:21
А для "разноса" проекта по ДЛЛ рекомендую применить передовую технологию copy-past

Цитата(bel_nikita @ 3.11.2005, 21:14)

Главное про SHARED_DATA не забывать

Цитата(bel_nikita @ 3.11.2005, 21:14)

Желательно не использовать MFC классы на стыке Application<->DLL (интерфейс)

Цитата(bel_nikita @ 3.11.2005, 21:14)

А для "разноса" проекта по ДЛЛ рекомендую применить передовую технологию copy-past

Earnest

Цитата

Просто dependences установи.

Я понял, что ничего незнаю об МФС ДЛЛ
Добавлено @ 21:45
bel_nikita

Цитата(bel_nikita @ 3.11.2005, 21:14)

А вот, такой меню файл (xml), где прописываю очередной пункт меню, ДЛЛ и путь к ней:

Старина, я не так крут

Это сообщение отредактировал(а) Coocky - 3.11.2005, 21:47

Coocky
Работа с библиотеками динамической компоновки (DLL)
http://www.citforum.ru/book/cook/dll1.shtml
http://vingrad.ru/CPP-FAQ-001916

Создал свой класс в длл,производный от диалога class My_Dll.
Добавил функцию void My_Dll::Create_Dialog ();
внутри нее вызвал Create(IDD_DIALOG1);

Подключил все к проге, а она не видит Mydll.Create_Dialog ();
А вот Mydll.Create(IDD_DIALOG) видит(правда не видит IDD_DIALOG1, ну это и понятно).
Если кому не трудно, напишите простенький пример, как экспортировать класс. Что б я понял, как правильно.
Чуйка у меня, что не правильно в заголовочном файле длл директивы препроцессора прописую..

Coocky
а не смотрел ссылки? там как раз есть про экспорт MFC классов
Добавлено @ 12:21
могу примерчик проекта сделать, но только вечером

bel_nikita
Очень прошу!
Сделай MFC extension Dll проект, добавь любой диалог. и добавь функцию к классу диалога(к примеру void Coocky_stuped()
)
И посмотри-отобразится ли в твоем примере ехе вызов этой функции

1. Создаем стандартный MFC проект MainAppl.
2. Добавляем итем в меню и создаем событие:

Код

.... BEGIN_MESSAGE_MAP(CMainFrame, CFrameWnd)     //{{AFX_MSG_MAP(CMainFrame)     ON_WM_CREATE()     ON_WM_SETFOCUS()     ON_COMMAND(ID_COOCKY_DLL, OnCoockyDll)     //}}AFX_MSG_MAP END_MESSAGE_MAP() ... void CMainFrame::OnCoockyDll()  {   // TODO: Add your command handler code here   // Здесь будем вызывать методы DLL }

4. В опциях проекта прописывам _AFXEXT и выставляем Debug Multithreaded DLL ( по другому: /MDd /D "_AFXEXT" )
5. Делаем ребилд.

Теперь займемся нашей DLL:

6. Создаем в той же директории, что и MainAppl, MFC extensions DLL. У нас это проект CoockyDLL.
7. Создаем в ресурсах диалог и его класс. У нас это CDialogCoocky : public CDialog.
8. Создаем классовую функцию Coocky_Is_You_Function:

Код

void CDialogCoocky::Coocky_Is_You_Function() {   AfxMessageBox("Coocky! This is you function from dll"); }

9. Вставляем макрос AFX_EXT_CLASS:

Код

... class AFX_EXT_CLASS CDialogCoocky : public CDialog { ...

10. Комментируем: //enum { IDD = IDD_DIALOG1 };

Код

... class AFX_EXT_CLASS CDialogCoocky : public CDialog { // Construction public:     void Coocky_Is_You_Function();     CDialogCoocky(CWnd* pParent = NULL);   // standard constructor // Dialog Data     //{{AFX_DATA(CDialogCoocky)     //enum { IDD = IDD_DIALOG1 };         // NOTE: the ClassWizard will add data members here     //}}AFX_DATA ...

11. Открываем DialogCoocky.cpp и прописываем: IDD_DIALOG1

Код

CDialogCoocky::CDialogCoocky(CWnd* pParent /*=NULL*/)     : CDialog(/*CDialogCoocky::IDD*/IDD_DIALOG1, pParent) {     //{{AFX_DATA_INIT(CDialogCoocky)         // NOTE: the ClassWizard will add member initialization here     //}}AFX_DATA_INIT }

12. В файле StdAfx.h прописываем: #include "resource.h"
13. Делаем ребилд. Наша DLL готова.

Возвращаемся к нашему MainAppl.

14. Подключаем к проекту файл DialogCoocky.h
15. В файле StdAfx.h прописываем: #include "CoockyDLL/DialogCoocky.h"
16. В файле StdAfx.cpp прописываем:

Код

#if defined (_DEBUG)   /************************************************************************/   /*  DEBUG *.LIBs                                                        */   /************************************************************************/   #pragma comment(lib,"CoockyDLL/Debug/CoockyDLL.lib") #else   /************************************************************************/   /*  RELEASE *.LIBs                                                      */   /************************************************************************/   #pragma comment(lib,"CoockyDLL/Release/CoockyDLL.lib") #endif  //  _DEBUG

17. Теперь возвратимся к нашей функции OnCoockyDll(), в которой вызываем диалог из DLL:

Код

void CMainFrame::OnCoockyDll()  {   // TODO: Add your command handler code here   CDialogCoocky Dlg;   Dlg.Coocky_Is_You_Function();   Dlg.DoModal(); }

18. Делаем ребилд проекта.
19. Копируем нашу CoockyDLL.dll в %PROJECT\Debug\
20. Нажимаем Execute MainAppl.exe и наслаждаемся

З.Ы.: проблемы типа: а чего в моей длл вызываются ресурсы ехе проекта - не рассматривались и мною опущены да бы не заниматься лишней писаниной

Это сообщение отредактировал(а) bel_nikita - 4.11.2005, 21:09

Присоединённый файл ( Кол-во скачиваний: 2 )
 MainAppl.zip 43,88 Kb

Ехе архив

Присоединённый файл ( Кол-во скачиваний: 3 )
 Exe.zip 14,53 Kb

Цитата(bel_nikita @ 4.11.2005, 21:05)

4. В опциях проекта прописывам _AFXEXT и выставляем Debug Multithreaded DLL ( по другому: /MDd /D "_AFXEXT" )

Итак анализируем.
Этому меня неучили да и в мануалах ненашел!
Может из-зи этого трабла у меня была.
Сейчас гляну
Добавлено @ 12:50

Код

// CoockyDLL.odl : type library source for CoockyDLL.dll // This file will be processed by the MIDL compiler to produce the // type library (CoockyDLL.tlb). [ uuid(938670D9-AC66-4DE1-B946-D0D6CD86952B), version(1.0) ] library CoockyDLL {     importlib("stdole32.tlb");     importlib("stdole2.tlb");     //{{AFX_APPEND_ODL}}     //}}AFX_APPEND_ODL}} };

Этого у меня нет..Но это наверное код "шестерки"

Coocky

Цитата

Этого у меня нет..Но это наверное код "шестерки"

Видать это я галочку на Automation выставил Это не нужно и не на что не должно влиять

Цитата(bel_nikita @ 7.11.2005, 12:56)

Видать это я галочку на Automation выставил

Стоп,стоп стоп..
Дык при выбре MFC extension dll блокируется галочка Automation
Ты какой тип проекта создавал?

Цитата(Coocky @ 7.11.2005, 14:30)

[QUOTE=bel_nikita, 7.11.2005, 12:56]Дык при выбре MFC extension dll блокируется галочка Automation Ты какой тип проекта создавал?

MFC extension создавал это точно.

Цитата(bel_nikita @ 7.11.2005, 15:48)

MFC extension создавал  это точно

Ну раз ТОЧНО, тогда я спокоен..

Coocky
Еще раз попробывал. У меня ничего не блокируется. Могу бырать Automation и Win Sockets. Проект MFC Extension DLL.
Все это пробывалось на MSVC6 SP6.

Coocky
1) Dependencies - это команда Project->Dependencies, и там галки ставишь, что от чего зависит.
2) 20 и более проектов среда тянет легко.
3) Чтобы что-то экспортировать, нужно в объявлении функции или класса в источнике (DLL) написать __declspec(dllexport), а в клиенте (EXE) - __declspec(dllimport). Так как обычно объявления пишут в хедерах, и не хочется их дублировать для DLL и EXE, обычно делают что-то вроде (см. MFC):

Код

#ifdef _AFXEXT         #define AFX_EXT_API         __declspec(dllexport)      #else         #define AFX_EXT_API         __declspec(dllimport)      #endif

При этом символ _AFXEXT у тебя определен в DLL (т.е. там ты имеешь экспорт). А в EXE - cоответственно, импорт.
Только для этого символ _AFXEXT и нужен.

НО: если есть некая общая DLL, функциями/классами которой пользуются другие (т.е. есть зависимость между библиотеками), такой фокус не пройдет. У обеих библиотек символ _AFXEXT определен - получается, все экспортируется - и свое, и чужое.
Тогда для каждой DLL нужно завести свой символ, и написать подобные объявления.

Скажем, есть DLL MegaSuperDLL. Для нее определяем символ _MEGASUPER (в параметрах препроцессора). Далее, создаем хедер MegaSuper.h:

Код

#ifdef _MEGASUPER         #define MEGASUPER_API         __declspec(dllexport)      #else         #define MEGASUPER_API         __declspec(dllimport)      #endif

Далее, пишем класс, который будет экспортироваться:

Код

#include "MegaSuper.h" class MEGASUPER_API CMyClass { };

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

Earnest
Совсем запутали...
Смотри, что у bel_nikita
Файл Dll.h (библиотеки)

Код

class AFX_EXT_CLASS CDialogCoocky : public CDialog { // Construction public:     void Coocky_Is_You_Function();     CDialogCoocky(CWnd* pParent = NULL);   // standard constructor // Dialog Data     //{{AFX_DATA(CDialogCoocky)     //enum { IDD = IDD_DIALOG1 };         // NOTE: the ClassWizard will add data members here     //}}AFX_DATA // Overrides     // ClassWizard generated virtual function overrides     //{{AFX_VIRTUAL(CDialogCoocky)     protected:     virtual void DoDataExchange(CDataExchange* pDX);    // DDX/DDV support     //}}AFX_VIRTUAL // Implementation protected:     // Generated message map functions     //{{AFX_MSG(CDialogCoocky)         // NOTE: the ClassWizard will add member functions here     //}}AFX_MSG     DECLARE_MESSAGE_MAP() };

Dll.cpp стандартный, как у ЕХЕ.
В опциях проекта Dll добавлено в С++-> Preprocessor ->Preprocessor Definition _AFXEXT
ВСЕ!
В ЕХЕ просто продублирован класс, как в длл, и также настроен препроцессор.
Просто класс я ля копи-пасте..
Так что же делать? Кто прав? Как правильно?
Вообще у меня не работало, из-за неправильного описания препроцессора.
Но кто из вас прав?
Хотя похожи методы, но вроде попроще у bel_nikita
Добавлено @ 18:26

Цитата(bel_nikita @ 7.11.2005, 16:07)

Еще раз попробывал. У меня ничего не блокируется. Могу бырать Automation и Win Sockets. Проект MFC Extension DLL. Все это пробывалось на MSVC6 SP6.

Дружище, давно пора переходить на новые компиляторы..
В семерке запрещает..

Вопросы в догонку...
Можно ли установить неявно подключаемую длл не каталоге исполняемого модуля. Если да , то как( а то длл много, хочу по папкам раскидать..)
То что lib прописывается -это одно, а вот длл -то ищется в каталоге exe...
Добавлено @ 18:53
Как правильно пользоваться
AfxGetResourceHandle();
AfxSetResourceHandle();
для использования ресурсов длл, а не проекта..

Coocky
У нас почти одно и то же. Я просто тебе в чем суть попыталась объяснить.

1) Посмотри что такое AFX_EXT_CLASS - это ровно __declspec(dllexport) или __declspec(dllimport), в зависимости от наличия _AFXEXT.

2) Дублировать объявления классов нехорошо! А поддержка?!!! Это же застрелиться можно - в нескольких местах синхронно править!!
Лучше использовать один и тот же хедер. Символ типа AFX_EXT_CLASS для того и нужен, чтобы по разному интерпретироваться в зависимости от модуля, в котором это компилируется.

3)

Цитата(Coocky @ 8.11.2005, 18:25)

В опциях проекта Dll добавлено в С++-> Preprocessor ->Preprocessor Definition _AFXEXT ВСЕ!

Все - это если у тебя нет зависимости между разными extension DLL. А если есть - простой метод не пройдет - нужны разные символы, для каждой DLL свой.
А так - суть та же.