[*]Profan

- page 3 -

Clemens
Meier

je vermisse dans XProfan reguläre Ausdrücke. Möglichst dans den Funktionen de seulement chercher et chercher et Ersetzen

je mon reguläre Ausdrücke im Programme zur Laufzeit. Zum Beispiel voudrais je bientôt un Analyse-Programme pour Logfiles construire, weil alle bisherigen entweder schweineteuer sommes, ou bien si kostenlos, unzureichend sommes. Um un Logfile réglé auseinander trop prendre, wären reguläre Ausdrücke simple toll. Es gäbe mais aussi encore autre Anwendungen, qui une reine de si- et cas-Anweisungen extrem verkürzen würden, inclusivement Eingabeprüfungen.

XProfan 9.1; XP SP2; FF; Editpad

20.03.2006 ▲

Clemens
Meier

peut-être encore une Kleinigkeit: chez Substr$ erfolgt une Fehlermeldung chez negativen numéro des Teilstrings. Zum une sollte es une Funktion donner, avec qui on le nombre qui Teilstrings ermitteln peux (on muss ansonsten chaque fois une Boucle durchlaufen laisser. Zum anderen, pourquoi wertet qui Funktion negative numéro pas comme Rückwärtsermittlung des Cordes aus.

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

et comme neue Funktion:

anzahl% = countsubstr(liste$,,)

Wäre un kleiner Beitrag zum effektiveren Programmieren

XProfan 9.1; XP SP2; FF; Editpad

25.03.2006 ▲

Clemens
Meier

Au cours de eines neuen Projektes, c'est moi encore une Funktion aufgefallen, qui dans den bisherigen XProfan-Versionen trop manquer scheint. Nämlich une Suchfunktion dans Bereichs-Arrays. il peut zwar dans einem Bereich selbst chercher, mais sobald un Bereich une Struktur hat ou bien un Array ist, allez là pas plus viel bzw. seulement dans Tandis que-Schleifen avec Hilfsvariablen.

joli wäre une Funktion comment cet:
index% = areafind(bereich#[].nom$,Ernst,1)

qui 3. paramètre pourrait en supplément dienen, comment oui c'est ca gesucht volonté soll. comme Ergebnis pourrait qui index-numéro retour ou bien 0, si rien trouvé wurde.

XProfan 9.1; XP SP2; FF; Editpad

26.03.2006 ▲

Clemens
Meier

Beim Programmieren tomber einem doch toujours wieder Dinge un, de denen on hofft, cet dans qui prochain Version wieder pour trouver:

assoziierte Arrays - mir ist bekannt, dass cela wohl un Problem avec dem Speichermanagement donner wird. joli wäre es quand même.

Globale Variablen dans Prozeduren définir peut wäre une feine l'affaire. on sait zum Beispiel pas, wieviele Arrays nécessaire volonté. Bien sûr peux on ensuite einmal hingehen et ausreichend Arrays dimensionieren. Doch quoi ist, si cet aussi pas ausreichen. dans qui Aider gibt es zwar une Hinweis, comment on une Art Redim ausführt, einfacher wäre es, si on cela Array dans un Hilfsarray zwischenspeichert, cela ursprüngliche simple avec dispose, declare et dim Redimensionieren pourrait, um ensuite qui données aus dem Hilfsarray zurückspielt.
Ferner fehlt mir dynamische Stukturen. j'ai une Procédure geschrieben, um données aus qui banque de données entsprechend aufzubereiten. Muss je qui banque de données erweitern, muss je zwangsläufig aussi qui Procédure changement. Besser wäre es, si je qui Procédure so gestalten pourrait, dass je qui Struktur eines Bereiches dynamisch à qui banque de données anpassen pourrait. j'ai jedenfalls jusqu'à maintenant encore aucun Possibilité trouvé, comme Bereiche per main entsprechend trop définir, alors dans Variablen festzuhalten de quel Position jusque quel, quelle données aus einem certain Datenbankfeld stammen.

XProfan 9.1; XP SP2; FF; Editpad

30.03.2006 ▲

Clemens
Meier

ah oui, bevor je es vergesse. il y a Funktionen et Befehle, qui am Ende ihres Namens encore toujours cela $ avons comme Kennzeichen, dass cet Funktionen et Befehle une String zurückliefern. Beim lesen eines Quelltextes stolpere je toujours wieder par-dessus, weil aussi Stringvariablen un $ am Ende avons. Wäre es pas einfacher, cela $ chez den Funktionen et Befehlen wegzulassen?

Automatique Konvertierung:
Funktioniert la plus part du temps. quoi mais pas funktioniert ist z.B.:
wert% = readini$()...
wert% hat chez mir ensuite toujours den wert 0, égal quoi je aus qui Ini auslesen. Gleiches chez substr$ etc. Hat mich dans qui Vergangenheit mehrfach Kopfzerbrechen bereitet. maintenant pas plus, weil je es sais. mais es devrait doch possible son, dass aussi ici une automatische Konvertierung stattfindet.

XProfan 9.1; XP SP2; FF; Editpad

30.03.2006 ▲

Jac
de
Lad

Dadurch serait chacun Aufruf einer Funktion très viel langsamer volonté! (Schätze je jedenfalls.) je crois pas, dass sich qui Aufwand lohnen serait, es sei car, qui Compiler serait anhand des Variablentyps erkennen, si un Val() ou bien un Str$() vorangesetzt volonté devrait et ca ensuite automatisch 1faire. Hm, eigentlich aucun schlechte concept!!!

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-part:36a8e59522=Michael Wodrich]..., solange on un objet pas à une LongInt zuweisen peux.[/quote-part:36a8e59522]
quoi maintenant déjà funktioniert:

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

quoi aussi (encore) funktioniert:

MeinLong& = MeinObjekt#: aussi ici wird qui Adresse des Objekte qui Long-Variablen zugewiesen. cet variante wird mais möglicherweise pour Objekte dans XProfan 10 pas plus marcher. qui variante avec Addr bleibt cependant conservé.

quoi Dir alors probablement fehlt, ist qui Possibilité einem anderen objet (possible qui gleichen super) cet Adresse zuzuweisen. je denke derzeit sur un SetAddr(MeinAnderesObjekt#, mon Long&)* après.

Salut
Roland

* (Genaue Syntax encore sans chacun Gewähr)

EDIT: dans XProfan 9.1 funktioniert aussi MeinObjekt# = MeinLong&. (dans qui Subscriptionsversion de XProfan 10 derzeit allerdings pas. c'est allerdings plutôt un 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-part:0aeb9ca536=Jacob Liebeck]
Erweiterte Variablen wären äußerst bien. alors Int64 et 64Bit-FLoat!
Jac

[/quote-part:0aeb9ca536]
qui Float-Variablen entsprechen bereits dem Typ Double dans C++ ou bien Delphi, sommes alors 64Bit (8 Byte) breit!

Salut
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...je mon 64Bit-Int et 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 alors DoubleLongs ou bien LongLongs

halte je aussi pour important. avant allem beim travailler avec dem Dateisystem sommes sonst Fichiers > 2 GB seulement schwierig > 4 GB seulement très schwierig trop Travailler

RGH

[quote-part:098d09f434=Jacob Liebeck]Dadurch serait chacun Aufruf einer Funktion très viel langsamer volonté! (Schätze je jedenfalls.)Jac

[/quote-part:098d09f434]
Viel langsamer pas, mais un peu langsamer doch. quelquefois wünschte je, je hätte avec cette automatischen Umwandlungen nie angefangen et serait quelque chose plus qui Strenge de Pascal bzw. Delphi walten laisser. Manche Teile des XProfan-Codes wären ensuite übersichtlicher (et avec cela aussi stabiler) et möglicherweise sogar plus rapide.

Salut
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-part:32c676fda1=iF]iF schrieb: je wünsche mir pour XProfan10:
a) Startpaint

