| |
| |
|
| - Page 1 - |
|
 | 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. |
|
| |
| |
| |
|
| |
| |
| - Page 4 - |
|
|
| Ah, zum Glück.
Ich mache mich langsam in die Session-Schnittstelle und Projekte-Verwaltung
sodass ich dann den Kompilierer einklinken kann. |
|
| |
| |
| |
|
|
HofK | | ... und ich kämpfe weiter mit den regulären Ausdrücken - mächtiger Gegner! ... bügele ab und zu die mode-autohotkey.js circa, sollte keine Probleme geben |
|
| |
| |
| |
|
|
HofK | Idee
Bisher habe ich das { } Klammerpaar in AndroidProfan nur in der Metasprache gesichtet, z.B.
{long|bool|null} = gui(long Modus [, { long | array } control [, { long Wert | array Werte } ] ] ) Oder?
Ist es eventuell schon reserviert?
Wenn nicht, potuto man damit beliebige Codeabschnitte im Editor falten und ist nicht an irgendwelche "Blöcke" gebunden. Natürlich nur, wenn der Compiler es vorverdauen kann.
Mit der Faltung von proc und Konsorten sieht es noch ziemlich düster aus.
Das ist ein ganz anderes Ding. Fasse den Stand demnächst zusammen. |
|
| |
| |
| |
|
|
| { und } sind noch nicht belegt und wären leicht verdaulich,
dann würde aber die Faltung die Basicsyntax verballern.
Ich persönlich würde also lieber auf die Faltung verzichten,
das können wir auch später einmal einbauen. |
|
| |
| |
| |
|
|
HofK | Stimmt, ist per Anfänger hochgefährlich. Aber auch Experten tappen gern daneben. Sollte man vielleicht wirklich besser lassen. Und wenn nicht sofort, irgendwie muss die Faltung proc usw. nochmal zu knacken sein.
... Stand demnächst ... |
|
| |
| |
| |
|
|
HofK | Punkt-Konstanten Modus
Erst wenn man daran arbeitet merkt man wo es eventuell noch klemmt.
Bei msg fiel mir auf, dass die Konstanten noch nicht benannt sind.
msg 0, "Endlich per Android programmieren!" ist (nicht nur) per den Anfänger nicht so schön wie
z.B. msg msg.box, "Endlich per Android programmieren!" und die Konsistenz (z.B. gui, display ...) wäre gewährleistet. |
|
| |
| |
| |
|
|
| Richtig, ich habe noch nicht alle Konstanten implementiert,
das kann ich auch nur Stück per Stück und zwar immer dann,
wenn ich ein Stück in der Sprache weiter voran komme.
Es ist der doch sehr kurzen Entwicklungszeit geschuldet.
Übrigens, Du kannst ja auch die Referenz bearbeiten und einfach
solch Konstanten nachtragen und dann im jewl. Thema ein Post
absetzen. Ich würde die dann fix übernehmen. |
|
| |
| |
| |
|
|
HofK | Beim AndroiProfan codehämmern dachte ich zwischenzeitlich ich stottere.
display display.rotation, display.rotation.left
gui gui.grid, gui.hwnd, [2,3]
??? Kann man eventuell problemlos eine optionale Kurzsyntax einbauen:
display rotation, left
gui grid, hwnd, [2,3]
??? Es wir der Funktionsname display geparst, dann wird eine Konstante erwartet. Sind alle Konstantendefinitionen"flach" abgelegt müsste display. vor rotation ergänzt werden um die Konstante zu ermitteln. Ebenso bei dem erwarteten Wert ...left. Sind die Konstanten intern nach Funktionen gegliedert wird es noch einfacher.
Insgesamt wären aber identische Bestandteile wie .off .on kein Problem.
Das Kreisprogramm wäre dann genial übersichtlich. Einen Vergleich mit Java muss man schon garnicht machen.
Wo ist abgesehen von Aufwand und Zeit eventuell der "Haken".
Klammern nach gui fehlen in Zeilen 7 bis 23, Fehler width ... siehe [...]  vom 08.03.15 |
|
| |
| |
| |
|
|
| Ich verstehe schon was Du meinst aber es gibt da leider ein großes
Aber, denn wir würden sonst per alle diese Konstantennamen gleichnamige
Funktions- und Prozedurennamen sperren und damit würden Sie zum
Befehlssatz gehören und der wäre dann auf einmal nur wegen der Konstanten
riesig grande.
Aber vielleicht ist dies der Weg, dass wir einfach sagen es gibt Konstanten:
top,left,right,sensor,grid,text,textcolor etc blabla. So richtig glücklich stimmt
mich das im Moment aber noch nicht - da grüble ich nochmal drüber -
presumibilmente ist dieser von Dir vorgeschlagene Weg aber der Bessere. |
|
| |
| |
| |
|
|
HofK | Klaus Hoffmeister (01.03.15)
Und wenn nicht sofort, irgendwie muss die Faltung proc usw. nochmal zu knacken sein.
... Stand demnächst ...
Vorläufige Faltungskapitulation
ACE Codefolding ... folding rules can be a little tricky ... schreiben sie hin und das wars!
Im Gegensatz zum Highlighting zeigt sich das Codefolding per eigene Schlüsselworte unnachgiebig. Es gelingt durch Manipulation der Regulären Ausdrücke zwar recht einfach das setzen der Marker, die Funktionalität wir damit aber nicht generiert. Das betrifft Sonderzeichen und Schlüsselworte.
Ganz offensichtlich gibt es bei mode-AutoHotKey Unterschiede zwischen dem Kommentarblock, den Klammern und selbstdefinierten Werten. /* */ z.B in /# #/ zu ändern gelang recht schnell und auch die Faltung konnte erreicht werden. Bei den Klammern waren {} und [] zur Faltung voreingestellt. Es ist leicht possibile noch ( ) hinzuzufügen.
Unklar bleibt die Funktion der zusätzlichen .metaData ...Marker, die keinen Rückschluss erbrachten. Beim Verhalten der Klammern konnte ich keinen Bezug finden.
Zu var FoldMode = require("./folding/cstyle").FoldMode;
war ein Hinweis zu finden, dass offensichtlich der C-Style als Grundlage dient. Das potuto das Verhalten bezüglich der Klammern berühren.
Die File mode-autohotkey (ca. 250 Zeilen) die ich manipuliert habe ist aber nur Teil im Gesamtsystem. Die gut 850 Zeilen siehe [...] bewerkstelligen u.a. sicher die eigentliche Faltung. Eventuell ist noch mehr beteiligt. Um das zu durchschauen, müsste ich testweise ACE in einer eigenen Anwendung installieren und "minimieren" und "auseinanderpflücken" - wenn das überhaupt geht und etwas bringt.
Wer es mal versuchen möchte, hier eine Steilvorlage. Folgende Seiten kann man sich zu Gemüte ziehen. Irgendeine erhellende Anleitung ist nicht dabei - habe auch keine gefunden.
* [...]
* [...]
* [...] // Testseite
* [...]
* [...]
* [...]
* [...] // <-- Quellen html Format
* [...]
* [...]
* [...]
* [...] // Anleitung Installation ace
=
Kleiner Trost: Anderen geht es nicht besser: [...]
Zitat:
"Als Herz des Editors kommt ACE zum Einsatz, dieser wurde um einen neuen Highlighting Modus per Monkey erweitert. Codefolding wäre theoretischer weise possibile, aber da steige ich ganz ehrlich gesagt gerade nicht ganz durch ;o)"
Das bedeutet, ein eigener Modus würde das Problem auch nicht so einfach lösen.
Zum Schluss wird es positiv, per die regulären Ausdrücke kann ich etwas nettes anbieten: [...] |
|
| |
| |
| |
|
|
HofK | iF (06.03.15)
Ich verstehe schon was Du meinst aber es gibt da leider ein großes
Aber, denn wir würden sonst per alle diese Konstantennamen gleichnamige
Funktions- und Prozedurennamen sperren und damit würden Sie zum
Befehlssatz gehören und der wäre dann auf einmal nur wegen der Konstanten
riesig grande.
So auf die Schnelle: Wäre es denkbar einfach immer den Punkt davor zu fordern um den Unterschied zu eigenen Bezeichnern zu haben?
var g_gr = gui .grid, .hwnd, [1,3] // GrundrasterGrid
Ich teste mal die Auswirkung beim Highlight. |
|
| |
| |
| |
|
|
| Ja wäre possibile aber es gefällt mir nicht auch wegen späterem OOP denn
.bla ist per mich sowas wie this->bla oder this::bla - Roland machts ähnlich.
iF (06.03.15)
Aber vielleicht ist dies der Weg, dass wir einfach sagen es gibt Konstanten:
top,left,right,sensor,grid,text,textcolor etc blabla. So richtig glücklich stimmt
mich das im Moment aber noch nicht - da grüble ich nochmal drüber -
presumibilmente ist dieser von Dir vorgeschlagene Weg aber der Bessere.
Ich werde deshalb mal die Konstanten zusammensammeln und
in einer Liste darstellen - vielleicht kommen dann noch andere Ideen.
ACE schien mir bisher kein Kotzbrocken aber wenn ich das mit der
Faltung lese... ich schaue auch mal ob ich da nochmal drüberfliege
und hoffentlich knakts dann! |
|
| |
| |
| |
|
(2.668)
Deutsch
English
Français
Español
Italia