AW: AW: [Allegro] V30 am Zeithorizont

[Thomas Fischer]

Hallo Herr Eversberg,

> > 1. Benutzeroberfläche
> > - Es wäre schön, wenn Standardtastenbefehle wie STRG-A, -C, -V, -X 
> > oder Standardverfahren wie Doppelklick in allen Feldern von A99 
> > funktionieren würden, wo dies sinnvoll ist. STRG-A 
> funktioniert z.B. 
> > nicht im Bearbeitungsfeld, Doppelklick nicht im Anzeigefeld.
> Wo's geht, ist's eingerichtet, wo nicht, da nicht.

Hm. Und alle anderen Programme können das, nur A99 nicht?
 
> > - Die Tasten von A99 sollten ihre Funktion dauerhaft 
> behalten, bei mir 
> > verschwindet sie immer nach einiger Zeit, bis ich sie mit 
> "X _start" 
> > wieder reaktiviere.
> Was verschwindet - die Belegung der Flip-Buttons? Das liegt 
> dann nur an den Inhalten der Variablen #uXi (i=0-9). Wenn man 
> die in eigenen FLEXen für sonstwas verwendet - tja. Oder 
> meinen Sie Phrasenbelegungen?

Die Belegung der Flip-Tasten. Und ich benutze normalerweise keine Flexe und
schon gar nicht die Variablen #uXi.
Es sind auch immer alle Belegungen auf einmal weg.

> > - Ein größeres Eingabefeld wäre oft hilfreich.
> Das gibts mit dem Befehl B. Geben Sie mal B81, wenn Sie eine längliche
> #81 bearbeiten wollen.

Ich habe in Engabefeld bei einem entsprechenden Datensatz B87 ins
Eingabefeld geschrieben und mit Return abgeschickt.
Darauf is A99 abgestürzt.

> > - Die Menüs sind für mich immer wieder verwirrend, nicht nur die 
> > "Pseudomenüs" wir Löschen oder Füllhorn, sondern auch die 
> Suche nach 
> > einzelnen Einträgen (Wo finde ich die bearbeiteten 
> Datensätze?). Für 
> > Ein- und Ausschalten einer Anzeige werden normalerweise nicht zwei 
> > Menüeinträge benützt.
> Hilfe bietet  h menu
> Über begründete Einzelheiten kann man immer noch reden.

Ich kann noch einmal genauer nachsehen, was mich verwirrt.

> > - Diverse Kleinigkeiten in der Benutzerführung. Z.B. kommt 
> nach einer 
> > globalen Ersetzung die Meldung, dass die Datensätze noch nicht 
> > gespeichert sind. Hier wäre ein Knopf mit der Möglichkeit 
> "Jetzt speichern" hilfreich.
> Gut, das wird geprüft.

Schön.

> > - Bei allen längeren Operationen (z.B. beim Speichern) 
> sollte es eine 
> > visuelle Rückmeldung geben und A99 sich nicht wie 
> eingefroren verhalten.
> > 
> Wo's geht, ist das meistens so eingerichtet, aber es geht 
> auch nicht immer.

Es muss!

> > 2. Zeichensatzoptionen
> > - Konfigurationsunabhängige Tabellen (Zeichenersetzungen 
> etc.) sollten 
> > vom Konfigurationsbuchstaben unabhängig sein.
>  > - Da diese nur von der internen Kodierung der Datenbank 
> und eventuell  > von Eingabemedien abhängen, sollte dafür 
> eine entsprechende Konvention  > gefunden werden.
> 
> Kein schlechter Gedanke, wird geprüft.
> 
> > - Die Möglichkeiten der internen und externen Repräsentation von 
> > Zeichensätzen sollten neu durchdacht und beschrieben werden 
> (also z.B.
> > OSTWEST-Ansi, OSTWEST-ASCII, ASCII (CP437), Latin-1/ISO 8859-1, 
> > Windows CP1252, UTF-8, UTF-16?, Unicode?)
> Was genau meinen Sie damit?

Dass es derzeit ziemlich unübersichtlich ist, sich durch die verschiedenen
(De-) Kodiertabellen durchzuarbeiten o-, p-, q-, U-Tabellen etc. Vielleicht
ließe sich ein einfacheres Konzept finden, wenn man unvoreingenommen
daraufschaut. 

> > - A99 sollte mit Unicode/UTF-8 in Registeranzeige und Bearbeitung 
> > umgehen können (Anzeige geht ja jetzt schon).
> > 
> Sorry, sehr sehr schwierig.

Aber lohnend!
 
> > 3. Programmierung
> > In der Exportsprache ist eine der größten Hürden die 
> > "unkonventionelle" Art des Umgangs mit Unterprogrammen.
> > Ich würde z.B. bei der Ausgabe gerne ein Datenfeld 
> umwandeln und davor 
> > und dahinter einige Zeichen ausgeben:
> > #92 x'<#91' p{' (revised '} >D P{')'}
> > da geht so aber nicht, weil Unterprogrammaufrufe nie zurückkehren.

> Nicht nie, sondern immer kehren sie zurück.

Aber nicht in derselben Zeile; Herr Berger meinte einmal, dass ">D" mit
"P>D" identisch ist, das passt zu meinen Erfahrungen.

> Übersichtlicher ist, mehrere Zeilen zu machen:
> #91 P{ ... } e0
> #91 >D
> #91 P{ ... } e0

Ja, dann muss man aber in jeder(?) Zeile noch etwaige Standardendungen mit
"#zz 0" deaktivieren .
Und wenn man das auf einer Zeile als
 #92 p{' (revised '} >D P{')'}
hätte, oder statt p oder P mit einer direkten Ausgabe, etwa
#92 ' (revised ' >D ')'
so würde das überschaubarer bleiben.
Wie sich die Effizienz  eines einfachen zu einem dreifachen Aufruf
vergleicht weiß ich nicht.

> > Erleichternd wäre auch, wenn die Befehle in einer Zeile weitgehend 
> > (also mit Ausnahme der explizit es Endoperationen gekennzeichneten 
> > Befehle wie p{} und P{}) sukzessive abgearbeitet würden.
> Von der Logik her nicht konsequent machbar. Außerdem würden 
> bei einer solchen Änderung zahlreiche Parameter nicht mehr 
> korrekt arbeiten.

Ja, das ist zum Teil ein Problem: Wie einerseits ändern und andererseits
alles Alte funktionsfähig halten.
Vielleicht wäre da auch einmal ein Schnitt zu prüfen.
Ich weiß nicht, wie viele Leute mit "selbstgestrickten" Parametern wie wir
arbeiten. Die Standardparameter an neue Konventionen anzupassen und
entsprechend auszutauschen sollte keine Problem sein.
Ein Beispiel für Herrn Berger: der U-Befehl wird unabhängig von seiner
Position zuletzt angewandt, verträgt also kein p'...'.

Mit freundlichen Grüßen
Thomas Fischer