-1 nécessaire ne...aucune %hwnd plus, et/ou bien
b) %hwnd

(Hauptfenster) peux erzeugt volonté sans dans qui Taskbar trop erscheinen
c) clearlist

avec Handle comme paramètre löscht Listboxinhalt .[/quote-part:32c676fda1]
a) Début de peinture -1 hat encore nie un %HWnd nécessaire! ;) Ok, es funktionierte mais seulement sinnvoll, si es une Memorybitmap donnais. Um cet trop erstellen nécessaire on qui Befehle MCLS ou bien MLOADBMP. cet beiden setzten un Hauptfenster (%HWnd) vorraus. Ab qui prochain Subscriptionslieferung ca va aussi sans.

b) gibt es oui déjà dans XProfan 9.1

c) Ab qui prochain Subscriptionslieferung peux dem Befehl CLEARLIST cela Handle einer Listbox ou bien Choicebox folgen et cet wird gelöscht.

dans diesem Zusammenhang marcher alle Listboxfunktionen (AddString

et SelectString

) eh bien aussi pour Choiceboxen. qui Funktionen AddChoice, DeleteChoice et MoveListToChoice entfallen daher, volonté vom Interpreter et Compiler mais encore erkannt et entsprechend umgewandelt.

avec ClassOf

([B#|N&]) peux eh bien aussi qui Klassenname une Windowsklasse ermittelt volonté, si qui paramètre aucun Bereichsvariable, mais un Handle trop einem Fensterobjekt ist. So peux alors z.B. ermittelt volonté, si un Handle trop einer Auswahlbox, einem Button ou bien einem Modifier le champ de est.

je hoffe, qui qui prochain Subscriptionslieferung aujourd'hui encore rausgeht.

Salut
Roland

EDIT: MoveListToList

, MoveListToChoice

et MoveListToEdit

volonté trop MoveListToHandle zusammengefaßt. XProfan erkennt ensuite aufgrund qui Fensterklasse des Handles, òu gemoved wird. Aussi gibt es eh bien aussi qui Umkehrfunktion: MoveHandleToList, avec qui qui Zeilen qui List-, sélection- ou bien Multieditbox qui Listboxliste hinzugefügt volonté. qui bisherigen Funktionen volonté aussi ici vom Cpiler et Interpreter erkannt et 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 ▲