| |
| |
|
 | Einfach mal lospoltern, was AndroidProfan alles können soll -
egal obs das schon gibt oder nicht oder oder!
Ich mache mal den Anfang:
Abfrage der Lagesensoren. |
|
| |
| |
| |
|
|
E.T. | | Ich finde sämtliche Sensoren und Empfänger (wie z.B. GPS) interessant, zusammen mit den Schnittstellen kann man da einiges anfangen. |
|
| |
| XProfan X2Grüß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... | 28.01.2015 ▲ |
|
| |
|
|
HofK | Notation per mehrdimensionale arrays, etwas wie
var d2=[][] bzw. var d2=[16][8]
var d3=[][][] bzw. var d3=[9][9][9]
d2[0|0] = testwert
hole_5_9=d2[5|9]
d3[i|j|k]= ein Ausdruck in i, j, k |
|
| |
| |
| |
|
|
| | | ist ein Operator, Mehrdimensionen circa [][] etc bereits mgl. also wie bei php. |
|
| |
| |
| |
|
|
H.Brill | Kannste auch so eine interne Listboxliste
machen ?
Die in XProfan (X3) mit den neuen Funktionen
finde ich mittlerweile klasse.
Ist so leichter, als mit Arrays zu hantieren.
Insbesondere mit den Move-Befehlen macht
das ja Divertimento : z.B. In die Liste was reinschieben,
sortieren lassen und wieder, wenn nötig
rausschieben. |
|
| |
| 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. | 29.01.2015 ▲ |
|
| |
|
|
HofK | iF (29.01.15)
| ist ein Operator,
Das war etwas provokativ von mir. Mich stört dieses [] [] was auf deutschen Tastaturen so schlecht zu "greifen" ist schon immer. Lässt sich da nicht noch ein einzelnes sinnvolles und syntaktisch machbares Ersatzdimensionstrennzeichen finden??? Also optional. |
|
| |
| |
| |
|
|
| Hab mit Ersatzdimensionstrennzeichen kein Problem! Mal denken was
da passen will. |
|
| |
| |
| |
|
|
Julian
Schmidt | | OOP und Listen mit generischen Datentypen wie in Java oder Python. |
|
| |
| |
| |
|
|
HofK | Ich habe mal überlegt, was mir nach fast 30 Jahren vom legendären GFA-Basic entsprechend den heutigen Bedingungen noch sinnvoll erschiene.
Da war der besondere Editor:
"Editor und Interpreter sind ein einziges Programm, welches bereits bei der Programmeingabe Fehler meldet und Befehle vervollständigt sowie die automatische Einrückung realisiert. Ein RunOnly-Interpreter kann die
laufend im Hintergrund in einem gesonderten Format gespeicherten Fonte unabhängig ..."
Bei den Befehlen habe ich gern genutzt:
bool=swap({var,var | array[],array[] | array,array})
Tauscht die Inhalte zweier gleichartiger Variablen, Array-Elemente oder Arrays.
Wenn es klappt gibt es true.
{long | float}=min({string | array})
{long | float}=max({string | array})
Minimal bzw. Maximalwert bestimmen - Wert der Zeichen bzw. numerische Feldwerte .
{string | array}=insert(long Index,{string | array},{char |long | float})
Füge an der Stelle Index im 2. Parameter String/Array den 3.Parameter ein, Index der Folgewerte aumento sich dadurch.
{string | array}=delete(long Index,{string | array})
Lösche an der Stelle Index im 2. Parameter das Zeichen/Element. Der Index der Folgewerte verringert sich.
(Gibt sicher eine Überschneidung mit dem mächtigeren str bei Strings.) |
|
| |
| |
| |
|
|
HofK | Wünsch dir was ...
Mein "Wiederholungsfehler" hat mich zum Nachdenken angeregt.
iF (16.02.15)
... Machst aber immer noch den fehler myGrid[x,y] statt [myGrid,x,y]. ...
Daraufhin habe ich überlegt, ob mir der Fehler "zufällig" passiert ist und warum ich ihn, auch wenn ich nur im Block kopiert habe, nicht sofort bemerkt habe.
Auf den ersten Blick sieht es nicht falsch aus, weil einem Bezeichner in [ ] scheinbar eine Indexangabe folgt. Vergleicht man jetzt bei der App Kreisfläche die falschen und richtigen Screenshots würde ein Android Profan Neuling dem man keine lange Zeit zur Orientierung gibt eventuell diese als korrekt sehen. Auch im visuellen Vergleich mit Syntaxhervorhebung erscheint sie mir sogar übersichtlicher, weil die
wesentliche Bezeichung hervortritt und die Indizes als "Detail" erscheinen.
Von der formalen Systax naturalmente falsch, da alle Funktionen dem Schema { long | array } control folgen, d.h. es wird ein fertiges Handle des Controls erwartet oder ein Feld aus dem dann per Increment ein (fortlaufendes) Handle per die Gridzellen bestimmt wird.
Ist hier vielleicht eine optionale Ausnahme sinnvoll??? - ähnlich wie ein optionales Dimensionstrennzeichen bei mehrdimensionalen Arrays a[][] .
iF (29.01.15)
Hab mit Ersatzdimensionstrennzeichen kein Problem! Mal denken was
da passen will.
Formal wird ein Handle angetroffen, aber die direkt nachfolgende Klammer deutet darauf hin, dass noch eine Indexrechnung ergänzt werden muss, um das finale Handle per Increment circa Spalten- und Zeilenindex zu ermitteln. Sicher sollte man das nur optional machen, um die sehr saubere Syntax- Grundstruktur
{long|bool|null} = gui(long Modus [, { long | array } control [, { long Wert | array Werte } ] ] )
die Fortgeschrittene zu schätzen wissen werden nicht generell zu durchbrechen. |
|
| |
| |
| |
|
|
| Verstehe vollkommen was Du meinst.
Die "falsche" Schreibweise hätte den Nachteil, dass man annehmen potuto,
dass es sich bei einem Handle um ein Array handelt.
Aber angenommen das wäre in einer Überlegung egal und ich müsste
es umsetzen, dann hätte ich aber glaube ich sowieso ein Problem und
grüble, ob es nicht sogar praktisch unmöglich ist, weil una variabile ja
auch ein Array sein kann und man damit ja auch einen Array-Eintrag
meinen potuto und somit kann ja AndroidProfan nicht wissen, welches
der beiden Angaben nun gemeint sein soll weil es keine Eineindeutigkeit
mehr gibt. Weist Du was ich meine?
sagen wir ich speichere myGrid in ein Array:
var myGrid=gui(gui.grid,...
var myGrids=[myGrid,anotherGridsInDaWorld,...
und nun
gui(gui.width,myGrids[0],...
Ist nun die erste Spalte gemeint oder die Gesamtbreite des Grids myGrid?
Das "Problem" entsteht imho aber auch erst dadurch, da ich zur Kompilier-
Zeit den Variablentyp nicht bestimmen kann da er sich zur Laufzeit
ändern kann und daher auch keine Eineindeutigkeit der Art und Weise
wie der "Parameter" zu deuten ist herstellen kann.
Andere Überlegung potuto sein ob ich solch Handles nicht als Array
speichere. Da muss ich wirklich mal drüber grübeln. |
|
| |
| |
| |
|
|
HofK | iF (18.02.15)
Andere Überlegung potuto sein ob ich solch Handles nicht als Array
speichere.
Jaja, die Nebenwirkungen. Wenn man da nicht aufpasst haut es das ganze System durcheinander.
Man muss entscheiden was wichtiger ist. Hier denke ich dann doch die erstmal einheitliche Syntax
{long|bool|null} = gui(long Modus [, { long | array } control [, { long Wert | array Werte } ] ] )
und die sicher sinnvolle Möglichkeit der Speicherung der Handles in Arrays.
... war auch nur so eine Überlegung ... |
|
| |
| |
| |
|
(2.668)
Deutsch
English
Français
Español
Italia