--> Ich finde die BltBitMap()-Routine nicht. Ist diese nicht im
    Compiler integriert?

    WOUTER:

    Es gibt BltBitMap() in die compiler! versuch doch mal:

       PROC main()
       ENDPROC

       PROC nicht_benutzt()
            BltBitMap(1,1,1,1,1,1,1,1,1,1,1) /* hier muessen natuerlich richtige */
       ENDPROC                            /* parameter rein */

--> Gibt es eine Möglichkeit, Source in Amiga_E mit einem Include-Befehl
    einzubinden? Kann man auch schon gewandelten Source einbinden?

    WOUTER:

    in v2.5 kan man einfach eine menge PROC's (und OBJECTs, CONSTs etc.)
    zu eine '.m' file compilieren, und im hauptprogram kan man dan
    einfach die sache includen (mit MODULE), und die code hinzulinken.

    mit 2.1(b), wenn sie wirklich wollen, sollte man einen Preprozessor
    benutzen (EPP)(es gibt einige ins PD).

    vieleicht gibt's in 2.5 auch die moeglichkeit assembly '.o'
    files in '.m' files zu verwandeln.

--> Warum kann ich folgende Konstanten-Zuweisung nicht machen:
          CONST sizeobj=SIZEOF objdef

    WOUTER:

    CONST sizeobj=SIZEOF objdef
    waere nicht moeglich, weil die groesse eines objectes NUR
    beim compilieren bekant ist, und ein CONST bereits in 'lexical
    analyse' phase benutzt wird.
    aber troesten sie sich, fuer:

         a:=SIZEOF myobj        /* groesse is z.b. 28 */

    und:

         a:=28

    wird die gleiche code erzeugt! (MOVEQ #28,D0)
    es ist also nicht langsamer!
    sie koennen auch selbst schreiben:

    MOVEQ #SIZEOF myobj,D0

--> Warum kann ich in Amiga_E keine Zuordnung eines Objektes wie z.B
    DEF x[100]:ARRAY OF PTR TO image machen?

    WOUTER:

    Ein OBJECT in E ist in viele sachen ungleich ein RECORD in Pascal,
    also, was sie nuer machen konnen:

    DEF x:PTR TO image, y[100]:ARRAY OF LONG

    x:=y[1]
    x.field:=werd   /* usw. */

--> Kann Amiga_E auch mehrfachdimensionierte Arrays darstellen?

    WOUTER:

    Nein, es gibt kein mehrfach dimensionierten arrays in E.

--> Werden zukünftige Amiga_E-Versionen noch als PD zu erhalten sein?

    WOUTER:

    aiaiai... das wird schwierig sein: es gibt ne große chance, E v2.5
    wird commerciel vertrieben worden!

    mit tausenden user weltweit und monaten arbeid fuer ein einziges
    update, glaubst du ich wirds immer gratis herausgeben? man kan fröh sein,
    das ich ein so guter compiler wie v2.1b gratis herausgegeben habe.
    von die tausenden user habe ich zusammen ne lausige 200 dm bekommen.
    fuer zwei jahre arbeit.


--> Gibt es nicht doch eine Chance, mehrfach dimensionierte Array in
    Amiga_E darzustellen?

    WOUTER:

    Ja, das hab ich auf die "TODO" liste stehen, aber wann ? bis nun, machen sie
    bitte (wenn die array vom typ CHAR sein muß:

        OBJECT bla
               x[100]:ARRAY          /* soll 400 sein fuer 100 LONGs */
        ENDOBJECT

        DEF mehrf[100]:ARRAY OF bla, z:PTR TO CHAR

        z:=mehrf[5].z

        z[10]:=1               /* z[5,10]:=1 */
        z[11]:=2               /* z[5,11]:=2 */

    Ist ja nich einfach, aber's geht.

--> In meinem Programm habe ich eine relativ große Tabelle hinterlegt.
    Gibt es eine einfachere Möglichkeit, diese zu initialisieren?
    Ich habe die meiste Zeit für das umschreiben gebraucht, weil ich
    dauernd einen Fehler bei der Zuweisung der Tabelle bekommen habe.

    Ja, bis ich in deiner technischen Dokumentation gelesen habe, daß
    nur einige hundert Konstaten zugeordnet werden können.
    Ich habe aber einige tausend!

    WOUTER:

    das liegt an die art von compilierung von listen, da wird ein interner
    stack benuetzt, die nicht ganz groß ist! scheiß was?

    veileicht sollen sie es nicht so:

     [1,2,3,
      4,5,6,
      7,8,9]

    aber so:

     [[1,2,3]
      [4,5,6]
      [7,8,9]]

    strukturieren. also das ergibt eine liste von pointers (und kurzere
    listen)!


--> Der Befehl "StringF" fehlt in der Dokumentation. Könntest du diesen
    bitte mit aufnehmen?

    WOUTER:

    tue ich! es ist aenlich zu WriteF(formatstr,args,...):

             StringF(estring,formatstr,args,..)

    das ergebnis wird also in "string" copiert.

--> Wenn ich eine Adresse mit "{tabelle[10].xyz}" zuweisen will, bekomme
    ich immer einen Fehler. Dasselbe tritt auch bei dem Inhalt einer
    Adresse auf, also "^tabelle[10].xyz". Ist das ein Fehler oder
    nicht gewollt?

    WOUTER:

    kein fehler, aber die {} und ^ operatoren wirken nur auf ein und den
    selben identifiers. fuer {} wird sich das eines tages aendern...

--> SELECT und CASE
    Wenn ich das CASE-Segment vergesse, meldet der Compiler dieses nicht.

    Das passierte mir bei Scancode, als ich geschrieben habe

             SELECT was
             CASE   1
             CASE   2
             CASE   3
                    4
                    5
             ENDSELECT

    wobei der Punkt 4 und 5 auch nicht angesprungen wurden.
    Ein Bug?

    WOUTER:

    nein, gar nicht! es ist ja auch kein fehler, sondern legal!
    dies heißt ja etwa:

         CASE 3; VOID 4; VOID 5

    also: "im dritten fall, ermitteln sie die wert von exp. "4" und
    tue nichts damit, und auch so mit "5" "


--> Nochmals SELECT und CASE
    In Pascal ist diese für einen Bereich besser definiert. Hier kann
    ich schreiben
                 Case was of

                 3:
                 4..8:
                 9..11:
                 end;

    In AMIGA_E muß ich aber jedes einzelne Elemt beschreiben. Gibt es
    hier nicht eine einfachere Möglichkeit?

    WOUTER:

    nein, benutz mal "ELSEIF".
    jeder sprache hat ein anderes conzept fuer select: in pascal ist das
    ein range oder constante, in C nuer eine constante, und in E eine ganze
    expression. jeder hat seine nachteile.