Subclassen per nProc

[AHT]

...da das zugrundeliegende Problem in XProfan wohl ein Variablenproblem ist, bräuchte man das eigentlich gar nicht. Unter Umständen ist die Lösung dafür viel einfacher (und auch kompletter).

Zitat von AHT

Unter Umständen ist die Lösung dafür viel einfacher (und auch kompletter).

Du sagst es: http://xprofan.com/xpse/

Alles oben beschriebene funktioniert bereits, jeder XProfaner kann bereits echte Threads und Callbacks programmieren.

Wem es nicht gelingt, nutzt einzig keine hierfür brauchbare Entwicklungsumgebung - die es dennoch aber gibt.

Andernfalls, viel Spaß beim weiterwarten - wir programmieren solange...

Salve, iF.

[Jac de Lad]

Es will aber nicht jeder XPSE benutzen, und so kommt es doch auf meine Liste des "Will-in-XProfan-12-Haben".

Was man "kann" klärt der Hinweis, doch aber nicht, "was jeder will".

Wer nur nicht können will, dem bleibt doch z.B. das Abwarten auf XProfan 12, 13, 14...,
um dann doch zu programmieren, was dann aber zuvor schon ("jahrlang") seit XProfan 11
programmiert wurde.

Stolz bin ich z.B. jetzt schon auf das neue Scroll-Control ( http://xprofan.com/t/?6274 ),
welches jeder auch ab sofort nutzen kann, statt auf eine XProfan-Version zu warten,
die dieses von Haus aus mitbringt.

Sowas vereinfacht wohlmöglich auch Roland die Arbeit, sei es, es bringt auf Ideen,
wie man was warum umsetzen könnte.

Salve, iF.

[AHT]

Na ja - mit XPIA geht das sogar noch besser .
Für mich ist eine Programmiersprache, mit der ich nicht richtig programmieren kann (hier wichtige APIs nutzen), keine vernünftige Programmiersprache. Daran ändert sich auch nichts, wenn man vor das Ding irgendwelche Tools schalten kann, die angeblich diese Fehler ausbügeln.

Um XPSE habe ich mich schon Jahre lang nicht mehr gekümmert.
Wenn du so überzeugt von dem Tool bist, stelle es doch einfach mal hier irgendwo vor und beschreibe mal, wie man zum Beispiel einen steuerbaren Service mit XPSE programmiert...
Bin echt gespannt, und ich schaue es mir auf jeden Fall an.

[Jac de Lad]

@iF: Wieso soll ich es dann nicht auf meine Wunschliste stellen? Ich wünsche mir ebenso, dass Progressbars implementiert werden, obwohl ich die bereits seit Ewigkeiten mit einer INC und ein wenig API erstellen kann.

[AHT]

Genau so ist. Ich kann auch fehlerfrei Callbacks aufrufen während irgendwelche anderen Profanschleifen laufen (und das mit XProfan9 und ohne XPSE) - bloß was ändert das an dem Problem???

Du scheinst XPSE nicht zu kennen, denn andernfalls und spätestens wer behauptet, SubClassing ginge mit XPIA noch einfacher, als mit XPSE, kennt entweder XPIA oder XPSE nicht oder scheitert beim Zählen von Zeilen und Anweisungen.

So gehts mit Windows:

long owp=setWindowLong(hWnd,gwl_wndProc,procAddr(hWnd.wndProc,4))

- und genau so gehts auch mit XPSE: Funktionsreferenz

So kann eine WNDProc aussehen:

nProc hWnd.wndProc
    Parameters wnd&,msg&,wp&,lp&
    return callWindowProc(getWindowLong(wnd&,gwl_userData),wnd&,msg&,wp&,lp&)
endproc

>> Wenn du so überzeugt von dem Tool bist

Es ist eine ergänzende Programmiersprache für XProfan, die imho hält, was sie verspricht und genau dort angreift, wo XProfans Potential technisch endet. Überzeugung bekommst Du vlt. in der Kirche.

>> Für mich ist eine Programmiersprache, mit der ich nicht richtig programmieren kann (hier wichtige APIs nutzen), keine vernünftige Programmiersprache.

Naja, nach meiner Theorie, kannst Du ja mit gar keiner Programmiersprache "richtig" Programmieren und nur deshalb entspringen Dir überhaupt erst solche "Aussagen". Nicht der Sprache wegen, sondern des Programmierens wegen. Scriptkiddis die im OS rumwurschteln wie Du es tust, verwechseln dies immer gerne mit "Programmieren", haben aber trotzdem meist nie programmiert. Ebenso ist eine Programmiersprache selten unzweckmässig, wer also meint, Sprache X sei nicht "vernünftig", weil sie nicht all seine Wünsche erfüllt, hat irgendwas komplett nicht verstanden.

>> Daran ändert sich auch nichts, wenn man vor das Ding irgendwelche Tools schalten kann, die angeblich diese Fehler ausbügeln.

Interessant und totaler Unfug, denn Du nimmst auch nicht Notepad als IDE, sondern wahrscheinlich eher XProfEd, um einfacher/besser mit XProfan programmieren zu können. Du kannst ja mal mit einer vernünftigen Programmiersprache namens C probieren, ohne "Tools" eine Exe zu erzeugen. Worüber reden wir, dass ist doch kein Level.

>> wie man zum Beispiel einen steuerbaren Service mit XPSE programmiert

Übersetze ich Dir gerne nach Profansyntax, wenn Du da Hilfe brauchst.

Zitat von Jac de Lad

@iF: Wieso soll ich es dann nicht auf meine Wunschliste stellen? Ich wünsche mir ebenso, dass Progressbars implementiert werden, obwohl ich die bereits seit Ewigkeiten mit einer INC und ein wenig API erstellen kann.

He, ich habe doch niemals gewünscht, dass Du es nicht auf Deine Wunschliste stellst! Ich habe ebenso Deinen Wunsch, kann ich auch beweisen - habe mir der Erfüllung wegen ja sogar XPSE für programmiert.

Ich hatte Deinem Wunsch doch nur hinzugefügt, dass dieser eigentlich vielleicht "unnötig" ist, weil bereits Lösungen frei für jedermann abrufbar - super Lösungen!

Das war doch kein Angriff auf Deinen Wunsch, den wir ohnehin "alle" hegen.

[Jac de Lad]

Ich hab die XPSE-Lösungen schon probiert und auch mit API. Bisher war das nicht zufriedenstellend, vielleicht liegts auch an mir (davon gehe ich fast aus). Deshalb auf meiner Wunschliste. Vielleicht meldet sich ja noch Roland zu Wort.

[Bangkok]

Ich denke hier geht es um Wünsche, die nativ in XProfan enthalten sein sollen, nicht um Tools die irgendetwas ermöglichen sollen und nicht um API's. Denn so gesehen könnte man die Entwicklung von XProfan dann einstellen, vielleicht noch ein paar Variablentypen dazu geben und fertig. Das weitere muss dann jeder selbst über API oder Tools regeln.

Was XPSE kann oder nicht kann, kann ich nicht beurteilen, da mir die Syntax nicht unbedingt zusagt und ich es deshalb auch nicht benutze. Mir sind native Funktionen auch lieber, denn die machen eine Programmiersprache aus, nicht irgendwelche Tools.

[AHT]

Ja Bankog, das sehe ich auch so!

> Ich denke hier geht es um Wünsche, die nativ in
> XProfan enthalten sein sollen, nicht um Tools die
> irgendetwas ermöglichen sollen und nicht um API's.

Das schließt diese Tools und Apis aber nicht aus
sondern ein, oder willste Gedankenpolizei.

> Denn so gesehen könnte man die Entwicklung von
> XProfan dann einstellen, vielleicht noch ein paar
> Variablentypen dazu geben und fertig.

Das sehe ich nicht so, denn Du stellst damit ja
in Frage, dass es Entwicklungsschritte gibt, und
behauptest, dass die Bedürfnisse der XProfaner
einfrieren. Ich meine, dass Gegenteil ist der Fall.

Tools und Apis helfen und ermöglichen die Entwicklung
des XProfan, Tools und Apis ermöglichen die Entwicklung
jeder guten Software, keiner hier entwickelt ohne
Tools, kaum einer ohne Apis.

Das Bedürfnis nach sicherem ProcAddr bestand,
in XProfan (ohne Präkompiler) wird es dieses sicherlich
auch irgendwann geben, was nur eben dem nichts nutzt,
der es jetzt benötigt, für den dieser Hinweis galt.

> mir die Syntax nicht unbedingt zusagt

C-Style ist doch optional, muss doch keiner nutzen?!
Standart, auch in nativen Funktionen, ist doch
normale Syntax, verstehe nicht, was Du meinst.

> Mir sind native Funktionen auch lieber

Ich weiß ja, dass Du in XProfan direkt eingebaute
Funktionen meinst, sei nur angemerkt, dass die
nativen Funktionen nicht weniger nativ sind,
als die in XProfan eingebauten. Die Sache ist nur,
habe ich eine Wahl, wenn mir XProfan eine native
Funktion nicht bietet, mir diese selber programmieren
zu können, oder eben nicht - die NProcs stehen
den in XProfan eingebauten nativen Funktionen
technisch jedenfalls in nichts nach, eher im Gegenteil,
sind sie immer direkt adressierbar und schnellst
aufrufbar aber der Hauptvorteil ist, dass man sich
diese selbst programmieren kann und dass sie mehr
"abkönnen" im Bezug auf Multithreadfähigkeit,
Callbacks und Hooks, sodass eben obige Jac-Wünsche
technisch bereits gebändigt sind, wenn auch noch nicht
mit reinem XProfan.

Wer das nicht braucht, oder mit anderen Tools gleiches
Verhalten erzielen kann, wollte ich mit meinem Hinweis
garnicht erfragt haben - zurecht wie ich finde.

[Jac de Lad]

Und wieder ein Thread zerquatscht. Vielleicht kann ein Admin das abtrennen, damit hier nur mein Wunsch steht, für den der Thread gedacht war. Damit will ich nicht sagen, dass ich was gegen diese Diskussion habe, ich finds hier nur fehl am Platz.

[Frabbing]

------------ abgetrennt --------------

Wer einen Precompiler benötigt, soll ihn doch benutzen. Es darf aber nicht verschwiegen werden, dass die native Technik, die XPSE von XPIA abgeschaut hat, einen großen Haken haben könnte, ist jedenfalls eine Vermutung von mir:
Damit erstellte Exedateien könnten anfällig gegenüber Virenwächtern sein. Es könnte eventuell damit gerechnet werden, dass ein Virentool diese Exe irtümlicherweise als infiziert anmeckert oder das in Zukunft plötzlich machen könnte...
Die eingebettete JWASM-Dll könnte von den Wächtern als Assembler-Dll erkannt werden, und da Viren oft in Assembler programmiert sind, werden solche Dateien strenger begutachtet. Mir ist das selber schon passiert, z.B. mit meiner Datei "Bewegungsmelder.exe" und ein bis zwei anderen kleineren Exen, die ich mit XPIA erzeugt habe. Der Prozentsatz ist zwar klein, aber der Nachteil könnte gegeben sein. Ein Nutzer deiner n-Procs könnte eventuell an den Fehlalarmen dann auch dann nichts ändern. XPIA-Code könnte ich zumindest noch entsprechend anpassen, auch wenn die Chancen auch nicht gut stehen.

Mir ist eine XProfan-native Funktion darum lieber als 4 nProcs oder XPIA-Funktionen. Nativ ist nicht gleich nativ.