[*]Profan

- Seite 3 -

Clemens
Meier

Ich vermisse in XProfan reguläre Ausdrücke. Möglichst in den Funktionen von nur Suchen und Suchen und Ersetzen

Ich meine reguläre Ausdrücke im Programm zur Laufzeit. Zum Beispiel möchte ich demnächst ein Analyse-Programm für Logfiles bauen, weil alle bisherigen entweder schweineteuer sind, oder wenn kostenlos, unzureichend sind. Um ein Logfile ordentlich auseinander zu nehmen, wären reguläre Ausdrücke einfach toll. Es gäbe aber auch noch andere Anwendungen, die eine reine von if- und case-Anweisungen extrem verkürzen würden, inklusive Eingabeprüfungen.

XProfan 9.1; XP SP2; FF; Editpad

20.03.2006 ▲

Clemens
Meier

Vielleicht noch eine Kleinigkeit: Bei Substr$ erfolgt eine Fehlermeldung bei negativen Nummer des Teilstrings. Zum einen sollte es eine Funktion geben, mit der man die Anzahl der Teilstrings ermitteln kann (man muss ansonsten jedesmal eine Schleife durchlaufen lassen. Zum anderen, warum wertet die Funktion negative Nummer nicht als Rückwärtsermittlung des Strings aus.

Als Beispiel: wert$ = substr(liste$,-1,,) ermittelt den letzten Teilstring.

Und als neue Funktion:

anzahl% = countsubstr(liste$,,)

Wäre ein kleiner Beitrag zum effektiveren Programmieren

XProfan 9.1; XP SP2; FF; Editpad

25.03.2006 ▲

Clemens
Meier

Während eines neuen Projektes, ist mir noch eine Funktion aufgefallen, die in den bisherigen XProfan-Versionen zu fehlen scheint. Nämlich eine Suchfunktion in Bereichs-Arrays. Man kann zwar in einem Bereich selbst suchen, aber sobald ein Bereich eine Struktur hat oder ein Array ist, geht da nicht mehr viel bzw. nur in While-Schleifen mit Hilfsvariablen.

Schön wäre eine Funktion wie diese:
index% = areafind(bereich#[].name$,Ernst,1)

Der 3. Parameter könnte dazu dienen, wie genau gesucht werden soll. Als Ergebnis könnte die index-Nummer zurückgegeben oder 0, wenn nichts gefunden wurde.

XProfan 9.1; XP SP2; FF; Editpad

26.03.2006 ▲

Clemens
Meier

Beim Programmieren fallen einem doch immer wieder Dinge ein, von denen man hofft, diese in der nächsten Version wieder zu finden:

assoziierte Arrays - mir ist bekannt, dass das wohl ein Problem mit dem Speichermanagement geben wird. Schön wäre es trotzdem.

Globale Variablen in Prozeduren definieren können wäre eine feine Sache. Man weiß zum Beispiel nicht, wieviele Arrays benötigt werden. Natürlich kann man dann einmal hingehen und ausreichend Arrays dimensionieren. Doch was ist, wenn diese auch nicht ausreichen. In der Hilfe gibt es zwar einen Hinweis, wie man eine Art Redim ausführt, einfacher wäre es, wenn man das Array in ein Hilfsarray zwischenspeichert, das ursprüngliche einfach mit dispose, declare und dim Redimensionieren könnte, um dann die Daten aus dem Hilfsarray zurückspielt.
Ferner fehlt mir dynamische Stukturen. Ich habe eine Prozedur geschrieben, um Daten aus der Datenbank entsprechend aufzubereiten. Muss ich die Datenbank erweitern, muss ich zwangsläufig auch die Prozedur ändern. Besser wäre es, wenn ich die Prozedur so gestalten könnte, dass ich die Struktur eines Bereiches dynamisch an die Datenbank anpassen könnte. Ich habe jedenfalls bis jetzt noch keine Möglichkeit gefunden, als Bereiche per Hand entsprechend zu definieren, also in Variablen festzuhalten von welcher Position bis zu welcher, welche Daten aus einem bestimmten Datenbankfeld stammen.

XProfan 9.1; XP SP2; FF; Editpad

30.03.2006 ▲

Clemens
Meier

Ach ja, bevor ich es vergesse. Es gibt Funktionen und Befehle, die am Ende ihres Namens noch immer das $ haben als Kennzeichen, dass diese Funktionen und Befehle einen String zurückliefern. Beim lesen eines Quelltextes stolpere ich immer wieder darüber, weil auch Stringvariablen ein $ am Ende haben. Wäre es nicht einfacher, das $ bei den Funktionen und Befehlen wegzulassen?

Automatische Konvertierung:
Funktioniert meistens. Was aber nicht funktioniert ist z.B.:
wert% = readini$()...
wert% hat bei mir dann immer den wert 0, egal was ich aus der Ini auslesen. Gleiches bei substr$ etc. Hat mich in der Vergangenheit mehrfach Kopfzerbrechen bereitet. Jetzt nicht mehr, weil ich es weiß. Aber es müsste doch möglich sein, dass auch hier eine automatische Konvertierung stattfindet.

XProfan 9.1; XP SP2; FF; Editpad

30.03.2006 ▲

Jac
de
Lad

Dadurch würde jeder Aufruf einer Funktion sehr viel langsamer werden! (Schätze ich jedenfalls.) Ich glaube nicht, dass sich der Aufwand lohnen würde, es sei denn, der Compiler würde anhand des Variablentyps erkennen, ob ein Val() oder ein Str$() vorangesetzt werden müsste und dies dann automatisch tun. Hm, eigentlich keine schlechte Idee!!!

Jac

Profan² 2.6 bis XProfan 11.1+XPSE+XPIA+XPRR (und irgendwann XIDE)
Core2Duo E8500/T2250, 8192/1024 MB, Radeon HD4850/Radeon XPress 1250, Vista64/XP

30.03.2006 ▲

RGH

@Michael Wodrich:

[quote:36a8e59522=Michael Wodrich]..., solange man ein Objekt nicht an einen LongInt zuweisen kann.[/quote:36a8e59522]
Was jetzt schon funktioniert:

MeinLong& = Addr(MeinObjekt#): Die Adresse des Objektes wird der Long-Variablen zugewiesen.

Was auch (noch) funktioniert:

MeinLong& = MeinObjekt#: Auch hier wird die Adresse des Objekte der Long-Variablen zugewiesen. Diese Variante wird aber möglicherweise für Objekte in XProfan 10 nicht mehr funktionieren. Die Variante mit Addr bleibt jedoch erhalten.

Was Dir also vermutlich fehlt, ist die Möglichkeit einem anderen Objekt (möglichst der gleichen Klasse) diese Adresse zuzuweisen. Ich denke derzeit über ein SetAddr(MeinAnderesObjekt#, Mein Long&)* nach.

Gruß
Roland

* (Genaue Syntax noch ohne jede Gewähr)

EDIT: In XProfan 9.1 funktioniert auch MeinObjekt# = MeinLong&. (In der Subscriptionsversion von XProfan 10 derzeit allerdings nicht. Das ist allerdings eher ein unerwünschter Nebeneffekt ...)

Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4

RGH

[quote:0aeb9ca536=Jacob Liebeck]
Erweiterte Variablen wären äußerst gut. Also Int64 und 64Bit-FLoat!
Jac

[/quote:0aeb9ca536]
Die Float-Variablen entsprechen bereits dem Typ Double in C++ oder Delphi, sind also 64Bit (8 Byte) breit!

Gruß
Roland

Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4

Jac
de
Lad

Tschuldigung, verschrieben...ich meine 64Bit-Int und 80Bit-Float (Extended)!

Profan² 2.6 bis XProfan 11.1+XPSE+XPIA+XPRR (und irgendwann XIDE)
Core2Duo E8500/T2250, 8192/1024 MB, Radeon HD4850/Radeon XPress 1250, Vista64/XP

64 Bit INT also DoubleLongs oder LongLongs

halte ich auch für wichtig. Vor allem beim Arbeiten mit dem Dateisystem sind sonst Dateien > 2 GB nur schwierig > 4 GB nur sehr schwierig zu bearbeiten

RGH

[quote:098d09f434=Jacob Liebeck]Dadurch würde jeder Aufruf einer Funktion sehr viel langsamer werden! (Schätze ich jedenfalls.)Jac

[/quote:098d09f434]
Viel langsamer nicht, aber ein wenig langsamer doch. Manchmal wünschte ich, ich hätte mit diesen automatischen Umwandlungen nie angefangen und würde etwas mehr die Strenge von Pascal bzw. Delphi walten lassen. Manche Teile des XProfan-Codes wären dann übersichtlicher (und damit auch stabiler) und möglicherweise sogar schneller.

Gruß
Roland

Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4

01.04.2006 ▲

RGH

[quote:32c676fda1=iF]iF schrieb: Ich wünsche mir für XProfan10:
a) Startpaint

-1 benötigt kein %hwnd mehr, und/oder
b) %hwnd

(Hauptfenster) kann erzeugt werden ohne in der Taskbar zu erscheinen
c) clearlist

mit Handle als Parameter löscht Listboxinhalt .[/quote:32c676fda1]
a) StartPaint -1 hat noch nie ein %HWnd benötigt! ;) Ok, es funktionierte aber nur sinnvoll, wenn es eine Memorybitmap gab. Um diese zu erstellen benötigt man die Befehle MCLS oder MLOADBMP. Diese beiden setzten ein Hauptfenster (%HWnd) vorraus. Ab der nächsten Subscriptionslieferung geht es auch ohne.

