4. Fortschrittsbalkendatenquelle aus DLL - wie geht das?

Fortschrittsbalkendatenquelle aus DLL - wie geht das?

  • P

    Hallo Forumsbesucher,

    aus meinem C- Progrämmchen, das eigentlich auf einem Controller läuft, habe ich noch 'ne win- Konsole und 'ne win- DLL gebastelt. Wenn man das Ding jedoch mit dicken Daten bewirft, verfällt es in mehrsekündige Meditation - das schaut bei der DLL seltsam aus, weil sich das Teil nicht mehr bemerkbar macht. Auf dem Controller kann ich den Stand jederzeit aus den Variablen für Bearbeitungsstufe, Gesamtelementezahl und aktuelles Element in Bearbeitung auslesen und darstellen.

    Die DLL exportiert derzeit nur zwei Funktionen, einen Aufruf, sich anhand eines ini- Files zu parametrieren und den Aufruf, eine bestimmte Datei zu bearbeiten, was halt langwierig sein kann.
    Genügt es, einfach eine weitere Funktion zu exportieren, die einen Satz Pointer annimmt und bei Aufruf die Variablen einfach reinspeichert? Ich meine natürlich, während sich die andere Funktion mit ihren Arbeitsdateien befaßt - oder ist das komplizierter?

    Tut mir leid, ich muß mich fast nie mit Betriebssystemen herumschlagen und bin daher weitgehend ahnungslos.
    Danke für's Lesen und Antworten!

    0
  • V

    Hallo pointercrash,
    es ist leider ein wenig komplizierter. Jeder Prozess ist zwar multithreadfähig, Funktionen laufen aber nicht parallel.
    Das heißt, du müsstest mindestens zwei Threads haben, einer wird natürlich sofort zu Programmbeginn erstellt, den anderen musst du explizit selber erstellen (wie es geht, steht hier).
    Der zweite Thread könnte nun die Funktionen zum Initialisieren und zur Ausführung aufrufen, der Primärthread könnte eine (noch nicht existierende) Funktion regelmäßig aufrufen und das Maximum und den momentanen Stand abfragen. Dies könnte dann bspw. in Prozent ausgedrückt immer in die selbe Zeile der Konsole geschrieben werden.

    size_t percent, max=1, curval=0;
while(curval<max)
{
        // hier max und curval holen
        // percent = (100.f*curval)/max;
	printf("\r%d %%",percent);
	Sleep(50); // Thread 50 ms lahm legen
}

    Und leider gibt es noch etwas zu beachten. Dies ist die Threadsynchronisation. Der Workerthread (2) kann max und curval setzen, während der Primärthread versucht, darauf zuzugreifen. Es ist also erforderlich, sich mit CRITICAL_SECTIONs oder mit Mutexes zu beschäftigen.
    Aber möglich ist das allemal.
    Edit: curval und max müssen natürlich initialisiert werden.

    0
  • P

    Vicious Falcon,
    danke erstmal, sowas hatte ich schon befürchtet.
    Als "dirty hack" wär's vermutl. einfacher, die bearbeitende Funktion selbst den Balken malen zu lassen, was zwar der Trennung von Funktion und GUI widerspricht, aber so einen Riesenzirkus möchte ich eher vermeiden.

    Muß wohl vorher mit den Leutchen reden, die meine DLL einsetzen wollen ...

    0
  • V

    Ja, das ist durchaus einen Gedanken wert. Auch wenn ich meistens eine Multithread-Lösung verwende, kannst du beispielweise das Handle des Controls der Funktion übergeben.
    Hier ergibt sich mir eine Verständnisfrage: Möchtest du eine Konsolenanwendung oder eine "richtige" Windows-App mit eigenem Fenster/Dialog haben?
    Ich persönlich würde jetzt am Einfachsten finden, einen Dialog zu erstellen, in diesem eine Progressabar erstellen und das Handle der Funktion an die DLL zu übergeben. Diese Funktion schickt dann regelmäßig Nachrichten vom Typ PBM_SETPOS an das Control.
    Sorry, ich hab eben völig "overpowered" gedacht.

    0
  • ?

    Kannst der DLL auch die Adresse einer Callback-Funktion von der GUI übergeben (lassen).

    Dann würde die DLL nichts GUIgemäßes mehr enthalten und alle wären glücklich.

    0
  • P

    Vicious Falcon schrieb:

    Hier ergibt sich mir eine Verständnisfrage: Möchtest du eine Konsolenanwendung oder eine "richtige" Windows-App mit eigenem Fenster/Dialog haben?

    Die Konsolenanwendung existiert aus entwicklungstechnischen Gründen, weil die Turnaroundzeiten am PC kürzer sind und ich erst gegen Ende auf das Target (Controller) crosse. Die DLL hab' ich nur draus gemacht, weil jemand das für seine medizinische CAM- Suite prima fand, ich hab' mit der GUI eigentlich nix am Hut. Jetzt haben die aber neue Hardware integriert, die statt Zehntelmillimeter auf den Mikrometer genau arbeitet, was die Simulationszeiten explodieren läßt.

    Vicious Falcon schrieb:

    Ich persönlich würde jetzt am Einfachsten finden, einen Dialog zu erstellen, in diesem eine Progressabar erstellen und das Handle der Funktion an die DLL zu übergeben.

    merker schrieb:

    Kannst der DLL auch die Adresse einer Callback-Funktion von der GUI übergeben (lassen).

    Dann würde die DLL nichts GUIgemäßes mehr enthalten und alle wären glücklich.

    Denke, die Vorschläge entsprechen einander weitgehend, Danke. Ich werde das wiederum den GUI- Bastlern empfehlen. Wenn die das so fressen, bedeutet das für alle auch den geringsten Aufwand, was mir als faulem Hund entgegenkommt. 😃

    0
Anmelden zum Antworten