[Allegro] v23 getestet

[Thomas Berger]

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

Lieber Herr Eversberg, liebe Liste,


>> Also: Die Kommunikation mit Janas war schon immer mein Haupteinwand
>> gegen eine sinnvolle Nutzung: Wieder werden irgendwo Dateien mit
>> festem Namen geschrieben, gelesen, zurueckgeschrieben und mit
>> Windows-weiten-Signalen geballert (dabei sitzt janas im gleichen
>> Prozess wie a99, was man schoen daran erkennen kann, dass man janas-
>> Fenster "ausradieren" kann, wenn a99 auf eine Eingabe wartet).
>
> Es ist nicht der gleiche Prozeß wie a99! Man erkennt es daran, daß
> man a99 beenden kann und JanaS läuft weiter. Daher gibt es keinen
> direkten Draht zwischen beiden. (Blick in den Task-Manager zeigt
> ebenfalls, daß da zwei getrennte Prozesse laufen. Ein zweites JanaS-
> Fenster kann aber nicht geöffnet werden, denn a99 prüft zuerst mit
> FindWindow(), einer Win32-Funktion, ob schon eines vorhanden ist.)

Dann ist es also zunaechst einmal eine andere Macke, dass auch
Janas in gewissen Situationen das Neuzeichnen des Fensterinhalts
unterlaesst, wenn man mit anderen Fenstern drueberwischt...

Ich halte es fuer vernuenftig, dass jedes a99 nur ein, zugehoeriges,
Janas-Fenster haben darf. Wirklich schlimm ist aber, dass der
unselige Exflex-Mechanismus zum Einsatz kommt: Druecke ich in Janas
auf "Submit", zappeln alle existierenden a99-Fenster herum und wollen,
dass ich ihnen eine Fehlermeldung quittiere.

Kommunikation zwischen Prozessen erfolgt (m.W. auch unter Windows)
typischerweise ueber Pipes, bidirektionale Kommunikation ueber ein
Paar von Pipes. (Avanti-W 1.x kannte named pipes als eine der
alternativen Ansteuerungsmethoden, fuer den Zweck, dass mehrere
Prozesse Daten an einen Server senden, sind Pipes allerdings nur
eingeschraenkt geeignet).

Im Janas-Fall wuerde a99 also ein Paar von Pipes erzeugen
(repraesentiert durch zwei mal zwei Handles), eine Pipe zur
Kommunikation A->J, die andere fuer J->A. Der Janas-Prozess
bekommt bei der Erzeugung die zwei geoeffneten Handles fuer
seine Seite mitgegeben (Waere Janas nur ein Thread, waere das
sehr simpel, es geht aber auch fuer beliebige Prozesse).

Eine schoene Diskussion der Detailprobeleme habe ich unter
http://www.3rd-evolution.de/tkrammer/docs/apipes.html
ergooglet.

Sowohl a99 als auch Janas beruecksichtigen nun nicht mehr das
Globale Windows-Event, sondern die Tatsache, dass an ihrem
jeweiligen Lese-Ende etwas anliegt, um ihre entsprechenden
Aktionen (Neuaufbau einer HTML-Seite bzw. Ablegen des Formular-
Inhalts) zu starten. Weil tendenziell viele Daten zusammenkommen,
ist dies der Zeitpunkt, wo jeder Prozess fuer sich eine wirklich
temporaere Datei erzeugen kann (das Betriebssystem kennt entsprechende
Funktionen, einen Dateinamen auszuwuerfeln, die Datei zu erzeugen
und zu oeffnen...), in die die Daten zunaechst einmal versenkt
werden, um sie dann in Ruhe wieder auszulesen.


>> Nun ist aber zusaetzlich klar, dass der Weiterverarbeitungsmechanismus
>> a99-seitig so nicht brauchbar ist. Rettung sehe ich eigentlich nur
>> darin, dass die erhaltenen Daten 1:1 in die iV gesetzt werden und
>> der spezifizierte Flex direkten Zugriff darauf hat. Der Aufbau der
>> anzuzeigenden HTML-Seite sollte ebenfalls ohne Zwischendatei
>> erfolgen...
>>
> Beides geht aus dem genannten Grunde nicht. Übermittlung von Daten
> zwischen zwei völlig getrennten Prozessen ist nun mal ein Problem.
> Oder weiß jemand, wie man da eine beliebig lange Zeichenfolge
> direkt überreichen könnte? Das wollten wir dann wohl gern einbauen,
> statt des Umwegs über Dateien.

Das prinzipielle Kommunikationsproblem habe ich oben skizziert, bei
meinem letzten zitierten Absatz ging es v.a. darum, dass ein j.flx
generiert wird, in den die empfangenen Daten eingebettet sind. Das
ist zunaechst einmal wegen Code-Injektion ein Stabilitaets- und
Sicherheitsrisiko, es hat sich aber auch gezeigt, dass hier die
Flexibilitaet nicht gross genug ist: Meine Anwendung hatte anderes
im Sinn als das, was j.flx scheinbar vorbereitet.

Liegen die empfangenen Daten aber "einfach so" in einer Datei (a99
mag beim Einsammeln behutsam de-escapen), dann kann ein Anwender-Flex
sie zeilenweise lesen und wesentlich gezielter weiterverabeiten.

Bleibt das Desiderat (auch fuer Avanti hilfreich), die Umwandlung per
u-Tabelle auch in der iV zu ermoeglichen, die Einschraenkung auf
"echte" Kategorien ist ein ziemlicher Stolperstrick.

Weiter ausgeholt waere noch einmal zu ueberlegen, ob Janas nicht
staerker die Kontrolle ueber a99 uebernehmen koennen sollte, etwa
indem janas-seitiges JavaScript ein Objekt kennt, mit dem die
Kommunikation ueber die Pipe angeleiert wird. Das kaeme vermutlich
Herrn Hoeppners nie veroeffentlichen ActiveX-Control nahe, der
Unterschied zum derzeitigen Janas waere aber wohl auch nicht gross
(nur dass a99 Daten uebertragen darf im Gegensatz zum momentanen
Zustand, dass es komplette HTML-Seiten sein muessen).

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

iD8DBQFGejR/hKFJT0F1FsoRAvGZAJ4ksHi10XxuRp5jUwqq5p+XWN767QCfXbtF
tSakehbZ0af7eVDBZAx8kRg=
=OLCP
-----END PGP SIGNATURE-----