b) gibt es ja schon in XProfan 9.1

c) Ab der nächsten Subscriptionslieferung kann dem Befehl CLEARLIST das Handle einer Listbox oder Choicebox folgen und diese wird gelöscht.

In diesem Zusammenhang funktionieren alle Listboxfunktionen (AddString

und SelectString

) nun auch für Choiceboxen. die Funktionen AddChoice, DeleteChoice und MoveListToChoice entfallen daher, werden vom Interpreter und Compiler aber noch erkannt und entsprechend umgewandelt.

Mit ClassOf

([B#|N&]) kann nun auch der Klassenname eine Windowsklasse ermittelt werden, wenn der Parameter keine Bereichsvariable, sondern ein Handle zu einem Fensterobjekt ist. So kann also z.B. ermittelt werden, ob ein Handle zu einer Auswahlbox, einem Button oder einem Editfeld gehört.

Ich hoffe, daß die nächste Subscriptionslieferung heute noch rausgeht.

Gruß
Roland

EDIT: MoveListToList

, MoveListToChoice

und MoveListToEdit

werden zu MoveListToHandle zusammengefaßt. XProfan erkennt dann aufgrund der Fensterklasse des Handles, wohin gemoved wird. Außerdem gibt es nun auch die Umkehrfunktion: MoveHandleToList, mit der die Zeilen der List-, Auswahl- oder Multieditbox der Listboxliste hinzugefügt werden. Die bisherigen Funktionen werden auch hier vom Cpiler und Interpreter erkannt und entsprechend umgewandelt.

Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4

01.04.2006 ▲