SetGadgetText und SetGadgetState sehr CPU lastig?

[Micha122]

@Kevin
Genau DAS habe ich gesucht.
Der Code ist einfach, funktioniert und ich habe eine Eventschleife.

Danke!!

[Micha122]

@CodeCommander:

Aber nicht mit WindowEvent() sondern mit WaitWindowEvent(50), wobei 50 nur exemplarisch genommen wurde.
WindowEvent() ist hier eher nicht geeignet und bei Deinem Verständnis für Fenster und EventLoop wird das
ansonsten weiterhin in einem CPU-Braten ausarten

Hast Recht, mit Fenstern und Gadgets habe ich mich bislang nur mäßig befasst.
Die Konsole hatte bisher immer zum üben und ausprobieren gereicht.
Das mit WaitWindowEvent(50) habe ich verstanden, Danke!

Gruß, Michael

[ts-soft]

Tja, jetzt kommt aber noch das Problem mit einem EventLoop in einer DLL Funktion. Das wird kaum vernünftig möglich
sein, jedenfalls nicht ohne Threads oder API. Da solltest Du Dir vielleicht was anderes einfallen lassen, ansonsten wirste
noch viele weitere Probleme haben in dieser Konstellation.

[Micha122]

@ts-soft
Warum?
Habe grade meinen Code nach dem Muster von Kevin abgeändert (aber mit WaitWindowEvent Timeout) und die dll neu kompiliert.
Funktioniert alles einwandfrei.
Dein Tipp mit dem Timeout von WaitWindowEvent hat sogar noch ein anderes Problem behoben welches es gab: Das Fenster wird nun auch bei Mausbewegungen richtig aktualisiert. Vorher mit meiner Methode geriet da alles ins stocken.

Gruß und Danke, Michael

[ts-soft]

Wenn es funktioniert ist ja gut, hoffentlich bleibt es so

Da ich mal vermute, Deine DLL soll irgendwelche Datenbank Vorgänge durchführen, würde ich die DLL auch nur
dies tun lassen und keine GUI Elemente einbauen. Für den Progress läßt Du dir vom DLL-Nutzer eine Callback-
Adresse geben, welche Du mit den Fortschrittswerten fütterst, die Anzeige sollte der Nutzer der DLL alleine vor-
nehmen. Auf jedem Falle würde ich dieses Vorgehen vorziehen und das ist auch weniger Fehlerträchtig.

Gruß
Thomas

[Micha122]

@ts-soft

Da ich mal vermute, Deine DLL soll irgendwelche Datenbank Vorgänge durchführen

Ja, hast Recht. Ich benutze die dll um Datanorm Artikeldaten in eine PostgreSQL- DB zu importieren.
Alle DB Operationen funktionieren auch tadellos, das Ergebnis meiner Arbeit habe ich mir immer im Konsolenfenster
anzeigen lassen. Der Debugger wurde dafür schnell zu langsam

würde ich die DLL auch nur dies tun lassen und keine GUI Elemente einbauen

War anfangs so geplant. Mangels Programmierkenntnisse hab ich´s dann doch so gemacht.

Für den Progress läßt Du dir vom DLL-Nutzer eine Callback-
Adresse geben, welche Du mit den Fortschrittswerten fütterst, die Anzeige sollte der Nutzer der DLL alleine vor-
nehmen. Auf jedem Falle würde ich dieses Vorgehen vorziehen und das ist auch weniger Fehlerträchtig.

Dann müsste die dll aber als thread oder eigener Prozess laufen, oder?
Momentan ist es bei mir so, das der dll Nutzer erst nach beenden der dll weiterarbeitet.

[ts-soft]

Dann müsste die dll aber als thread oder eigener Prozess laufen, oder?
Momentan ist es bei mir so, das der dll Nutzer erst nach beenden der dll weiterarbeitet.

Naja, der DLL Nutzer hat aber ein totes Fenster, wenn Du es so machst, das ist IMHO immer
eine schlechte Idee. Das arbeiten mit Threads ist natürlich aufwendiger und da fehlt Dir vermutlich
die Erfahrung, aber Du solltest es zumindest mal testen und wenn Du nicht weiter kommst, hier
nachfragen.
Ich würde darauf verzichten, eine DLL zu nutzen, die meine GUI tötet

Vielleicht machste erstmal 2gleisig weiter, mit der einen Version kommste dann schneller voran,
während die andere dann nach und nach erstellt wird.

[Micha122]

Hallo,
hab mir mal ein wenig Zeit gegönnt um die vielen Informationen hier mal zu verarbeiten.

@ts-soft

Vielleicht machste erstmal 2gleisig weiter, mit der einen Version kommste dann schneller voran,
während die andere dann nach und nach erstellt wird.

Ja, die Idee ist gut. Hab gestern mal einen anderen Programmaufbau mit Threads erstellt. Allerdings ohne dll´s, also die Prozeduren im Programm.
Habe mein Datanorm Import dann mal mit Kommerzieller Software (ab 400€) verglichen .
Das Ergebnis:
Geschwindigkeit: bei 500000 Datensätzen lag mein PB- Code bei ca. +-30 Sekunden
Fortschrittsfenster: Habe mit Timer eine Aktualisierung von 20/sec gewählt und sah im Vergleich sogar gut aus
"Tote" GUI: Bei fast allen musste ich warten bis die Daten importiert waren. ...Deshalb werde ich nach und nach wohl auf Threads umsteigen.

@Kiffi
Habe Deinen Code nun verstanden. Wusste vorher überhaupt nicht, das es CustomEvents gibt. Geniale Sache!!

Hab nun erstmal genug Stoff zum Basteln, deshalb Danke für die vielen Tipps!