XProfan - kein freier Callback

Das sieht gut aus. Würde ich auch so versuchen

Gruß Volkmar

Da gibt es auch noch andere Möglichkeiten.

Man könnte ja auch beim letzten Eintrag eines Knotens eine UserMessage

auslösen und die in der Callback abfragen und entsprechend reagieren.

Na super Danke für Deine Rückmeldung

Gruß Volkmar

Dafür sind wir bzw. das Forum auch da und ich helfe immer gerne mit.

Weil es so funktioniert, freue ich mich auch.

Solche Callbackfunktionen wären ja auch ohne API bzw. fremde Funktionen nützlich.

Ich denke da gerade an BindEvent in PB. Das gibt es dort auch für Gadgets und Menüs.

Gerade auf Hinsicht der freien UserMessages wäre es doch interessant :

BindEvent(Usermessage|Windowsmessage, ProcAddr(Callbackfunktion), [%HWnd])
UnbindEvent(-Usermessage|-Windowsmessage, ProcAddr(Callbackfunktion), [%HWnd]) 

Oder auch ein

UserMessages message, [ProcAddr(Callbackfunktion)]

könnte ich mir vorstellen. Wobei dann die Message direkt den Callback ausführt, ohne das langsame

WaitInput bzw. dessen Handling zu durchlaufen.

So sieht das in PB aus (siehe Bilder unten):

Sowas würde ich mir auch in X5 wünschen

Das geht auch ohne Usermessages:

$H Windows.ph

Declare OldWndProc&

PROC NewWndProc
  Parameters hWnd&, Message&, wParam&, lParam&
  if Message&=$8000
    TestProc
  endif
  Return ~CallWindowProc(OldWndProc&, hWnd&, Message&, wParam&, lParam&)
ENDPROC

PROC TestProc
  print "Test!"
ENDPROC

cls
OldWndProc&=~GetWindowLong(%hWnd, ~GWL_WNDPROC)
~SetWindowLong(%hWnd,~GWL_WNDPROC,@ProcAddr("NewWndProc",4))
@SendMessage(%HWnd,$8000,0,0) 'das wäre dann die Usermessage - hier wird TestProc 1x "direkt" ausgeführt
WaitKey
~SetWindowLong(%hWnd,~GWL_WNDPROC,OldWndProc&)
end

Ja, richtig.

Ich bevorzuge aber lieber die normalen UseMessages, da die ja schon seit

Version 7.0 eingebaut sind. Das ist auch für den Normalo-User besser verständlich,

also ohne die API-Aufrufe.

Naja, ich meinte ja nur, weil Du anregtest, man könne ja usermessages ohne das langsame waitinput implementieren. Da Roland mit seinen knapp 70 Jahren vermutlich keine weitere Version von XProfan mehr anbieten wird, geht das eben nur über ein Umbiegen der Fensterfunktion - aber es geht immerhin.

Um übrigens nochmal zum eigentlichen Thema des Threads zurückzukommen:

Wenn man unbedingt mehr als 5 Callback-Funktionen pro Parameteranzahl braucht, kann man (notfalls, jaja, ich weiß, immer die gleiche Leier...) fbPROCs mit JRPC3 benutzen. Die Funktion @GetFbProcAddr ermittelt die Funktionsadresse, und davon kann es unbegrenzt viele geben. Das würde im Eingangsbeispiel nicht so gut funktionieren, weil da ja PDF-Builder über die damit verbundene INC-Datei benutzt wird, d.h. es werden in der Callback-Funktion wiederum PDF-Builder-Aufrufe verwendet. Es würde zwar gehen, wäre aber kompliziert. Aber wenn man Callback-Funktionen z.B. für API-Aufrufe braucht, dann sind fbPROCs dafür ideal (superschnell etc.).

Zitat von Jens-Arne

Da Roland mit seinen knapp 70 Jahren vermutlich keine weitere Version von XProfan mehr anbieten wird, geht das eben nur über ein Umbiegen der Fensterfunktion - aber es geht immerhin.

Gerade dann, wenn man aus dem Berufsleben raus ist, wäre es ja eine sinnvolle Beschäftigung. Aber RGH hat ja momentan andere Sorgen

(Pflege der Eltern), was dann auch wieder verständlich ist. Zumindest könnte er, wenn es mal irgendwann die Zeit erlaubt, die paar Baustellen

per Patch beheben. Von denen gibt es hier im Forum ja ein paar, die andere und auch ich gemeldet hatten. Dabei sind dann auch noch ein paar

Containerfunktionen, die erweitert werden könnten, z.b. bei Json ein Remove zum Löschen und ein Set zum Ändern von Strings, Objecten und

Listen.