dlls mit Klassen?



  • naja, das sind nicht meine, aber ich kann ja das posten, was ich hab:

    In Miranda gibts ne Reihe vordefiniertet "Services", die als Strings in der
    Datenbank registriert sind. Man kann einen Service mit CallService aufrufen. Dabei übergibt man den String, der den Service identifiziert und 2 Parameter.
    Der untenstehende Service AddPage fügt ein property sheet in das Optionsmenü von Miranda ein. Im Prinzip ne feine Sache, man muss nur das untenstehende struct füllen, die Seite verhält sich dann ganz normal wie ein property sheet.
    Kurze Erläuterung der (wichtigen) Variabeln:
    cbSize = Größe der Struktur
    pszTitle = Titel der Seite im Auswahlmenü
    pfnDlgProc = Das DialogProc
    pszTemplate = Pointer auf eine Resource, ganz wie bei normalen ps
    hInstance = Instanz des ps, wird von DllMain geliefert
    flags = Flags ebenfalls wie beim ps

    /* Opt/AddPage
    Must only be called during an opt/initialise hook
    Adds a page to the options dialog
    wParam=addInfo
    lParam=(LPARAM)(OPTIONSDIALOGPAGE*)odp
    addInfo must have come straight from the wParam of opt/initialise
    Pages in the options dialog operate just like pages in property sheets. See the
    Microsoft documentation for details on how they operate.
    Strings in the structure can be released as soon as the service returns, but
    icons must be kept around. This is not a problem if you're loading them from a
    resource.
    Prior to v0.1.2.1 the options dialog would resize to fit the largest page, but
    since then it is fixed in size. The largest page that fits neatly is 314x240
    DLUs.
    */
    #define OPTIONSDIALOGPAGE_V0100_SIZE   0x18
    #define OPTIONSDIALOGPAGE_V0120_SIZE   0x28
    typedef struct {
    	int cbSize;
    	int position;        //a position number, lower numbers are topmost
    	char *pszTitle;
    	DLGPROC pfnDlgProc;
    	char *pszTemplate;
    	HINSTANCE hInstance;
    	HICON hIcon;		 //v0.1.0.1+
    	char *pszGroup;		 //v0.1.0.1+
    	int groupPosition;	 //v0.1.0.1+
    	HICON hGroupIcon;	 //v0.1.0.1+
    	DWORD flags;         //v0.1.2.1+
    	int nIDBottomSimpleControl;  //v0.1.2.1+  if in simple mode the dlg will be cut off after this control, 0 to disable
    	int nIDRightSimpleControl;  //v0.1.2.1+  if in simple mode the dlg will be cut off after this control, 0 to disable
    	UINT *expertOnlyControls;
    	int nExpertOnlyControls;    //v0.1.2.1+  these controls will be hidden in simple mode. Array must remain valid for duration of dlg.
    } OPTIONSDIALOGPAGE;
    #define ODPF_SIMPLEONLY   1	  //page is only shown when in simple mode
    #define ODPF_EXPERTONLY   2	  //         "                 expert mode
    #define ODPF_BOLDGROUPS   4   //give group box titles a bold font
    
    #define PSN_EXPERTCHANGED 2    //sent to pages via WM_NOTIFY when the expert checkbox is clicked. lParam=new state
    #define PSM_ISEXPERT      (WM_USER+101)   //returns true/false
    #define PSM_GETBOLDFONT   (WM_USER+102)   //returns HFONT used for group box titles
    #define MS_OPT_ADDPAGE      "Opt/AddPage"
    

    Muss dazu sagen, dass das wunderbar funktioniert hat, bis ich den Quellcode mit g++ compiliert hab, und dafür alle Funktionen mit exter "C" deklarieren musste.



  • N00Bie schrieb:

    Muss dazu sagen, dass das wunderbar funktioniert hat, bis ich den Quellcode mit g++ compiliert hab, und dafür alle Funktionen mit exter "C" deklarieren musste.

    ich muss ehrlich sagen ich verstehe nicht warum du mit aller gewalt aus einer c dll eine c++ machen möchtest wenn das programm das diese dann verwendet vermutlich auch in c geschrieben ist. 😕 ich sehe darin keinen vorteil nur riesige nachteile.

    ich vermute das diese struktur in einem exteren header ist, diesen musst du dann auch umklammern

    extern "C"
    {
        #include "derheader.h"
    }
    


  • miller_m schrieb:

    ich muss ehrlich sagen ich verstehe nicht warum du mit aller gewalt aus einer c dll eine c++ machen möchtest wenn das programm das diese dann verwendet vermutlich auch in c geschrieben ist. 😕 ich sehe darin keinen vorteil nur riesige nachteile.

    Weil ich dann alle Header neu Coden müsste. Im Prinzip will ich ja keine C++ dll, sondern nur eine Möglichkeit meine C++ Header mit der C-Dll zu verwenden.

    Die Header hab ich mit im extern "C" {} drin.



  • N00Bie schrieb:

    Weil ich dann alle Header neu Coden müsste. Im Prinzip will ich ja keine C++ dll, sondern nur eine Möglichkeit meine C++ Header mit der C-Dll zu verwenden.

    was verstehst du unter c++ und c header? mach mal ein beispiel



  • c-header:

    #ifndef _HEADER_H
    #define _HEADER_H
    
    void Funktion (char * buffer);
    
    #endif
    

    einer meiner cpp-header:

    #ifndef _TRC4_H_
    #define _TRC4_H_
    
    /*--------------------------------------------------------------------------*/
    /*      Includes                                                            */
    /*--------------------------------------------------------------------------*/
    
    #include "TEngine.h"
    
    /*--------------------------------------------------------------------------*/
    /*      Klasse                                                              */
    /*--------------------------------------------------------------------------*/
    
    class TRC4 : public TEngine
    {
    private:
    	long Init();
    	void swap( BYTE & x, BYTE & y );
    
    	BYTE SBox[SBOX_LENGTH];
    	BYTE K[SBOX_LENGTH];
    public:
    	virtual ~TRC4();
    
    	TRC4();
    
    	virtual long Encrypt( char * buffer, long length );
    
    	virtual long Decrypt( char * buffer, long length );
    
    };
    
    #endif
    


  • also verwendest du doch cpp in deiner dll. 😕

    nochmal langsam.
    1. du hattest eine funktionierende c dll
    2. diese wird von einem c programm verwendet
    3. du möchtest jetzt irgendwelche klassen der dll hinzufügen
    4. diese dll sollte allerdings immernoch von dem c programm dynamisch geladen werden
    5. und wer braucht die klassen? vermutlich du in deiner dll

    ps:
    include guards dürfen, laut dem standard, nicht mit einem unterline anfangen.



  • jep



  • soll ich mal das ganze projekt posten bzw. n link geben?



  • besser nen link





  • hatte gestern keine zeit mehr, sorry. habe es mir mal gerade angeschaut und stelle fest das wenn deine dll dynamisch geladen werden soll eigentlich fast nichts im header stehen würde bzw wenn du es auf die spitze treiben möchtest dann bräuchtest du gar keinen.

    // dll.h
    #ifndef DLL_H_
    #define DLL_H_
    
    #ifdef __cplusplus
    extern "C"
    {
    #endif
        __declspec(dllexport) PLUGININFO* MirandaPluginInfo(DWORD mirandaVersion);
        int __declspec(dllexport) Load(PLUGINLINK *link);
        int __declspec(dllexport) Unload(void);
    #ifdef __cplusplus
    }
    #endif
    
    #endif
    

    ps:
    wenn du eine datei als cpp kompilierst dann benenne sie auch so *.cpp nicht dllmain.c



  • Stimmt, eigentlich bräuchte man das nicht. Aber damit ich nicht alle Funktionen in einer Datei habe, hab ich diese nach "Themen" in andere *.cpp Dateien eingeordnet. Damit die Funktionen aber immer noch aufeinander zugreifen können, wie z.B. Load () auf HookProc(), brauche ich den Header. Er dient nicht nur als Interface für das Programm, das die dll lädt, sondern auch für die Funktionen in der Dll selbst. Hab auch mal alle Funktionen in eine mein gepackt und deinen Header verwendet, aber meine Resource wird immer noch nicht geladen.



  • N00Bie schrieb:

    Damit die Funktionen aber immer noch aufeinander zugreifen können, wie z.B. Load () auf HookProc(), brauche ich den Header.

    nein jede quelldatei sollte einen header haben und nicht einen zusammen
    gewürfelten header

    // menu.h
    // ...
    int HookProc(WPARAM wParam,LPARAM lParam);
    BOOL CALLBACK DialogProc(HWND, UINT, WPARAM, LPARAM);
    void RefreshList (HWND list);
    
    // menu.c
    // bleibt unverändert
    
    // dllmain.cpp
    #include "menu.h"
    

    N00Bie schrieb:

    Er dient nicht nur als Interface für das Programm, das die dll lädt, sondern auch für die Funktionen in der Dll selbst.

    interface? ich dachte dynamisch -> somit musst du doch nur diese drei exportieren und darauf achten das sie funktionsnamen stimmen.
    kannst ja den walker als hilfe nehmen http://dependencywalker.com/



  • miller_m schrieb:

    nein jede quelldatei sollte einen header haben und nicht einen zusammen
    gewürfelten header

    // menu.h
    // ...
    int HookProc(WPARAM wParam,LPARAM lParam);
    BOOL CALLBACK DialogProc(HWND, UINT, WPARAM, LPARAM);
    void RefreshList (HWND list);
    
    // menu.c
    // bleibt unverändert
    
    // dllmain.cpp
    #include "menu.h"
    

    Danke, das hilft in Hinsicht auf die Struktur schon ziemlich viel 👍



  • Aber leider hilft es nicht gegen mein Problem mit dem property sheet.
    Ich hab auch schon versucht es mit VC++ zu compilieren, aber das hat zum selben Fehler geführt.


Anmelden zum Antworten