[vc++] static library met dialog

[Boy]

Ik heb momenteel een MFC programma gemaakt met 1 dialoog (ja, en een about box).

Nu wil ik eigenlijk van dit project een library maken en dat deze kan worden toegevoegd in een ander project, zodat deze dit dialoog kan openen met bijvoorbeeld een button.

Nu heb ik via new... etc een static library project gemaakt, alle files aan het project toegevoegd en ik krijg de library gemaakt. Maar nu heb ik een nieuw programma gemaakt, de library toegevoegd aan dit project en de headerfile voor het dialoog (zoiets als libDlg.h).

In dit nieuwe project heb ik aan de dialoog class een instantie toegevoegd ( CTestDlg testDlg; )

onder een button roep ik nu aan:

testDlg.DoModal();

Maar dan kreeg ik een assert failure want hij zal nog niet geinitialiseerd zijn.

Vervolgens probeer ik deze te initialiseren met testDlg.OnInitDialog, maar die is protected.

Als ik een eigen init() aanmaak en hetgene copy-paste (ik weet het, allemaal niet zo mooi, maar ik probeer door te krijgen hoe het werkt) dan kan hij niet bij CDialog::OnInitDialog. Deze zal hij toch nodig hebben om m'n schermpje te maken?

Ik heb op GoT zitten zoeken en googlen naar een voorbeeldapplicatie waar zoiets wordt gedaan (dialog uit een library), maar niets gevonden.

Iemand een tip voor mij?

[riezebosch]

kan je in die class geen public functie maken vanwaaruit je eventuele private functies aan kunt roepen?

[Boy]

Sorry, wat vergeten te melden.

Ik heb dus wel een public functie gemaakt die die OnInitDialog aanroept, maar het gaat mis binnen CDialog::OnInitDialog.

Het gaat hier mis bij

code:

    // send update message to all controls after all other siblings loaded
    if (bSuccess)
        SendMessageToDescendants(WM_INITIALUPDATE, 0, 0, FALSE, FALSE);

de assert van ASSERT(::IsWindow(m_hWnd)) gaat hier mis.

[MSalters]

OnInitDialog is net zoals alle OnX functies een functie die door MFC wordt aangeroepen als X gebeurt. Het is niet de functie die zorgt dat X gebeurt. Ik vermoed dat je .Create( ) zoekt.

[Boy]

MSalters schreef op vrijdag 29 juli 2005 @ 11:37:
OnInitDialog is net zoals alle OnX functies een functie die door MFC wordt aangeroepen als X gebeurt. Het is niet de functie die zorgt dat X gebeurt. Ik vermoed dat je .Create( ) zoekt.

Inderdaad, ik denk dat ik gewoon verkeerd aan het aanroepen ben. Ik heb die create nu aangeroepen en als eerste parameter iets als IDD_TEST_DIALOG meegegeven. Nu krijg ik een foutmelding van "Error: no data exchange control with ID 0x03F0."

Die ga ik eens uitzoeken of ik erachter kom wat hier fout gaat...

[Boy]

Hij kan niet bij de resource komen van het project in die library.

Is het wel mogelijk om een dialoog in een library te krijgen? Ik heb bijv. een nieuw project aangemaakt voor een static library, maar als ik insert->new form doe, dan zegt hij dat dat niet ondersteunt wordt in dit project type

[MSalters]

Ja, het kan gewoon. Moet je natuurlijk wel een MFC library project maken

[Verwijderd]

Boy schreef op vrijdag 29 juli 2005 @ 13:06:
Hij kan niet bij de resource komen van het project in die library.

Is het wel mogelijk om een dialoog in een library te krijgen? Ik heb bijv. een nieuw project aangemaakt voor een static library, maar als ik insert->new form doe, dan zegt hij dat dat niet ondersteunt wordt in dit project type

