Auch wenn scheinbar nicht mehr viele Anwender XProfan benutzen nehme ich es noch sehr gern. Und ich hoffe es wird noch weiterentwickelt.
Ist es noch zu früh schon mal ein paar Wünsche für die nächste Version zu äußern?
Auch wenn scheinbar nicht mehr viele Anwender XProfan benutzen nehme ich es noch sehr gern. Und ich hoffe es wird noch weiterentwickelt.
Ist es noch zu früh schon mal ein paar Wünsche für die nächste Version zu äußern?
Der iF (lassen wir olle Kamellen unter Programmiergöttern mal beiseite) meinte, dass mit dem eingebauten X4-ASM die Sprache in Richtung "eigener nativer Funktionen" weiterentwickelt werden kann, vielleicht nach Vorbild von xpse. Das kann aber aus Zeitgründen vermutlich nicht von RGH allein ausgehen, sondern wäre ein Community Effort.
Vorhanden ist ja das meiste in Windows schon - mir fehlen dazu leider sowohl Kenntnisse der Interna von XProfan als auch API-Kenntnisse. Naja, vielleicht in der Frühpense, das dauert aber noch ein Jährchen ...
Das klingt gut, aber es gibt natürlich noch jede Menge andere Dinge die nützlich wären. Renate oder diese modernen Office-Controls zum Beispiel. Das würde XProfan gleich einen moderneren Look verleihen. Ich werde demnächst mal mit der ProGUI.dll experimentieren, aber die kostet und der Autor ist scheinbar nicht mehr erreichbar. Wäre schade wenn wir unseren Programmen nicht mal einen aktuellen Look verpassen können.
Dazu kommt immer noch, dass ich mir wünsche die errorproc temporär umleiten zu lassen. Nützlich für Includes die Fehler anfangen wollen aber nicht wissen ob die errorproc schon verwendet wird. Bisher muss dann in der errorproc noch explizit was geändert werden, so könnte man die Include einbauen und fertig.
Sag mal ehrlich - wie viele von wirklich auf tausenden von Geräten laufenden, komplexeren Anwendungen hast du in XProfan bislang programmiert?
Bevor man mit Möglichkeiten für irgendwelche neuen Controls herumschmeißt, sollte man vielleicht mal in den Vordergrund stellen, dass sich mit der Sprache auf aktuellen Systemen überhaupt vernünftig Anwendungen schreiben lassen. Ohne 64Bit und Multithreading wird das absolut nichts.
Selbst Autoit ist für spezielle Sachen entwickelt worden, kann nicht alles, aber manches so gut, dass Anwendungen wie der AdwCleaner und das Farbar Recovery Scan Tool damit entwickelt wurden, die auf Millionen von Rechnern zum Einsatz kommen und dort auch laufen.
Das liegt daran, weil mit Autoit wirklich jeder Idiot dazu in der Lage ist, kleine administrative Anwendungen zu proggen, die unter 32Bit und 64Bit nicht nur lauffähig sind, sondern auch problemlos laufen. Das kann Autoit gut, das kann Autoit besser als alle andere Sprachen und dafür ist Autoit geschrieben worden.
Was kann XProfan gut? Was kann XProfan besser als jede andere Sprache - und vor allen Dingen, was kann die Sprache wirklich richtig?
Sag mal ehrlich - wie viele von wirklich auf tausenden von Geräten laufenden, komplexeren Anwendungen hast du in XProfan bislang programmiert?
Will er das überhaupt? Wer von den Profan-Nutzern außer Dir will denn das? Meine Erfahrung mit Profan sagt mir eher, daß hier der Spaßfaktor eine große Rolle spielt. Mal das Eine oder Andere für die Eigennutzung schreiben. Das darf dann durchaus mal durch Freunde oder Bekannte genutzt werden oder auch in einem Forum wie hier für Gleichgesinnte vorgestellt werden. Mehr wollen die Profannutzer in aller Regel gar nicht. Für manche ist schon das zu hoch gegriffen, die wollen einfach nur ein bißchen Spaß an ihrem Rechner. Einfach mal selbst was schaffen. Nennt sich dann einfach nur Hobby.
Siehe auch zum Beispiel Briefmarkensammler. Nicht allzuviele haben eine wirklich wertvolle Sammlung. Die dürfen dann aber doch nach ihrem Interessengebiet weiter sammeln. Es gab übrigens auch einen Streichholzsammler. Der hat deformierte Streichhölzer gesammelt und nach der Art der Deformation katalogisiert. Interessiert keinen Menschen aber der hatte Spaß dran.
Gruß Volkmar
Andreas,
Ich mag dich, du bist hilfsbereit und ein fabelhafter Programmierer. Aber es hilft uns nicht weiter wenn du in jedem XProfan-Thread anbringt, dass XProfan langsam, unflexibel und veraltet ist. Ich möchte jetzt hier keinen Streit eröffnen, aber von diesen Beiträgen hat keiner was.
Edit: Volkmar war schneller.
Meine Erfahrung mit Profan sagt mir eher, daß hier der Spaßfaktor eine große Rolle spielt
OK - dann wird es eine Sprache für immer weniger Leute sein, die Freude an etwas Speziellem haben und nichts anders können. Die Anzahl der Leute wird irgendwann gegen 0 gehen.
Aus einer Sprache, in der nichts wirklich richtig funktioniert, lässt sich leider irgendwann auch nichts mehr lernen. Neue Leute können auch nicht hinzu kommen, wenn die Sprache für nichts spezielles besonders geeignet ist.
Je weniger Leute in einer Sprache programmieren, um so weniger offenen Code gibt es, an dem sich die Sprache am Ende weiter entwickeln kann.
Deswegen meine Fragen:
Was kann XProfan besonders gut? Wofür ist die Sprache extrem gut geeignet - und was kann sie besser als jede andere Sprache? Wofür eignet sich die Sprache nicht oder wofür ist sie nicht so gut geeignet?
Schaue ich mir zum Beispiel Autoit an, kann ich dam in einem halben Tag Zeit und etwas Powershell Kenntnissen die Sprache so gut lernen, dass ich kleine administrative Einzelthread-Anwendungen damit schreiben kann, für die ich ansonsten 10 Jahre erst mal das Programmieren lernen und Einblicke ins OS nehmen müsste. Deswegen wird die Sprache von ganz bestimmten Leuten genutzt.
Mit PureBasic kann ich extrem einfach API basierende Anwendungen bis weit in den nativen Bereich hinein proggen, für die ich in anderen Sprachen erst mal wochenlang suchen und vielleicht noch nicht einmal die passenden Infos finden würde.
Ich habe mir XProfan mal zugelegt, weil es damals besonders gut in bestimmten Sachen war:
Die Vorteile existieren eigentlich alle nicht mehr.
Das steht doch hier gar nicht zur Debatte. Vielleicht wäre ein eigener Threads dafür gut.
Was die Sprache besonders gut können und womit sie sich gegenüber anderen Sprachen auszeichnen soll,, halte ich eigentlich für eine kommende Version für die wichtigste Frage überhaupt. Deswegen passt das sehr gut hier hin.
Also - wo soll das denn überhaupt hin gehen?
Ich werde demnächst mal mit der ProGUI.dll experimentieren
Das wird wahrscheinlich nicht funktionieren. Der Autor hat die Entwicklung eingestellt, so das ich auf weitere Updates meiner "Gold-Source" Lizenz wohl eher abschminken sollte. Wer sich den Chaos-Source mal angesehen hat (in PureBasic) wird so etwas aber vorausgesehen haben .
Im Grunde wäre es einfacher diesen Code in XProfan nach Programmieren, aber ob das lohnt? Inzwischen werden doch ganz andere Sachen in Windows genutzt.
Am besten beerdigt Du die DLL!
Ich denke, man sollte sich mal gewaltig darüber Gedanken machen, wo man mit der Sprache denn eigentlich hin will.
Will man eine Sprache, in der einfach GUI zu proggen ist, sollte die GUI dann wenigsten sicher funktionieren, wenn das Programm nebenbei auch noch was tut.
Will man Scriptleute begeistern, sind die meist administrativ tätig. Die schreiben kleine Singelthread Anwendungen, die man meist, während sie eine Aufgabe durchführen, noch nicht einmal bedienen muss oder kann. Ohne 64Bit geht aber administrativ sehr vieles nicht.
Das ist alles nichts ganzes, was die Sprache bietet. Was man wirklich gut mit der Sprache tun kann, sehe ich eigentlich nicht. Ich sehe nur Sachen, die so halbwegs gehen - und da kann viele Freeware mehr.
Das wird wahrscheinlich nicht funktionieren. Der Autor hat die Entwicklung eingestellt, so das ich auf weitere Updates meiner "Gold-Source" Lizenz wohl eher abschminken sollte. Wer sich den Chaos-Source mal angesehen hat (in PureBasic) wird so etwas aber vorausgesehen haben .
Im Grunde wäre es einfacher diesen Code in XProfan nach Programmieren, aber ob das lohnt? Inzwischen werden doch ganz andere Sachen in Windows genutzt.Am besten beerdigt Du die DLL!
Shite. Ich dachte ich kriege die endlich mal halbwegs moderne Controls hin.
Shite. Ich dachte ich kriege die endlich mal halbwegs moderne Controls hin.
Du hättest dann wunderbar moderne Controls für eine Programmiersprache, die für das Programmieren richtiger GUI Anwendungen für moderne Systeme gar nicht wirklich geeignet ist. Warum?
Ich dachte ich kriege die endlich mal halbwegs moderne Controls hin.
Die werden im allg. Gezeichnet. Dies wurde in PureBasic mit dem CanvasGadget umgesetzt. Dies ist nur eine weiße Leinwand auf die Gemalt werden kann und dies aktualisiert sich selbständig.
Es löst alle Ereignisse, egal ob Mouse, Klick oder Focus usw. aus, auf die man dann reagieren kann. Es kann 2D Drawing oder mit der Vector-Lib drauf gemalt werden.
Auch dies sollte in XProfan möglich sein, bliebe nur die Frage ob alle Ereignisse weitergeleitet werden können und ob da schnell genug drauf reagiert. Hier mal die möglichen Ereignisse:
#PB_EventType_MouseEnter : Der Maus-Cursor "betrat" das Gadget
#PB_EventType_MouseLeave : Der Maus-Cursor verließ das Gadget
#PB_EventType_MouseMove : Der Maus-Cursor bewegte sich
#PB_EventType_MouseWheel : Das Maus-Rad wurde bewegt
#PB_EventType_LeftButtonDown : Der linke Maus-Knopf wurde gedrückt
#PB_EventType_LeftButtonUp : Der linke Maus-Knopf wurde los gelassen
#PB_EventType_LeftClick : Ein Klick mit der linken Maus-Taste
#PB_EventType_LeftDoubleClick : Ein Doppelklick mit der linken Maus-Taste
#PB_EventType_RightButtonDown : Der rechte Maus-Knopf wurde gedrückt
#PB_EventType_RightButtonUp : Der rechte Maus-Knopf wurde los gelassen
#PB_EventType_RightClick : Ein Klick mit der rechten Maus-Taste
#PB_EventType_RightDoubleClick: Ein Doppelklick mit der rechten Maus-Taste
#PB_EventType_MiddleButtonDown: Der mittlere Maus-Knopf wurde gedrückt
#PB_EventType_MiddleButtonUp : Der mittlere Maus-Knopf wurde los gelassen
#PB_EventType_Focus : Das Gadget erhielt den Tastatur-Fokus
#PB_EventType_LostFocus : Das Gadget verlor den Tastatur-Fokus
#PB_EventType_KeyDown : Eine Taste wurde gedrückt
#PB_EventType_KeyUp : Eine Taste wurde los gelassen
#PB_EventType_Input : Text-Eingabe wurde generiert
#PB_EventType_Resize : Das Gadget wurde in der Größe verändert
Alles anzeigen
Ich habe bis vor kurzem ein völlig heterogenes WAN von Win95 bis Windows 8 betreut, dessen einzige gemeinsame Komponenten Internet und dBASE III bzw. IV waren. Welche andere Programmiersprache ausser XProfan hätte Integration und Konsistenzprüfung über die letzten 25 Jahre (!) unterstützt und ohne nennenswerte Probleme mitgemacht? Solange 32 bit auch auf 64-bit-Systemen tadellos funktioniert, bleibe ich XProfan-Fan!
Welche andere Programmiersprache
Fast jede!
PureBasic unterstützt DBase seit Februar 2002, also 16,5 Jahren und die Netzwerkunterstützung in XProfan hab ich wohl noch nicht gefunden.
Solange 32 bit auch auf 64-bit-Systemen tadellos funktioniert
Das ist nur eine Frage der Zeit, div. Treiber z.B. von NVidia, gibt es nur noch in 64-Bit. 32-Bit Anwendungen werden immer weniger.
Fast jeder Programmierer programmiert für die Zukunft, es dauert ja auch, bis ein richtiges Programm fertiggestellt ist. Da sollte es in jedermanns Interesse liegen, das die Programmiersprache mit Ihren Aufgaben wächst. Eine Anwendung für DBase schreiben kann erforderlich sein, ist aber nicht unbedingt das Ziel eines Programmierers. Für den sind meist selbst die Einschränkungen von Access zu viel.
Was man wirklich gut mit der Sprache tun kann, sehe ich eigentlich nicht
Ich auch nicht, aber jeder setzt da wohl andere Prioritäten.
Die 64 Bit Version müßte Roland mal unbedingt nachreichen.
Bis zur Version X3 gibt es sie ja schon.
Was für mich XProfan interessant macht, ist die schnelle Umsetzung,
wenn man kleine Tools braucht. Auch das Erlernen macht es für
Neueinsteiger interessant.
Auch bei PureBasic sieht man, daß es immer weniger Leute gibt,
die sich dafür interessieren. Da ist das dt. Forum zeitweise genauso
tot, wie hier das. Auch das SpiderBasic steht schon seit Ewigkeiten
halbfertig da und geht nicht weiter.
Das ist halt bei Ein - Mann - Projekten so. Auch bei PureBasic
läßt sich Fred ellenlang Zeit und nichts passiert. Ich denke, daß
das Interesse an solchen Nischensprachen, ob XProfan oder PB
oder sonstige, immer mehr nachläßt.
Das lässt sich in PureBasic in gleicher Weise umsetzen - im API Bereich sogar noch sehr viel schneller und besser. Wegen 64Bit Compiler und Unterstzützung von Multithreading muss ich mir noch nicht einmal Gedanken darüber machen, wie ich an nicht funktionierenden APIs vorbeikomme, meine GUI trotz Sachen, die nebenbei getan werden, funktionsfähig halte - und über irgendwelche Geschwindigkeitsprobleme sowieso nicht.
Im Prinzip habe ich also oben gelogen - es llässt sich nicht in gleicher Weise umsetzen, sondern besser und einfacher.
Zur Kenntnis genommen.
Solange 32 bit auch auf 64-bit-Systemen tadellos funktioniert, bleibe ich XProfan-Fan!
Versuchhe mal folgendes umzusetzen:
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!