[Allegro] A30: Speicherprobleme und Schriftgroesse nicht stabil

[Sibylle Koczian]

Lieber Herr Eversberg,

Bernhard Eversberg schrieb:
> Sibylle Koczian schrieb:
>>
>> Die Datenbank hat eine eigene Konfiguration und macht reichlich 
>> Gebrauch von Teilfeldern. Der datenbankinterne Zeichensatz ist ASCII, 
>> das Teilfeld-Kennzeichen ist ASCII-31 (das Dreieck).
>>
>> Ich suche einen Satz, ändere den Inhalt _eines_ Teilfeldes und 
>> speichere (direkt im Tab Intern). Danach sehe ich in der 
>> Intern-Anzeige _jede_ Kategorie, die Teilfelder enthält, in zwei 
>> Ausführungen: die unveränderte, alte Version und eine Version mit Γû╝ 
>> (hex e2 96 bc) an Stelle des Teilfeldkennzeichens; diese Version 
>> enthält meine Änderung. Und so ist der Satz jetzt auch wirklich in der 
>> Datenbank, ich habe in die .vld-Datei geschaut.
>>
> a30 erwartet einen Datenstrom aus UTF-8 Codes. Das stellt man sicher
> durch Einbezug der Tabelle ad-utf.apt in die Exportparameter.
> a30 sendet auch UTF-8 zurück. acon verwendet dann "xcode u" bzw.
> "set U2" (in a30put.php) für die Rückwandlung in ASCII, braucht dazu
> aber die Tabelle ucodes.apt, eingebettet in die Indexparameter - das ist
> wohl bei Ihnen nicht gegeben.
> 

So war es, das ist erledigt, besten Dank. In meine Indexparameter sind 
jetzt eingebettet: swl1, i, o, ucodes. Ist da was zu viel, ist die 
Reihenfolge vernünftig?

Zusatzfrage: wenn im Allegro-Paket sowieso schon eine Datei xxx. at pt 
vorhanden ist, ist es sicher besser, sich _keine_ eigene Kopie mit 
eigenem Konfigurationsbuchstaben ins Datenverzeichnis zu legen. Richtig? 
Was ist geschickter, wenn es so eine Datei noch nicht gibt? Die xxx.apt 
im Programmverzeichnis auf xxx. at pt zu kopieren oder ins eigene 
Datenverzeichnis? Beides bringt das Risiko mit sich, eine Verbesserung 
zu verpassen, wo ist das Risiko größer?

>> Zwei andere Dinge passieren auch in der Demo-Datenbank, allerdings 
>> nicht sicher reproduzierbar: nachdem ich bei einem Satz auf einen der 
>> Schalter "Form" oder "Grid" gedrückt habe, sind die 
>> "Speichern"-Schalter für diesen Satz ausgegraut, in allen drei Tabs 
>> (Intern, Form, Grid). Speichern geht erst wieder, wenn ich einen 
>> anderen Satz aufrufe und dann zum Ausgangssatz zurückkehre (was in der 
>> Zwischenzeit aus einer evtl. ungespeicherten Änderung wird, habe ich 
>> nicht untersucht). Das passiert meistens, aber nicht immer.
>>
> Im Datenstrom muß sich ein Befehl  _!_ACC 3  befinden, damit die
> Speicherbuttons geschärft werden. Die Standardskripte verlangen dazu
> einen Authentifiziervorgang. Wie das geht, steht in der Doku:
> http://www.allegro-c.de/doku/a30/#sicher
> und ist beispielhaft zu sehen z.B. in a30gri.job

Ich habe '$Ident = "no";' in der a30_ini.php stehen und dachte, dann 
müsste das Speichern auch ohne Authentifizierung möglich sein. Und oft 
klappt es ja auch. In der Intern-Anzeige, vor einem Klick auf "Form" 
oder "Grid", geht es eigentlich immer glatt.

> 
>> Und manchmal ändert sich nach Versuchen mit Speichern, Form und Grid 
>> die Schrift der externen Anzeige (sie wird größer und in der 
>> Demo-Datenbank kann sie auch blau werden). Da habe ich noch nicht viel 
>> herumprobiert, weil ich absolut nicht weiß, wie ich anfangen könnte - 
>> und weil die anderen Probleme dringlicher sind. Schnaps in den 
>> Bildschirm gegossen habe ich jedenfalls nicht.
> Solcherlei Abhilfe haben wir auch noch nicht versucht, aber auch sonst
> wissen wir dagegen momentan keinen konkreten Rat. Es muß mit der extrem
> begrenzten und zickigen HTML-Implementierung in Flash zu tun haben. Wir
> wollen bald mal Flash4 testen, nachdem es aus dem Betastadium heraus ist.
> 

Als Abhilfe wollte ich das auch nicht darstellen, nur kundtun, dass ich 
nicht auf diese Weise die Blaufärbung verursacht habe.

Bis zum nächsten Problem,
Koczian