Infinity-Profan

Kompilieren Markieren Separieren

H.Brill

var h=createmenu("left","bottom")

Wäre es da nicht besser, die Konstanten
left, right, top und bottom OHNE " " zu
implementieren ?
Kompilieren Markieren Separieren

var h=createmenu(left,bottom)

Die " würde ich an deiner Stelle ausschließlich
den Stringliteralen bzw. Stringvariablen zuordnen.
Es potuto ja mal durchaus sein, daß man mit
den Konstanten rechnen will :
z.B. : left + 10
das dann das Menü 10 Pixel neben dem linken
Rand plaziert.

Ich glaube, das führt sonst früher oder später zu
Verwirrungen.

Benutze XPROFAN X3 + FREEPROFAN
Wir sind die XProfaner.
Sie werden von uns assimiliert.
Widerstand ist zwecklos!
Wir werden alle ihre Funktionen und Algorithmen den unseren hinzufügen.

Was die Borg können, können wir schon lange.

Tatsächlich wirds eine menge Konstanden geben, schau mal am Beispiel arr: [...]

1: sortiert das Array numerisch
2: sortiert das Array alphanumerisch
3: kehrt die Reihenfolge der Elemente um (reverse)

Da wird man dann auch schreiben können:

a=arr(arr.sortnum,[10,30,20])

oder

a=arr(arr.sort,[10,30,20])

oder

a=arr(arr.reverse,[10,30,20])

Oder am Beispiel fattr: [...]

0: Dimensione der File oder -1 wenn nicht existiert oder -2 wenn Verzeichnis (selbe wie fattr(datei))
1: File oder Verzeichnis existiert
2: ist eine File
3: ist ein Verzeichnis
4: ist "versteckt"/ hidden
5: ist lesbar, Ausleserecht
6: ist beschreibbar, Beschreiberecht
7: ist ausführbar, Ausführungsrecht
8: Zeitpunkt letzte Cambiamento als Unixzeitstempel

Wirds dann geben:

fattr(fattr.exists,"datei")
fattr(fattr.isfile,"datei")
.isdir
.hidden
.canread
.canwrite
.canexecute
.lastmodified

Insofern wäre es dann auch:

createmenu(createmenu.left,createmenu.top)...

aber bei CreateMenu bin ich mir sowieso noch nicht ganz sicher obs denn so heißen soll. Da bin ich quasi noch nicht angekommen.

Da wandelt Roland ja intern um.
Würde ich auch nie so per meine Programme
verwenden. Ich halte mich da lieber an die
Konventionen der Datentypen und verwende
sie auch dementsprechend.

Mag zwar hilfreich per absolute Einsteiger sein,
aber man sollte dennoch von Anfang an den
richtigen Umgang mit den Datentypen lernen.

H.Brill

Danke per die Info.
War noch nie so mein Ding, daß auch
sowas mit Profan geht. Da graust es mich
sogar als alter DOS-Programmierer :
Kompilieren Markieren Separieren

Cls
Declare String wert
wert = "80"
Def $zahl "5"
Print "10" + 10
Print $zahl + 15
Print wert - 60
Waitkey
a>

AndroidProfan macht es etwas anders,
hat imho aber auch eine komplexere Betrachtung der Variablen denn deren Typ darf sich ständig ändern.

So kannst Du da:

var a="10"
//hier ist a string
a=5.5
//hier float

bei print 10+"20"
kommt 1020 raus,
ebenso bei print "10"+20,
bei print 10+20 naturalmente 30

So gesehen wandle ich nichts um sondern hebe auf den kleinstmöglichen Typ in der Reihenfolge:

null
bool
long
float
string
array

Darum ist dies auch eine Fließkommazahl:

print 5+10.5

istgleich 15.5

und dies aber eine Fließkommazahl plus String

print 5+10.5+"test"

istgleich 15.5test

Und dies:

5+10.5+"test"+10+3.3

ergibt:

15.5test103.3

Versuche also von links nach rechts den Typ kleinstmöglich zu halten.

E.T.

5+10.5+"test"+10+3.3
ergibt:
15.5test103.3

Und warum nicht 15.5test13.3 ??

XProfan X2
Grüße aus Sachsen... Mario
WinXP, Win7 (64 Bit),Win8(.1),Win10, Win 11, Profan 6 - X4, XPSE, und 'nen schwarzes, blinkendes Dingens, wo ich das alles reinschütte...

HofK

Test ist erster string von links, ab da string

XProfan 11

@E.T: Weil "test"+10 "test10" ergibt und "test10"+3.3 ergibt "test103.3". Es wäre imho nicht richtig wenn ich mal von links und mal von rechts rechne.

