Jacs Wünsche für XProfan 12

[Jac de Lad]

So, da nun die Subscriptionphase für XProfan 12 angelaufen ist (ich habs mir schon bestellt) möchte ich gleich mal meine Wünsche loswerden.

Am besten alle anderen Wünsche werden auch hier gesammelt. Vielleicht kann Roland auch darauf eingehen. Ich würde sagen, wenn Diskussionen erforderlich sind, dann macht einen neuen Thread mit dem Thema auf, damit dieser hier für die Auflistung der Wünsche vorbehalten bleibt.

Meine Wünsche:
- Die schonmal angesprochenen XPDLs
- Subclassing auch außerhalb von Waitinput
- Errorproc auf eine andere Proc umleitbar
- Downloadfunktion abbrechbar und mehrere Downloads gleichzeitig
- mehr native Unterstützung für Common Controls (Progressbar, Rebar! etc.)

[AHT]

• Multithreading über API
• Subclassing von Controls auf Dialogen mit eingeschalteter Messageverarbeitung

[Frabbing]

Subclassing von Controls auf Dialogen mit eingeschalteter Messageverarbeitung

Gibt es schon.

[AHT]

Ach so. Dachte, das wäre nur bislang nur innerhalb des Hauptfensters möglich.

[Frabbing]

Nein, seit "SubClassProc" alles kein Problem. Ich selber subclasse auch fast nur noch mit XProfan, nicht mehr extra in Assembler.

[Frabbing]

Controls auf Dialogen lassen sich herrlich zum Hauptfenster "durchschleifen", sodass du alle Controls in der Hauptschleife abarbeiten lassen kannst:

If SubClassMessage(control&, ~WM_COMMAND)
     Sendmessage(%hwnd,$~WM_COMMAND,&swparam,&slparam)
...

[AHT]

Dann schließe ich mich mal Jac an:

• Subclassing auch außerhalb von Waitinput mit eingeschalteter Messageverarbeitung

Zur Zeit regele ich das, was Jac da möchte (reagieren auf Fensterklicks während eine sehr lange Schleife ununterbrochen läuft), mit meiner älteren Version über die WM_TIMER Message (trickse da etwas rum, weil XProfan im Prinzip auch das nicht möchte -> PPFScanner: Da reagieren unter anderem die Tabs, während der Scan läuft).
Wäre das erste Problem gelöst, hätte sich wohl auch die Klamotte mit dem Subclassing erledigt.

[Jac de Lad]

Schön wäre auch eine native Möglichkeit um MenuItems fett oder kursiv zu machen (Fett ist besonders gut für Contextmenüs, um die Doppelklickaktion zu kennzeichnen).

Jac

[p. specht]

Ich hoffe auf ein fehlertoleranteres Math-Pack (siehe link zu dem RGH-Soft-Beitrag).
Liebe Grüße

[Jac de Lad]

Vielleicht gibt es ja eine Möglichkeit, dass man eine Proc in der Form Background(ProdAddr("Proc"),...), die dann im Hintergrud läuft. Allerdings müsste die Kommunikation und der Zugriff auf Variablen fehlerfrei laufen. So wäre es dann ganz einfach möglich Hintergrundaktionen zu programmieren.

Jac

[AHT]

Auch das wäre nichts, womit man vernünftig Arbeiten könnte, denn manche APIs erstellen den zweiten Thread selbst - das ist zum Beispiel beim erzeugen eines Services so.
Ich denke, mit einer Programmiersprache sollte man erst mal vernünftig programmieren könnte - und dazu gehört vor allen Dingen, das man ganz normale APIs problemlos ausführen kann, wie zum Beispiel die SetTimer API. Profan brngt eine ganze Menge nette Sachen mit - die macht es sich an anderen Stellen mit diesem Fehler aber wieder kaputt (und ich denke, das muss nicht so sein).

[RGH]

@AHT:

