[Allegro] DFT Startverzeichnis

[Thomas Berger]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Liebe Frau Moehring, liebe Frau Panski,

> die DFT von vorhin war ja eigentlich nur eine ganz normale Frage,
> deshalb kommt jetzt noch eine vielleicht ganz blöde (gern auch morgen
> zu beantworten):

[Fragen zur Netzwerkadministation sind eigentlich auch nie DFT's ...]


> Unser Datenbankverzeichnis ist hier:
> 
> L:\allegro\kg
> 
> Im Datenbankverzeichnis befindet sich eine kg.frm
> 
>  
> 
> Jetzt würden wir gern mehrere Formulardateien für verschiedene
> Benutzer entwerfen. Da wurde immer gesagt, dass das möglich wäre, wenn
> man sie ins Startverzeichnis des Benutzers legt.

... und wenn keine im Datenverzeichnis liegt. Ich halte das (= wichtige
Dateien nicht auf dem Netz, sondern verteilt ueber Benutzer-PC's oder
Benutzer-Profile) fuer keinen guten Ansatz. (Besserer Vorschlag unten)



> Verknüpfung auf dem Desktop eines Benutzers sieht z.Zt. z.B. so aus:
> 
> L:\allegro\a99.exe L:\allegro\a99h.ini
> 
>  
> 
> Wo ist das Startverzeichnis für einen einzelnen Benutzer? Wie muss
> dann die Verknüpfung aussehen? Wo sollten dann welche Dateien liegen?

Falls in der Verknuepfung nichts eingetragen ist, ist das
Startverzeichnis dasjenige, in dem das aufgerufene Executable liegt,
also L:\allegro. Wenn dem so ist, ist es fatal, weil sich dann
Benutzer "private" Dateien gegenseitig ueberschreiben, und "private"
Dateien im allegro-Programmverzeichnis sowieso nichts zu suchen haben.
(Das ist u.U. sogar gegen normale Benutzer schreibgeschuetzt)
[Diese Situation ist allerdings nicht ganz so fatal wie zu DOS/Cockpit-
Zeiten, weil viele "private" Dateien inzwischen ins TEMP-Verzeichnis
gehen und nicht mehr ins Arbeitsverzeichnis]

Vorschlag an die allegro-Entwicklungsabteilung: Wenn a99 beim Start
merkt, dass das Arbeitsverzeichnis gleich dem Programmverzeichnis
ist, dann sollte a99 von sich aus das TEMP-Verzeichnis zum
Arbeitsverzeichnis machen...


Hier der Vorschlag fuer benutzerspezifische Formulardateien:

Im Datenverzeichnis liegt ein stark abgespecktes <dbname>.frm
Der _start.flx laedt nun Formulare dazu, die liegen im
Programmverzeichnis, weil .frm-Dateien doch nicht so eine einfache
Syntax haben, dass Fehler unmoeglich sind und a99 sehr ungnaedig
auf Syntaxfehler in Formularen reagiert, die Formulare sind also
moeglichst nicht durch die Benutzer selbst pflegbar:


var P #op ".frm"
fsize
if no jump allg
var P #op ".frm"
addform
jump done

:allg
var P "allg.frm"
addform

:done

(Es wird also <benutzername>.frm im Programmverzeichnis dazu
geladen, existiert die nicht, wird allg.frm geladen). Vorausgesetzt
ist, dass ein sinnvoller Benutzername in #op steht, das geht
ueber die .ini-Datei, besser natuerlich ueber den "Password"-
Mechanismus. Fuer Benutzer von Alf oder Order ist der typischerweise
aktiviert, ansonsten gibt es die "Billig-Variante", die beim Start
von a99 den Windows-Benutzernamen als #op einstellt (erfordert
Windows NT oder besser, unter Windows '9x kommt man nicht dran):

- --%<-schnipp----
 // Umgebungsvariable USERNAME als a99-Operator einstellen
 // Dieser Flex ist aktiv, wenn er als _psw.flx im DbDir liegt
get env USERNAME
ins #uwN
var #uwN "=egal"
ins #uwN
- --%<-schnapp----

Die Frage ist allerdings, ob sich der Aufwand lohnt: Formulare
wollen gepflegt sein, und besonders frei ist man in der
Formulargestaltung sowieso nicht, weil der Input- und Onforms-
Mechanismus darauf beruhen, dass bestimmte Formulare mit
bestimmten Namen existieren.

Ein haeufiges Problem sind eigentlich, dass bestimmte Benutzer
bestimmte Standardvorgaben in Datensaetzen benoetigen, das
kann man aber eleganter durch personalisierte Kategorieladungen
im onput.flx regeln.


viele Gruesse
Thomas Berger

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3-nr1 (Windows XP)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHMEYchKFJT0F1FsoRAuXTAJ9yDGwZcqP08aTl76yZdilo5+il9ACdGfNg
F6oLq+LW1ywVfvN6DD0fEuU=
=NSUB
-----END PGP SIGNATURE-----