Designproblem bei langer Operation

dEUs

der user = der programmierer, der mit meiner DLL arbeitet

D*niel *chumann

Warum machst du die Operation nicht auch in dem Thread (am Ende)?

dEUs

Die Operation danach gehört nicht in diese Klasse, deswegen müsste ich nen thread machen, der das ungethreadede dekodieren und die operation enthält. das bedeutet aber, dass ich den thread jedes mal um diese dekodier-funktion rumbauen muss, wenn ich sie benutz ...
Hm ... Aber vielleicht könnte ich in die Dekodierfunktion nen thread einbauen, der bei beendigung ein flag auf true setzt. und erst wenn dieses flag auf true ist, wird im thread, der aussenrum gebaut ist die operation aufgerufen ... was haltet ihr davon?

frenki

Also, ich würde mir um den Thread keinen Kopf machen: Wenn der User einen Thread will, soll er selbst einen starten und deine Funktion von diesem aufrufen, ist ja nun wirklich Trivial.

Wenn du den Thread selbst machen willst: Wie wärs mit Callback-Funktionen? Ist IMHO sowieo immer bei längeren Operationen Sinnvoll, weil heutzutage eine Fortschrittsanzeige Standard sein sollte, und auch dafür Informationen zurückgegeben werden müssen, um diese darzustellen.

dEUs

Hm, ich glaub, ihr versteht nicht ganz, was ich will ...
Ich schreibe eine DLL. Dem Programmierer, der sie benutzt, liegt nur die DLL, eine Headerdatei mit den exportierten Funktionen und ein paar Definitionen und eine lib, zum einbinden der DLL ins Programm, vor. Wenn er jetzt meine Funktion MP3_Dec_And_Operation() aufruft soll eben auch das dekodieren UND die Operation ausgeführt werden. Die Callback für die Statusanzeige habe ich schon von anfang an drinne ...

verstehs noch nicht:

bla MP3_Dec_and_Operation () {
  Dec();
  Operation();
}

voila, zwei funktionen aufgerufen

dEUs

witzbold.
Genau so hab ichs ja im Moment! Dec ist die Funktion, die LANG dauert.

CMatt

ich verstehs nicht....

- Der user ruft ein funktion in der DLL auf
- Die funktion startet nen thread der ne datei deociert
- Decodierung ist fertig
- ?????????

Unix-Tom

Ich kapiere es auch nicht.
In DLLs sind oft funktionen die lange dauern.
Was macht der WIN-Coder. Er startet eine Thread welche die DLL lädt und die exportierte Funktion ausführt. Da ich davon ausgehe, da du eine DynLIB machst kannst du IMHO sowieso keine Klassen exportieren.
Wenn der Programierer dies nicht tut dann ist er selbst schuld und kann seine GUI nicht mehr bedienen.
Einen Thread würde ich in einer dll nicht starten da man dann nicht mehr so schön aufräumen kann wenn der Programmierer ohne dieses Thread zu beenden das Programm schließt.
Ich wüsste jetzt eigentlich auch keine Funktionen in einer DLL der MFC welche eine Thread startet. Insbesonders da das Programm dann auch mit der z.B. Multithreadversion der MFC gelinkt werden müsste.

dEUs

hm. Dass muss ich mir mal durchdenken ...