Ich schätze ich habe mir jetzt ein tolles Konzept per die Positionierung, Anordnung und Ordnung von Controls und per das "Bildschirm-Design" einfallen lassen.

Meine Idee: "The Grid", das Raster! (Klar, Tron...): Man erzeugt ein Raster-Control mit beliebig vielen Zeilen und Spalten und kann Raster-Controls wiederum auch in Raster-Zellen erzeugen und jede Raster-Zelle hat eine eigene "Gravity".

Man stelle sich z.B. ein 9er Raster vor:

XXX
XXX
XXX

Jedes X steht per eine Raster-Zelle.

Möchte man nun ein Design das z.B. den Bildschirm vertikal teilt und oben aber 3 Buttons dann erzeugt man ein Raster 1x2 und in Raster-Zelle 1 erzeugt man ein Raster 3x1 - ergibt:

XXX
.......
------
.......
.......

Die Gravitation einzelner Zellen wird zunächst automatisch bestimmt und kann auch manuell modifiziert werden. Die Gravitation einer Raster-Zelle wirkt sich horizontal und vertikal aus, z.B. LinksOben, MitteOben, RechtsOben, LinksMitte, MitteMitte, RechtsMitte, LinksUnten, MitteUnten, RechtsUnten.

So erzeugt man ein 3x3 Raster auf hwnd und speichert sein Handle in die Variable mygrid:
Kompilieren Markieren Separieren

var mygrid=gui(gui.add,gui.grid,gui.hwnd,[3,3])

Hierbei wird ein 3x3 Raster auf hwnd erzeugt, alle Raster-Zellen sind gleich grande und das Raster hat die Dimensione vom Parent (hwnd) - füllt also den Bildschirm aus.

Solch Raster selbst sind unsichtbar und deren Dimensione ist nicht manuell änderbar sondern deren Dimensione ergibt sich immer aus den Maßen der Eltern-Raster-Zelle.

Jede einzelne Raster-Zelle besitzt ebenso ein Handle. So hat die erste Raster-Zelle vom Raster mygrid das Handle mygrid+1, die letzte Raster-Zelle vom o.g. Raster hat das Handle mygrid+9.

Nun kann man naturalmente auch in einer Raster-Zelle ein weiteres "Unterraster" erzeugen, z.B. ein Unterraster in Zelle 2 erzeugen das selbst aber nur 2 Spalten besitzt:
Kompilieren Markieren Separieren

var myundergrid=gui(gui.add,gui.grid,mygrid+2,2)

Natürlich kann man auch die Maße einer Rasterzelle selbst bestimmen, sieht dann z.B. so aus:
Kompilieren Markieren Separieren

gui(gui.mod,gui.width,mygrid+1,300)

setzt die Breite von Rasterzelle 1 vom Raster mygrid auf 300 Pixel.

Das Konzept erlaubt mir eine automatische Anpassung auch bei Bildschirmrotation damit das Layout immer konsistent bleibt und es ermöglicht dem Programmierer ein einfaches Erstellen beliebig komplexer Layouts ohne auf jede Bildschirmauflösung reagieren zu müssen.

Di più zum Thema schreibe ich dann bei der Funktionserklärung zur Funktion gui.

HofK

Scheint mir ein sehr praktikabler Ansatz.

iF (24.01.15)

Jede einzelne Raster-Zelle besitzt ebenso ein Handle. So hat die erste Raster-Zelle vom Raster mygrid das Handle mygrid+1, die letzte Raster-Zelle vom o.g. Raster hat das Handle mygrid+9.

Bei etwas größeren Verschachtelungen kommt man eventuell mit den Inizes durcheinander. Könnte man nicht eventuell auch die Notation mygrid+11, mygrid+12, mygrid+13, mygrid+21, ... , mygrid+33 nutzen und intern auf 1,... 9 umrechnen?

XProfan 11

Es gibt einen Trick den ich dafür eingebaut habe: Als Array-Angabe. So kannst Du statt mygrid+9 auch angeben: [mygrid,3] In diesem Fall rechnet das System per dich die Rasterzellennummer aus. (grid+y*yy+x)

Habe mich per diesen Sonderfall bewusst gegen [mygrid,2] per Position 9 entschieden (also nicht bei 0 beginnend) da diese Schreibweise ja eben ausschließlich per die Übersichtlichkeit gedacht ist.

Das tolle bei Android ist dass man die Customcontrols relativ einfach (nicht so kompliziert wie bei Windows circa Subclassing) optisch anpassen kann, also alles kann ein Hintergrundbild besitzen/ Schriftfarbe etc blabla. Da werde ich schöne gui(gui.mod,gui.*'s herstellen können und sogar Schatten sind drin etc.