Daar kan ik me ook wel wat bij voorstellen. Een static library wordt als het ware met tie-wraps aan je applicatie vastgemaakt tijdens het linken en dat kan in het geval van resources best moeilijk zijn (zeker met de IDE's die automatisch resources nummeren enzo).

Een dialog in een DLL is daarentegen weer geen enkel probleem, dan moet je er alleen even aan denken om de dialog resource wel uit de dialoog te laden in plaats van de applicatie resources.

[Boy]

Verwijderd schreef op vrijdag 29 juli 2005 @ 13:35:
[...]


Daar kan ik me ook wel wat bij voorstellen. Een static library wordt als het ware met tie-wraps aan je applicatie vastgemaakt tijdens het linken en dat kan in het geval van resources best moeilijk zijn (zeker met de IDE's die automatisch resources nummeren enzo).

Een dialog in een DLL is daarentegen weer geen enkel probleem, dan moet je er alleen even aan denken om de dialog resource wel uit de dialoog te laden in plaats van de applicatie resources.

Inderdaad, ik zie dat ik inderdaad iets verkeerds heb met die resources.

Ik heb nu snel een kleine (lege) applicatie gemaakt met dat standaard ok/cancel form. als ik nu doe:

testApplDlg.Create(IDD_TESTAPPL_DIALOG);
dan zie ik dat IDD_TESTAPPL_DIALOG gelijk is aan 102. Maar het nummer van dit dialog in de library is dus gelijk aan die van de applicatie waar ik deze library in gebruik...maw hij opent nogmaals het form wat al open is

Kan ik niet zeggen 'je moet de resource.h uit het project van de library gebruiken!' ? Zit deze resource.h wel in de library? lijkt mij toch wel?

[MSalters]

Nee. Een resource.h is een header file en zit nooit in je .lib

[The End]

Je moet het dialog gewoon starten met DoModal(). Wat voor assertion krijg je?

Ik heb ook wel eens zoiets gemaakt. Ik roep echter het dialog niet direct aan, maar via een call naar de library. (Bij mij is ie overgens dynamisch gelinked) Je maakt dan het dialog object in die call en en roept daarin DoModal() aan.

[Boy]

Hoe krijg ik dat conflict dan gefixt?

Momenteel dus een library met een standaard 'new project'-wizard programma genaamd 'testApplDlg'.

Die library toegevoegd aan een project genaamd 'ApplicationUsingLib'.

aan 'applicationUsingLibDlg.h' heb ik toegevoegd:

[c++]
#include "..\testAppl\testApplDlg.h"
[/c++]

en in de class onder public

[c++]
CTestApplDlg testApplDlg;
[/c++]

toegevoegd.

Onder de OK button heb ik het volgende gezet:

[c++]
testApplDlg.Create(IDD_TESTAPPL_DIALOG);

testApplDlg.DoModal();
[/c++]

en dan krijg ik dus het probleem dat hij niet het dialoog van de library opent, maar (nog eens) het dialoog van de applicatie die het aanroept en vervolgens een assert error (dlgCore.cpp line 459).

[The End]

Boy schreef op vrijdag 29 juli 2005 @ 14:09:
Hoe krijg ik dat conflict dan gefixt?

knip

code:

    testApplDlg.Create(IDD_TESTAPPL_DIALOG);

    testApplDlg.DoModal();

Je moet geen create en DoModal aanroepen. DoModal roept zelf al create aan. Dit is dus dubbel...

[Boy]

The End schreef op vrijdag 29 juli 2005 @ 14:11:
[...]


Je moet geen create en DoModal aanroepen. DoModal roept zelf al create aan. Dit is dus dubbel...

Inderdaad, nu krijg ik geen assert error. Maar hij doet dus wel nog steeds zijn eigen scherm nog eens openen ipv die in de library, omdat de waardes van beide identifiers 102 is.

[The End]

Boy schreef op vrijdag 29 juli 2005 @ 14:14:
[...]


Inderdaad, nu krijg ik geen assert error. Maar hij doet dus wel nog steeds zijn eigen scherm nog eens openen ipv die in de library, omdat de waardes van beide identifiers 102 is.

Nee, maar als je een export functie maakt in die library waarin je het object creeert en DoModal() aanroept, dan is het probleem opgelost..

[Boy]

The End schreef op vrijdag 29 juli 2005 @ 14:19:
[...]


Nee, maar als je een export functie maakt in die library waarin je het object creeert en DoModal() aanroept, dan is het probleem opgelost..

Het spijt me, maar ik begrijp even niet wat een export functie is...

edit:

lijkt erop dat dit alleen werkt bij dll's? als ik snel even google...

[ Voor 13% gewijzigd door Boy op 29-07-2005 14:25 ]

[The End]

Boy schreef op vrijdag 29 juli 2005 @ 14:22:
[...]


Het spijt me, maar ik begrijp even niet wat een export functie is...

edit:

lijkt erop dat dit alleen werkt bij dll's? als ik snel even google...

Maak gewoon een headerfile met 1 functie erin: "INT_PTR ShowMyDialog();"
Maak een cpp file met je functie:

code:

INT_PTR ShowMyDialog()
{
   CMyDialog MyDialog;
   return MyDialog.DoModal();
}

Compileer de library.

Voeg de headerfile toe aan je andere project. Roep de functie aan als je op de button klikt.

[ Voor 3% gewijzigd door The End op 29-07-2005 14:37 ]

[riezebosch]

Boy schreef op vrijdag 29 juli 2005 @ 14:09:
[...]
[c++]
#include "..\testAppl\testApplDlg.h"
[/c++]
[...]

Kleine tip: code werkt met [code=c++] ... [/code] tags

[Boy]

The End schreef op vrijdag 29 juli 2005 @ 14:36:
[...]

Maak gewoon een headerfile met 1 functie erin: "INT_PTR ShowMyDialog();"
Maak een cpp file met je functie:

code:

INT_PTR ShowMyDialog()
{
   CMyDialog MyDialog;
   return MyDialog.DoModal();
}

Compileer de library.

Voeg de headerfile toe aan je andere project. Roep de functie aan als je op de button klikt.

Nope, gebeurd nog steeds hetzelfde, opent nogmaals het scherm wat gewoon open is. dit is de code in de cpp file:

C++:

#include "..\testAppl\test2\StdAfx.h"
#include "..\testAppl\test2\Resource.h"     // main symbols

#include "..\testAppl\test2\test2Dlg.h"

INT_PTR ShowMyDialog()
{
   CTest2Dlg MyDialog;
   return MyDialog.DoModal();
}

riezebosch schreef op vrijdag 29 juli 2005 @ 14:37:
[...]


Kleine tip: code werkt met [code=c++] ... [/code] tags

thanks

[ Voor 6% gewijzigd door Boy op 29-07-2005 15:22 ]

[The End]

Die header en cpp file moeten wel in je static library staan. Niet in je andere project. Daar moet alleen de header staan.

[Boy]

The End schreef op vrijdag 29 juli 2005 @ 15:38:
Die header en cpp file moeten wel in je static library staan. Niet in je andere project. Daar moet alleen de header staan.

Dat heb ik ook gedaan. Alleen de header gecopieerd naar dat andere project.

[Boy]

Ik kom nog steeds niet verder.

Wat ik eigenlijk wil is:

een library maken. als iemand de 'start()' functie aanroept vanuit zijn (dialog based) programma, moet er een scherm tevoorschijn komen met bijv. een edit box en nog wat dingen (maak niet zoveel uit voor dit probleem) waar gegevens op worden afgedrukt (deze worden via een thread vanuit een andere bron opgehaald, ook niet interessant voor het probleem).

Dus, een class welke een scherm kan openen om data weer te geven. Vreemd dat dit zo moeilijk is.
Als ik nu een static library project heb en ik doe 'add new form' dan zegt hij dat dat niet ondersteunt wordt in dit project type (preciese foutmelding: 'The New Form command is not supported for this project type'.

[.oisyn]

Het hele probleem is dat je je resource wel toe kunt voegen aan een library, maar die resource nergens gereferenced wordt waardoor hij niet meegelinkt wordt. Dit is een bekend probleem met resources in libraries, en er is volgens mij niet echt een oplossing anders dan de resource als binary data te includen in je library en dan een InitModalIndirect() oid te doen.

[ Voor 5% gewijzigd door .oisyn op 01-08-2005 10:30 ]

[Boy]

.oisyn schreef op maandag 01 augustus 2005 @ 10:29:
Het hele probleem is dat je je resource wel toe kunt voegen aan een library, maar die resource nergens gereferenced wordt waardoor hij niet meegelinkt wordt. Dit is een bekend probleem met resources in libraries, en er is volgens mij niet echt een oplossing anders dan de resource als binary data te includen in je library en dan een InitModalIndirect() oid te doen.

Mijn kennis is nog niet zo goed dat ik meteen zie wat je bedoelt, maar ik zal ermee gaan stoeien.

Ik kwam vanmorgen op deze pagina:
http://msdn.microsoft.com...sues/01/01/c/default.aspx

Zie daar de laatste Q/A waar dus bevestigd wordt wat jij zegt: het is gewoon klote

Maar anders zou ik toch maar een .dll moeten gaan maken (dat gaat heb ik gehoord wel makkelijk?). Ik vind een .lib gewoon mooier en wil het eigenlijk gewoon kunnen

[Killemov]

Een static library is meestal worst of both worlds. Als je die dialog in veel applicaties gaat gebruiken is een losse dll meestal het best. En anders moet je je dialog gewoon steeds in je app opnemen. Er is ook een tool om .dll's statisch aan je .exe te linken, ik kan nu alleen ff niet op de naam komen.

[Boy]

Killemov schreef op maandag 01 augustus 2005 @ 12:08:
Een static library is meestal worst of both worlds. Als je die dialog in veel applicaties gaat gebruiken is een losse dll meestal het best. En anders moet je je dialog gewoon steeds in je app opnemen. Er is ook een tool om .dll's statisch aan je .exe te linken, ik kan nu alleen ff niet op de naam komen.

Hij wordt niet in veel apps gebruikt, maar het gaat naar iemand anders toe die het gaat gebruiken, maar source mag niet mee...

[Boy]

Ik ben nu bezig met het proberen van het maken van een .dll. Ik heb 'm, heb ook een lib en exp erbij?

Zou iemand me verder op weg kunnen helpen? Met iets van een goede site waar het wat uitgelegd staat?

Hij komt nog steeds met die resources in de knoei. Hij geeft er een undeclared identifier fout over. Als ik de resource.h (hernoemd naar iets anders, omdat er al een resource.h bestaat) en die include in die header (de header is van de dll), zegt hij 'redefinition', want ik heb ook al andere resources met dezelfde naam.

Het moet toch kunnen om het geheel in een dll te stoppen??