-         

Ergebnis 1 bis 6 von 6

Thema: Dll Konzept

  1. #1
    Erfahrener Benutzer Fleißiges Mitglied
    Registriert seit
    23.05.2004
    Beiträge
    119

    Dll Konzept

    Anzeige

    Hallo,

    ich stecke Grade in einen konzeptionellen Problem.

    Ich benutze die RS232 Schnittstelle um mit meiner Hardware zu Kommunizieren. Da das Auslesen der Daten manchmal eine etwas kompliziertere Prozedur ist, wollte ich mir eine Art Lib in Form einer Dll schreiben, in der ich dann alle Funktionen ablege. Dll daher damit ich es auch in anderen Sprachen nutzen kann. Einer Art Treiber.

    Normalerweise würde ich mir eine Klasse schreiben, in dessen Konstruktor ich alle nötigen Einstellungen der RS232 übergebe und in Attribute festhalte. (Baudrate, Datenbits, Stopbits, Startbits...)
    Außerdem würde ich eine Methode schreiben, die den Port öffnet, so dass alle weiteren Methoden nicht mehr genötigt sind den Port am Anfang zu öffnen und am ende wieder zu schließen.

    Da ich aber in einer normalen Dll keine Objekt Orientierte Programmierung setzen darf, wie kann ich das lösen?
    Ich will nicht jeder Methode alle Parameter der Schnittstelle übergeben. Ich habe schon dran gedacht die geöffnete Schnittstelle an die jeweilige Methode mit zu übergeben (sofern das bei einer Dll überhaupt möglich ist), aber das erscheint mir auch Unpraktisch.

    jemand eine Idee?
    ist es überhaupt sinnvoll die Schnittstelle offen zu lassen, oder sollte man sie lieber schließen, und erneut öffnen?

  2. #2
    Super-Moderator Robotik Visionär Avatar von PicNick
    Registriert seit
    23.11.2004
    Ort
    Wien
    Beiträge
    6.836
    Zitat Zitat von FJK Beitrag anzeigen
    Da ich aber in einer normalen Dll keine Objekt Orientierte Programmierung setzen darf, ...
    Versteh' ich nicht ganz.
    Ich mach das so: In der DLL gibt es eine "INIT" Function (gleich mit den oa Parametern), die eine "COMPORT" Klasse erzeugt.
    die adresse dieser Klasse gibt er als neutrales "Handle"-Integer zurück, (dadurch braucht das aufrufende Programm die klasse nicht zu kennen.)
    Bei jedem Function-Call bekommt die DLL als ersten Parameter (ist übersichtlicher) diese Handle und kann dann um eine Ecke herum die div. Methoden aufrufen
    z.B.
    Code:
    // DLL
    int ComPortInit( argumente......)  
    {
    ComClass* pClass = new blabla
         pClass->methode(xyz);
      return (int)pClass
    }
     
    // Methode 
    int  Whatever( int  Handle,  args....)
    {
    int            result;
    ComClass* pClass = (ComClass*)Handle;
            result = pClass->Methode(args);
            return(result):
    }
    // Aufruf   
     
    int    MyHandle = ComPortInit(...)
     
          int result =  Whatever(MyHandle, args....)
    Ach ja, da gehört noch das DLL-Brimborium dazu, damit man die DLL auch mit anderen Sprachen als C verwenden kann
    Geändert von PicNick (16.03.2011 um 11:14 Uhr)

  3. #3
    Erfahrener Benutzer Fleißiges Mitglied
    Registriert seit
    23.05.2004
    Beiträge
    119
    Hallo PicNick,
    danke für die Antwort.

    Ok, das ist ja ähnlich meiner gedanken Führung, mit der Übergabe.
    Ich hatte mal gelernt das in einer normalen Dll keine Klassen verwendet werden dürfen. Ein Dll mit Klassen wäre dann eine Active-Dll, oder nicht?

    zu deiner Lösung,
    gibt es eine Möglichkeit den Handler als globale Variable in der Dll zu deklarieren, so das er nicht immer mit Übergeben werden muss? vermutlich nicht sonst würdest du es vermutlich nutzen, aber ich frage trotzdem einfach mal
    Dann muss ich aber auch sichergehen das die Instanz wieder am ende Zerstört wird, oder? Gibt es hier eine "automatische" Möglichkeit, oder muss ich den User bitten die ComPortDestroy() aufzurufen wenn er fertig ist?

    danke

  4. #4
    Super-Moderator Robotik Visionär Avatar von PicNick
    Registriert seit
    23.11.2004
    Ort
    Wien
    Beiträge
    6.836
    Naja, nur der Caller kann wissen, wann er das Port nicht mehr braucht.
    Theoretisch kann die DLL aber nach einem "inactivity-timeout" das handle selbst vernichten.
    Aber man kann schon verlangen, dass ein Programm vor dem "exit()" noch seine ressourcen wegräumt.


    Ahja: Bei der Entwicklung mach ich noch keine DLL, sondern schreib "normale" classen und funktionen im Hauptprogramm, hab aber die "aufruf-Ecke" schon dabei.
    Erst wenn alles funzt, tu ich das zeugs raus und mach wirklich eine DLL.
    mfg robert
    Wer glaubt zu wissen, muß wissen, er glaubt.

  5. #5
    Erfahrener Benutzer Fleißiges Mitglied
    Registriert seit
    23.05.2004
    Beiträge
    119
    Zitat Zitat von PicNick Beitrag anzeigen
    Naja, nur der Caller kann wissen, wann er das Port nicht mehr braucht.
    Theoretisch kann die DLL aber nach einem "inactivity-timeout" das handle selbst vernichten.
    Aber man kann schon verlangen, dass ein Programm vor dem "exit()" noch seine ressourcen wegräumt.
    Naja, ich dachte da eher an einen Programm-Ende-Aufruf, wie Form Close().
    Aber Timeout klingt auch intressant, mal googlen, oder hast du da ein Bsp für mich?
    man sollte ja eh in jeder Methode fragen ob der Port offen ist, wenn er dann geschlossen ist, notfalls neu öffnen.
    Aber dann hat man immer noch das Problem das die Schnittstelle belegt ist, wenn das Programm beendet wurden ist.


    Zitat Zitat von PicNick Beitrag anzeigen
    Ahja: Bei der Entwicklung mach ich noch keine DLL, sondern schreib "normale" classen und funktionen im Hauptprogramm, hab aber die "aufruf-Ecke" schon dabei.
    Erst wenn alles funzt, tu ich das zeugs raus und mach wirklich eine DLL.
    jo das ist klar.
    Erster anstatz war mit c#, aber leider ist es ja eine "andere" dll.

  6. #6
    Super-Moderator Robotik Visionär Avatar von PicNick
    Registriert seit
    23.11.2004
    Ort
    Wien
    Beiträge
    6.836
    Mit den entsprechenden Definitionen wird das eine DLL, die mit allen (miroslav)-Sprachen aufrufbar ist. (also ohne der LIB-Dependency)
    Meine konkrete (VC++) DLL haben wir z.B. mit VBasic-Express verwendet.

    Wo ich nix weiss, wie das mit DLL's in c-sharp ist.
    mfg robert
    Wer glaubt zu wissen, muß wissen, er glaubt.

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •