UserMessages

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

  • Hallo,

    habe hier ein kleines Problem.

    Ziel ist es, viele Bilder in einem Prozess vorzuladen (Handle), um das Hauptprogramm zu entlasten

    bzw. daß es flüssiger läuft. Mit einer Message (SendMessage) soll der Prozess das Handle zum

    Hauptprogramm senden und wenn der Prozess fertig mit Laden ist, auch eine Message senden.


    Leider bekomme ich die Handles nicht ins Hauptprogramm, bzw. bewirkt die UserMessage nichts.

    Die Message, wenn der Prozess fertig ist, funktioniert dagegen.


    Hat jemand eine Idee, woran das hängen könnte ?


    Im Prozess selber kann ich mit StartPaint...EndPaint auf das übergebene Fensterhandle zeichnen.

    Insofern sind die Bilder mit den richtigen Handles ja da.

    Ich möchte die Bilder aber gerne im Hauptprogamm anzeigen.

  • Die Usermessage 1000 will er wohl nicht. Wenn ich 1001 nehme, dann komme ich zu

    "Dieses Element gibt es nicht" in Zeile 16. Das muß wohl richtigerweise DrawPic Diashow%[&ULPARAM], 100, 20; 0 heißen. Aber dort erhalte ich dann "Falscher Parametertyp: 100 in Zeile 16" :?: Der Grund ist mir jetzt nicht klar,


    Gruß Volkmar

  • Hallo Volkmar,

    Die Werte der Usermessages hatte ich auch schon verändert und keinen Erfolg gehabt.

    Da Roland in seiner Hilfe auch von der UserMessage 1000 , 1001 Gebrauch macht, bin ich

    mal davon ausgegangen, daß man mit denen nicht ins Gehege mit anderen Messages kommt.

    Irgendwie scheinen die Handles im Hauptprogramm nicht mehr gültig zu sein. Die Meldung

    "Falscher Parametertyp: 100 kommt auch bei falschen oder mit 0 belegten Handles.

    Zuerst bekomme ich aber die Meldung, daß es dieses Element (Diashow%[&ULPARAM] nicht

    gibt, obwohl ich mit SetSize das Array groß genug erweitere.


    Aber bei UserMessages 2000, 3000 :

    If %UMessage = 2000

    Messagebox(Str$(&UWPARAM), Str$(&ULPARAM), 0)

    und das andere auskommentiert, zeigt mir, daß beide Werte ankommen. Bei 1000 geht es nicht.

    Die erste 0 bei &ULPARAM zeigt die Nummer (Index) des in das Array einzutragende Handle

    &UWPARAM. Und beim Index 0 fangen wir ja auch beim Array an.

    Wenn ich direkt mit

    DrawPic &UWPARAM, 100, 20; 0

    anzeigen will, kommt auch der falsche Parametertyp.

    Da muß der Fehler doch woanders stecken. Auch eine übergebene Variable an pExec() , die das Handle

    des Bildes aufnehmen soll, funktioniert nicht. Mit Handles von Fenstern etc. geht es ja auch. Scheint

    so zu sein, daß es sich verhält wie Bereiche und Arrays, die man auch nicht übergeben kann / sollte,

    Auszug aus der Hilfe :

    Zitat

    PExec - PExecWait

    Bei Arrays und Bereichen würden Referenzen auf Speicheradressen übergeben, die im neuen Prozess des Moduls keine Gültigkeit mehr hätten. Ein Programmabbruch wäre die Folge.

    Wird wohl umgekehrt auch so sein.



    Vielleicht kann Roland das mal anschauen.

    Erstens das mit der UserMessage 1000 und zweitens das mit den (falschen) Werten

    beim Array und DrawPic.

  • Ich nehme da an, daß das Bildhandle im Hauptprogramm nicht mehr

    gültig ist.

    Bloß die Sache mit dem Array müßte doch wenigstens funktionieren.

    Ich probiere mal Schritt für Schritt weiter. z.B. mit MAT mal das Array

    vorbelegen usw.


    Da muß mal jemand ran, der klüger ist 8)

    Das wird wohl nur Roland sein.

    Wir können nur durch Probieren und Hilfe lesen das eine oder andere herausfinden.

  • Jonathan lieferte - denke ich - einen Workaround:


    Orig.-Text:

    Wenn man in einem Programm viele Bilder zeichnet und diese nicht immer wieder von der Festplatte geladen werden sollten, man aber auch keine Lust hat, jedes Bild am Anfang ausdrücklich zu laden, kann man diese Routinen nehmen:

    Die Procs ersetzen Create("hPic"), Create("hSizedPic"), DrawPic und DrawSizedPic in ihrer Form zum Laden von Bildern von der Festplatte. Wird ein Bild zum ersten Mal geladen, laden diese Routinen das Bild in den RAM und behalten dort eine Kopie davon. Wird das Bild erneut geladen, wird die Kopie im RAM benutzt und es nicht nochmal von der Festplatte geladen. Am Ende sollte man DeleteImageBuffer nicht vergessen, damit die ganzen Handles der Kopien wieder freigegeben werden.

    Gruß

    Jonathan

    HP255G7:Win10pro2.004,4*AMD Ryzen3200U@2.60GHz,6+2GB-RadeonVega/237GBSSD:intlDVDRW,3xUSB3 ext4TB-HDX,XProfanX3+Xasm/Xpse

  • Ob das mit sehr vielen Bildern viel schneller ist ?

    Immerhin müssen die Procs ja auch abgearbeitet werden

    und in dieser Zeit steht ja das Hauptprogramm.

    Es ging ja um flüssiges Arbeiten im Hauptprogramm und

    deshalb sollte das Laden im Hintergrund erfolgen.

    Da wäre halt das Multiprozessing das Mittel der Wahl

    gewesen.

    Vielleicht kann man auch mit einem Timer was machen.

    Der muß halt so kurz angepaßt werden, damit er das

    Arbeiten im Programm nicht stört. Die Timer-Proc müßte

    sich ja nur merken, wo sie in der Listboxliste beim Verlassen

    steht, um beim nächsten Timerüberlauf dort weiter zu machen.

    Eben halt bis zum Ende der Listboxliste.

    Die Zeit müßte man dann im Hauptprogramm ausbaldowern.

  • Verstehe ... manuelles polling, sozusagen... Aber das droht dann sehr PC- und Auslastungs-spezifisch zu werden.


    Wie wär´s mit XPSE-UserThreads? Seit iF den Workaround zu thread.is vorgestellt hat, klappt das recht gut! Und fände schon im Datenraum des Hauptprogramms statt, habe ich gelesen (Oder gilt das nur für Kernel-Threads?)

    HP255G7:Win10pro2.004,4*AMD Ryzen3200U@2.60GHz,6+2GB-RadeonVega/237GBSSD:intlDVDRW,3xUSB3 ext4TB-HDX,XProfanX3+Xasm/Xpse

    Einmal editiert, zuletzt von p. specht ()

  • Ich glaube immer noch, das dies der falsche Weg ist.

    Im Internet stehen viele Lösungen, wie man Bilder schnell mit OpenGL anzeigt.

    Handles werden immer innerhalb eines Prozesses bleiben. Ruft man einen 2. Prozess auf kommen die Zugriffsgeister und der Spuk beginnt.


    Über "opengl viele bilder schnell laden" habe ich auf Anhieb Aussagen gefunden, die ein schnelles Laden als 'ganz normal' beschreiben.

    Hier wird aber dann ganz mit OpenGL gearbeitet.


    Mit XProfan müsste man dann tiefer in die OpenGL-Speicherstrukturen einsteigen.


    Vielleicht hilft auch: Eine Einführung in OpenGL - Universität Augsburg Informatik

    Dort wird auch auf schnell zu bearbeitende Texturen eingegangen.