[Allegro] 64bit: wege zur dosbox

[Thomas Berger]

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

Lieber Herr Eversberg,

>> Diese Vorbereitung von #ua! geschieht aber nur beim manuellen Aufruf "h order"
>> oder bei einem Flip, der das aequivalente tut. Sobald ich im Flip einen Flex
>> ausfuehre und dieser erst order.rtf zeigt, muss ich mich vor dem Aufruf um
>> identische Belegung von #ua! bemuehen. Eine teilweise Loesung koennte
>> entweder darin bestehen, dass die eingebetteten Flexe stets ausgefuehrt werden
>
> Das würde die bisher bestehenden FLEXe in dem Punkt aber beeinträchtigen.
> 
>> oder dass die exec-Syntax so erweitert wird, dass die Flex-Abarbeitung auch
>> in die Anzeige einer Hilfeseite uebergeleitet werden kann.
>>
> Wie meinen Sie das?

Flexe koennen einander ja leider nicht gegenseitig aufrufen, aber mit
exec immerhin ineinander "ueberleiten". D.h. bei "exec" erfolgt ein
Schnitt, ($-klein-Variable werden geloescht), die neue Flexdatei
wird geladen und ausgefuehrt. Das geht, weil die alte Flexdatei (bzw.
ihre interne Repraesentation als Ausfuehrungskontext) nicht mehr benoetigt
wird und daher komplett durch das neue ersetzt werden kann.

Nach meinem Verstaendnis liegt der Unterschied zwischen den Flips

h xy  (kann eingebettete Flexe)

und

x h xy   (kann keine eingebetteten Flexe)

daran, dass ein bestehender Flex-Abarbeitungskontext die Ausfuehrung
eingebetteter Flexe verhindert. Erkennung, dass "h" das letzte Kommando
eines Abarbeitungskontextes ist (Spezialfall: ueber "exec" mitteilen,
dass dem so ist) koennte also zunaechst den Kontext aufheben und damit
beim Anzeigen der Hilfeseite die Ausfuehrung eingebetteter Flexe moeglich
machen.


> Die monierte Sache mit der Anzeige der Geldbeträge bei Bestellungen in
> d-wrtf.apr wird noch bereinigt. Die DEM-Sachen kommen jetzt da raus, die
> sind nicht mehr relevant.
> Es gilt folgendes:
> 
> #9DB $p = Bestellpreis, Währung steht in $c
>      $q = Rechnungspreis, in EUR. Denn der darf sich nicht mehr ändern,
>           wenn der Kurs sich ändert.
>      $i = bezahlter Preis in EUR; nur falls "Abschluss" gemacht wird.
>           kann von $q abweichen, wenn Rechnung nicht sofort bezahlt
>           wurde.

Das laesst noch einige Fragen offen, die evtl. die alte ORDER-Dokumentation
klaert, was aber nicht unbedingt besagt, dass das neue order dieselbe
Auffassung hat:

- - man sollte beim Rechnungseingang u.U. $p noch modifizieren, so dass
  dieser Preis dem individuellen Rechnungsposten entspricht?

- - $q ist u.U. der Preis unter Beruecksichtigung von Rabatten und (anteiligen)
  Versandkosten, vom Bearbeiter in EURO umgerechnet (hier ist die Praxis m.E.
  sehr uneinheitlich, die Versandkosten aufzudroeseln ist eine fragwuerdige
  Fleissarbeit, einige haben auch bewusst gerne den "Wert" irgendwo vermerkt)

- - $i ist vermutlich nicht der "bezahlte" Preis, sondern der, der anhand der
  monatlichen amtlichen Umsatzsteuer-Umrechnungskurse (heissen die so?)
  retrospektiv festgelegt worden ist.

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

iJwEAQECAAYFAkwq8qcACgkQYhMlmJ6W47PpdAQAiULOswDRV5kHt9bkEBj8nJM6
ZupeEapLq/ssBnlzQBDKX69W7U8RN6Z/KrWuGBLdWUH7QItk8PI4qcbj5uV3OzMA
GpWAjmLMrV4t15neLwIZrVM5PXF+8vvd0dWbvHQhBFGkFY7dmfW3twiZ4vz13BHX
Gy9Og50gAqqPRCxM9a8=
=APTh
-----END PGP SIGNATURE-----