Zitat von Frabbing;697306also mach dir keinen Kopf!
Das sehe ich auch so.
Zitat von Frabbing;697306also mach dir keinen Kopf!
Das sehe ich auch so.
Schau dir die Prozedure einfach an, sie wird in jedem von XPIA erstellten Quellcode generiert.
Es handlet sich um Code, um die Funktionen der internen Dll per Memorymodule zu starten, aus dem Speicher heraus. In früheren Versionen musste die Dll noch im Temp ausgelagert werden. Das ist dank der MM nicht nötig.
Normalerweise wird eine Funktion dort aufgerufen, wo der Asm-Code steht. Durch den externen Aufruf kann sie aber mehrmals aufgerufen werden, bzw. der Asm-Code nur dort ausgeführt werden, wo der User es wünscht. Das ermöglicht z.B. eine Sammelprozedure mit allen Asm-Blöcken.
Edit:
Dieser Teil ist immer gleich: Call(xpia_getprocaddressm(xpia_hmodule&,
Davor befindet sich eventuell der Returnwert, dahinter die zu übergebenen Parameter.
Zitat von Frabbing;697339Schau dir die Prozedure einfach an, sie wird in jedem von XPIA erstellten Quellcode generiert.
Es handlet sich um Code, um die Funktionen der internen Dll per Memorymodule zu starten, aus dem Speicher heraus. In früheren Versionen musste die Dll noch im Temp ausgelagert werden. Das ist dank der MM nicht nötig
Ah ja, sehe es schon:
[Blockierte Grafik: http://www.postimage.org/aV6A6LJ.jpg]
Zum Profan2Cpp-Subthema: Dann bin ja erstmal beruhigt Danke für die Erläuterungen, das mit dem Timer-Callback schaue ich mir bei Gelegenheit mal etwas genauer an.
Zitat von AHT;697303Wo es in Profan dabei Probleme geben kann, ist bei allen Create und Control Klamotten.
Kleine Korrektur: Bei SendMessage scheinbar unter Umständen ebenfalls, hängt aber von der Message ab. Werde das für mich noch etwas austesten :-).
Edit: War ein Irrtum, lag an mir.
Profan2CPP ist scheinbar genausowenig multithreadingfähig wie XProfan
Es führen auch mit Xprofan wege dort hin.
Einfach ein bisschen umdenken und umlenken.
Zitat von profanfan;697748Profan2CPP ist scheinbar genausowenig multithreadingfähig wie XProfan
Es führen auch mit Xprofan wege dort hin.
Einfach ein bisschen umdenken und umlenken.
So?
ZitatEs führen auch mit Xprofan wege dort hin.
Einfach ein bisschen umdenken und umlenken.
Ich vermute, du meinst die Thread.pcu von David. Die ist in der Tat sehr gelungen, bietet aber keine echten Threads. Die genaue Arbeitsweise ist mir allerdings nicht bekannt.
Zitat von Frabbing;697833Ich vermute, du meinst die Thread.pcu von David. Die ist in der Tat sehr gelungen, bietet aber keine echten Threads. Die genaue Arbeitsweise ist mir allerdings nicht bekannt.
Die ist sehr wohl bekannt.
David benutzt dort Timer - funktioniert also nicht wie es sollte.
Ich glaube, die nutzt jetzt die Subclassing-Routinen. Aber wie gesagt, kein Thread-Ersatz.
Zitat von Frabbing;697840Ich glaube, die nutzt jetzt die Subclassing-Routinen.
Kann gut sein, dass sich da was getan hat - hab mich darum schon eine ganze Zeit nicht mehr gekümmert.
Zitat von Frabbing;697840
Aber wie gesagt, kein Thread-Ersatz.
Na ja - heißt ja "programmieren für Anwender" - als Anwender braucht man so was wie ständig laufende Programme", "Dienste" und "gleichzeitig laufende Routinen" ja nicht :-). Einen Anwender kratzt es überhaupt nicht, wenn beim Aufrufen des Menüs keine Zeitmessungen mehr vorgenommen werden können. Desweiteren hat ein Anwender ja immer viel Zeit und er kümmert sich überhaupt nicht darum, ob man nichts anderes mit einem Profanprogramm tun kann, während eine aufwendige Berechnung läuft. Das ein Anwender mit Vista arbeitet und deswegen gerne einen Service hätte (weil ohne da fast gar nichts mehr läuft), ist sowieso sehr weit hergeholt.
Also warum über "Threads in Profan" nachdenken? Jeder Anwender kann doch ASM!
Ich sehe das nicht so negativ und finde es auch nicht in Ordnung, das so negativ rüber zu bringen.
XProfan ist sicher nicht "perfekt", aber das sind andere Programmsprachen auch nicht. Schwachpunkte haben alle. Der grosse Pluspunkt ist aber die leicht erlernbare Syntax, loslegen können ohne unzählige Libraries einzubauen zu müssen und mit wenig Code viel erreichen zu können. Da kommt keine andere Sprache mit.
Die Nachteile lassen sich zudem nahezu alle kompensieren, entweder durch P2Cpp oder Inline-Assembler. Wer mehr will, muss eben bereit sein etwas extra zu bezahlen (immer noch kein Vergleich zu den Preisen anderer Programmsprachen!) oder in eine gänzlich andere (Zweit)Sprache reinzuschnuppern. Ich persönlich finde die Kombination von XProfan - XPIA perfekt und werde sie so bald nicht aufgeben...
Aber bitte zurück zum Thread-Thema...
Zitat von Frabbing;697862
Aber bitte zurück zum Thread-Thema...
Gerne - einzige vernünftige Methode ist über XPIA.
Hehe, du bist unverbesserlich.
Zitat von AHT;697303Ich verwende einen Timercallback, um die Fenstergröße anzupassen, während gleichzeitig mehrere tausend Handles ausgelesen werden.
Du weißt, dass dies eine nicht ganz ungefährliche Geschichte ist? Für SubClassing ist ProcAddr() eigentlich nicht gedacht, auch wenn es natürlich bei entsprechend "vorsichtiger" Programmierung gut gehen kann, was bei Dir ja wohl der Fall ist. Hier würde ich das SubClassing aus XProfan 11 empfehlen.
ZitatWarum? Da man Profans interne Messageverarbeitung abschalten kann, hat Roland in seiner "Virtual-Machine" eine Delphi-Messageverarbeitung hinter das CreateWindowEx gesetzt, dass das Fenster erzeugt (das würde sonst gar nicht angezeigt).
Also das ist ziemlich weit hergeholt, zumal es keine Delphi-Messageverabeitung gibt, sondern ich dieXProfan-Messageverarbeitung in Delphi geschrieben habe. Diese wird durch Set("FastMode", 1) weitgehend abgeschaltet. Das erweiterte Messagehandling (Siehe Hilfe) wird abgeschaltet. Befehle und Funktionen, die Messages erzeugen, sind aber trotzdem noch möglich.
ZitatIst aber nur graue Theorie
In der Tat!
Gruß
Roland
Zitat von RGH;698236Du weißt, dass dies eine nicht ganz ungefährliche Geschichte ist?
Ja, dass weiß ich, deswegen "Trickserei".
Zitat von RGH;698236
Für SubClassing ist ProcAddr() eigentlich nicht gedacht, auch wenn es natürlich bei entsprechend "vorsichtiger" Programmierung gut gehen kann, was bei Dir ja wohl der Fall ist. Hier würde ich das SubClassing aus XProfan 11 empfehlen.
Ich regele das nicht über Subclassing, ich brauche die interne Messageverarbeitung und hab XProfan9. Subclassing funktioniert, soweit ich weiß, auch in XProfan11 nicht zufriedenstellend - oder kann man in XProfan11 alle Fenster subclassen? Für Subclassing habe ich bislang immer eigene DLLs benutzt.
Zitat von RGH;698236
Also das ist ziemlich weit hergeholt, zumal es keine Delphi-Messageverabeitung gibt, sondern ich dieXProfan-Messageverarbeitung in Delphi geschrieben habe. Diese wird durch Set("FastMode", 1) weitgehend abgeschaltet. Das erweiterte Messagehandling (Siehe Hilfe) wird abgeschaltet. Befehle und Funktionen, die Messages erzeugen, sind aber trotzdem noch möglich.
Wir reden aneinander vorbei und du beißt dich an unwichtigen Sachen fest. Wenn du etwas erklären willst, erkläre bitte, warum der Returnwert einer TimerProc auf dem Ergebnis von Create landet.
Zitat von AHT;698376Subclassing funktioniert, soweit ich weiß, auch in XProfan11 nicht zufriedenstellend
Also in meinen Programmen funktioniert es exakt so wie es soll, z.B. im aktuellen XProfed.
ZitatWenn du etwas erklären willst, erkläre bitte, warum der Returnwert einer TimerProc auf dem Ergebnis von Create landet.
Wenn Du hier im Forum (aber bitte in einem eigenen Thread, um nicht gänzlich OT zu werden ) ein kurzes (!) Beispielprogramm (natürlich reines XProfan ohne externe DLLs.*) postest, schaue ich gerne mal nach, was da schief läuft.
Gruß
Roland
* Das ist bei Bugmeldungen wichtig, damit ich sicher bin, dass das Problem am XProfan-Programm oder XProfan selbst liegt und nicht an einer DLL, auf die ich keinen Zugriff habe.
[offtopic]
Zitat* Das ist bei Bugmeldungen wichtig, damit ich sicher bin, dass das Problem am XProfan-Programm oder XProfan selbst liegt und nicht an einer DLL, auf die ich keinen Zugriff habe.
Wobei es aber Wechselwirkungen der beiden Sachen geben kann, die (zur Not) durchaus auch auf XProfan-Seite behoben werden könnten. Ein Beispiel wäre z.B. das beidseitige Reservieren von GWL_USERDATA oder GWL_ID usw.
[/offtopic]
Zitat von Frabbing;698494Wobei es aber Wechselwirkungen der beiden Sachen geben kann, die (zur Not) durchaus auch auf XProfan-Seite behoben werden könnten. Ein Beispiel wäre z.B. das beidseitige Reservieren von GWL_USERDATA oder GWL_ID usw.
Ja, natürlich. Keine Regel ohne Ausnahmen!
Gruß
Roland
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!