Da XProfan als einfache Sprache für Anwender und nicht für Systemprogrammierer entwickelt wurde, liegt der Fokus nicht in erster Linie darauf, dass möglichst alles mit API-Aufrufen gemacht wird, sondern umgekehrt darauf, dass das, was die Anwender wünschen, möglichst ohne APIs möglich ist. Da unter Windows alles über APIs läuft, könnte man auf 90% der Funktionen und Befehle verzichten, hinter denen ja eigentlich "nur" API-Aufrufe stehen.
BTW: So eine Version hatte ich ja mal gemacht:
PurProfan: Kein eigenes Messagehandling (quasi reinster Fast-Mode), keine Funktionen und Befehle, die intern APIs verwenden, sondern nur die Struktur-Befehle (wie z.B. While-Scheifen, IF-Abfragen, Variablen-Deklarationen und -Zuweisungen, mathematische Funktionen, etc.). Ich hatte das damals als Freeware komplett mit Compiler und Beispielen zur Verfügung gestellt. Allerdings war die Resonanz - vorsichtig formuliert - eher überschaubar. Kurz: Ich habe diese Richtung nicht weiter verfolgt.
Sollte wider Erwarten doch noch Interesse bestehen, könnte ich nach XProfan 12 noch mal eine aktualisierte Version versuchen ... Wenn das XProfan-Interne Messagehandling wegfällt, dürfte auch ein Eliminieren der bisherigen globalen Datenstrukturen in PurProfan möglich sein und damit stünde dann der Verwendung der Thread-APIs nichts mehr im Wege. (Man könnte natürlich einwerfen, dass jeman der so etwas will, auch gleich zu C++ greifen könnte, zumal es da ja auch Einiges an Freeware gibt ... aber das ist ein anderes Thema ... )

Gruß
Roland

[Bangkok]

Hallo Roland,

ich habe diese Purprofan-Version noch auf der Festplatte, aber ein Compiler war damals nicht dabei, ich habe jedenfalls keinen und der mitgelieferte Editor sieht es auch nicht vor. Ist vielleicht der Grund warum das Interesse überschaubar blieb, denn der Compiler ist ja mit das wichtigste Element. Ich hatte damals auch damit rumgespielt, habe es dann aber mangels Compiler eingestellt.

[Frabbing]

Ja, ich hatte auch ein bischen rumprobiert, fand es dann aber zu rudimentär.

[AHT]

Zitat von RGH

@AHT:

Da XProfan als einfache Sprache für Anwender und nicht für Systemprogrammierer entwickelt wurde, liegt der Fokus nicht in erster Linie darauf, dass möglichst alles mit API-Aufrufen gemacht wird, sondern umgekehrt darauf, dass das, was die Anwender wünschen, möglichst ohne APIs möglich ist.

OK. kümmere dich weiterhin nicht darum, dass deine Sprache vernünftig läuft, sondern baue weiterhin eine ganze Menge so schöner Funktionen ein, wie Readini$ und Writeini, bei denen erst nach Jahren irgendeinem Anwender auffällt, dass man sich locker damit die Registry zerschießen kann .

Zitat von RGH

BTW: So eine Version hatte ich ja mal gemacht:
PurProfan: Kein eigenes Messagehandling (quasi reinster Fast-Mode), keine Funktionen und Befehle, die intern APIs verwenden, sondern nur die Struktur-Befehle (wie z.B. While-Scheifen, IF-Abfragen, Variablen-Deklarationen und -Zuweisungen, mathematische Funktionen, etc.). Ich hatte das damals als Freeware komplett mit Compiler und Beispielen zur Verfügung gestellt.

Im Prinzip könntest du beides haben - Messageverarbeitung und vernünftiges Funktionieren deiner Sprache, das ist es ja .
Mit dem Problem, dass in deiner Sprache auftritt, haben scheinbar schon eine ganze Menge Leute in anderen Sprachen zu tun gehabt. Überall, wo das der Fall ist, kann man davon ausgehen, dass sich Leute sehr intensiv mit der Lösung des Problems beschäftigt haben, deren Intelligenz weit über der eigenen liegt. Das ist, wenn ich es richtig sehe, auch hier der Fall. Ich habe unter anderem (neben der besten und einfachsten Lösung für solche Probleme) auch den Lösungsvorschlag genau unter die Lupe genommen im Netz vorgefunden, den dir D.S. vor ein paar Jahren gemacht hat. Da kann man auch genau nachlesen, warum der für XProfan wohl nicht funktionieren wird - das ist also nicht auf meinem Mist gewachsen (das nur, falls du mir nicht zutraust, überhaupt durch irgendwas Durchblick zu haben - das kann ja sein - vielleicht traust du ja hauptberuflichen Programmierern und Professoren mehr zu).

PS: Damit wir uns nicht wieder missverstehen - an deiner Programmiersprache musst du gar nichts ändern. Ich habe seit einigen Jahren weder Zeit noch Lust mich wirklich intensiv mit der Sprache auseinanderzusetzen und gewerblich tue ich das auch schon lange nicht mehr. Ich sage dir nur, was man ändern kann, das ist alles.