home *** CD-ROM | disk | FTP | other *** search
/ Dream 48 / Amiga_Dream_48.iso / Atari / c / windial.lzh / WINDDIAL / WINDDIAL.TXT < prev   
Text File  |  1993-04-11  |  10KB  |  237 lines
  1. Inhaltsverzeichnis:
  2.  
  3. 1. Einführung
  4. 2. Beschreibung der Routinen
  5. 3. Tips für die Programmierung
  6. 4. Bugs
  7. 5. Kontakte
  8.  
  9. 1. Einführung
  10.  
  11. Die Routinen von WINDDIAL dienen zur Verwaltung von Dialogboxen in
  12. normalen GEM-Fenstern. Jede Menge Leute werden jetzt schon wissen,
  13. wozu das gut ist. Diese brauchen dann erst den nächsten Abschnitt
  14. lesen. Warum also Dialoge in Fenstern? Die Darstellung irgendwelcher
  15. Informationen (wie z.B. der Dialogbox) ist unter GEM nur in Fenstern
  16. möglich, wenn man nicht alle anderen Aktivitäten des Rechners
  17. lahmlegen will oder mit dem Überschreiben seiner Infos rechnen will.
  18. Die normale form_do()-Routine mu₧ daher mit einem wind_update()
  19. geschützt werden, die dem AES Schreiboperationen auf dem Bildschirm
  20. untersagt. Dadurch geht die Kontrolle über den Rechner sozusagen auf
  21. die Dialogbox über, andere Programme (oder Accessorys) können während
  22. der Zeit der Dialogabarbeitung nichts unternehmen. Lä₧t man das
  23. wind_update() weg, mu₧ man bei der erstbesten Gelegenheit damit
  24. rechnen, da₧ die Dialogbox übermalt wird. Auf einem normalen Atari
  25. mag es durchaus akzeptabel sein, da₧ erst die Dialogbox fertig
  26. bearbeitet wird, unter MULTITOS, wenn mehrere Programme sichtbar
  27. sind, ist das jedoch äu₧erst unpraktisch.
  28.  
  29. Legt man nun den Dialog in ein Fenster, wird man vom AES informiert,
  30. wenn die Informationen aufgefrischt werden müssen. Man kann also
  31. getrost vorübergehend die Kontrolle abgeben und die Dialogbox kann
  32. gnadenlos übermalt werden: wenn sie dann wieder gebraucht wird,
  33. bekommt man ja die Nachricht, alles neu zu zeichnen.
  34.  
  35. Im XCONTROL.ACC von Atari wird es bereits so gemacht. Mit dem hier
  36. vorgestellten Routinen kann jeder Programmierer für seine Programme
  37. Dialogboxen in Fenster legen und verwalten lassen.
  38.  
  39.  
  40. 2. Beschreibung der Routinen
  41.  
  42. WINDDIAL wurde so entwickelt, da₧ möglichst wenig Aufwand bei der
  43. Umgestaltung eigener Programme mit normalen Dialogboxen entsteht. Ich
  44. glaube dennoch nicht, das dadurch unnötig ineffektiv programmiert
  45. wurde.
  46.  
  47. Es werden 3 Routinen angeboten, die 3 AES-Funktionsaufrufe ersetzen:
  48.  
  49. -   form_wind(...) kommt für form_dial(FMD_START,...)
  50. -   wind_do(...) kommt für form_do(...)
  51. -   form_wclose(...) kommt für form_dial(FMD_FINISH,...)
  52.  
  53. Die Prototypen sind "winddial.h" angegeben. Eine wesentliche Rolle
  54. spielt die Datenstruktur "wi_data", in der alle nötigen Informationen
  55. über das Fenster und den Objektbaum enthalten sind. Ein Zeiger auf
  56. diese Struktur ersetzt bzw. erweitert den Zeiger auf den Objektbaum
  57. bei den obigen Funktionsaufrufen.
  58.  
  59. /* struct zum Verwalten der Windows */
  60.  
  61. typedef struct
  62. {
  63.     unsigned drawed:    1;   /* Flag für erstes Redraw */
  64.     unsigned auto_top:  1;   /* andere Fenster toppen */
  65.     unsigned ltmf:      1;   /* let 'em fly nutzen */
  66. }
  67. wi_flags;
  68.  
  69. drawed verhindert das doppelte Zeichnen der Dialogbox beim ersten
  70. Aufruf (einmal durch den Nutzer und dann nach Eintreffen der Redraw-
  71. Meldung), auto_top sorgt darür, da₧ auch andere Fenster als das der
  72. Dialogbox getopt werden (d.h. wenn eine WM_TOPPED-Message kommt, wird
  73. im True-Fall das gemeldete Fenster als oberstes Fenster gesetzt. Das kann
  74. Arbeit sparen, aber auch unerwünscht sein). ltmf schlie₧lich steuert
  75. die Nutzung von Let 'em fly.
  76.  
  77. typedef struct{
  78.    int wi_handle; /* Window-Handle */
  79.    OBJECT *obj;   /* Zugehöriger Object-Baum */
  80.    int *m,*n,*o,*p;  /* Clipping-Koordinaten */
  81.    wi_flags flags;   /* Flags für Fenster*/
  82. }wi_data;
  83.  
  84.  
  85. Kommen wir zur Beschreibung der Routinen:
  86.  
  87. /********************************************************
  88. *             form_wind()                               *
  89. *   initialisieren und zeichnen des Fensterrahmens      *
  90. *   erste 5 Parameter: wie form_center                  *
  91. *   wind :   Zeiger auf zu bearbeitende Window-Struktur *
  92. *   title:  Titel des Fensters                          *
  93. *   return:  im Fehlerfall !=0 , sonst 0                *
  94. ********************************************************/
  95.  
  96. int form_wind(OBJECT *ptr,int *center_x,int *center_y,
  97.            int *center_w,int *center_h,
  98.            wi_data *wind,char *title);
  99.  
  100. Die ersten 5 Parameter sollten direkt aus form_center übernommen
  101. werden. Als nächstes folgt die Adresse einer wi_data-Struktur, die in
  102. dieser Funktion ausgefüllt wird. Und schlie₧lich wird ein Zeiger auf
  103. einen String übergeben, der als Titelzeile des Fensters dient. Kann
  104. kein Fenster geöffnet werden, wird eine normale Dialogbox geöffnet,
  105. die von wind_update() geklammert wird. Es wird hierzu form_do()
  106. aufgerufen.
  107.  
  108. /************************************
  109. *        form_wclose()              *
  110. * Dialog beenden, Fenster schlie₧en *
  111. * Parameter:                        *
  112. * wind: Zeiger auf Fensterstruktur  *
  113. ************************************/
  114.  
  115. int form_wclose(wi_data *wind);
  116.  
  117. Ganz einfach schlie₧en des Fenstes mit der Dialogbox.
  118.  
  119. /*****************************************************************
  120. *           form_do() in Fenstern: wind_do()                     *
  121. *   Parameter:                                                   *
  122. *   wind       : von form_wind() bearbeitetes wind-Objekt        *
  123. *   start_field: Objektnummer, in dem sich der Textcursor zuerst *
  124. *                 befinden soll                                  *
  125. *   buf[8]      : Messagepuffer                                  *
  126. *   return      : Nummer des angesprochenen Objektes oder        *
  127. *                 -1 Nach Eintreffen einer Message               *
  128. *****************************************************************/
  129.  
  130. /* aus dem Profibuch (form_do()), erweitert um Message-Handling */
  131.  
  132. int wind_do(wi_data *wind,int start_field,int *buf);
  133.  
  134. Hier war das meiste zu tun. wind_do() übernimmt die komplette
  135. Verwaltung der Dialogbox einschlie₧lich aller Redraws. Nach Rückkehr
  136. aus dieser Routine, wenn ein Exit-Object angesprochen wurde, kann man
  137. sicher sein, das die Box so aussieht, wie sie es soll. Der dritte
  138. Parameter buf dient zur Abspeicherung der eingetroffenen Nachrichten.
  139. Alle eingegangenen Nachrichten werden weitergemeldet, auch Redraws,
  140. die schon abgearbeitet wurden. Ein Redraw innerhalb von wind_do()
  141. bezieht sich immer nur auf den angegebenen Objektbaum (analog zu
  142. CPX-Modulen). Die Nachricht WM_TOPPED führt in Abhängigkeit vom Flag
  143. auto_top zum Toppen des angegeben Fensters. Der entsprechende
  144. wind_set()-Aufruf braucht also vom Hauptprogramm nicht getätigt werden.
  145. Wird wind_do() in Accessorys verwendet und das Dialogfenster ist gerade
  146. nicht sichtbar, führt ein Anklicken des Accessory-Menüintrages zu einem
  147. Sichtbarmachen des Fensters.
  148. Von T34 (Thomas Baade) wurde ein weiteres Feature eingebaut: In den Edit-
  149. Feldern kann der Cursor mittels der Maus positioniert werden.
  150.  
  151. 3. Tips für die Programmierung
  152.  
  153. Ein Beispielprogramm sieht z.B. so aus
  154.  
  155. {
  156.     ....
  157.     int x,y,w,h,mesg_buf[8];
  158.     int form;
  159.     wi_data wind;
  160.     form_center(tree,&x,&y,&w,&h);
  161.     form_wind(tree,&x,&y,&w,&h,&wind," Titel ");
  162. /*  war: form_dial(FMD_START,...) */
  163.     form_dial(FMD_GROW,0,0,0,0,x,y,w,h);
  164.     objc_draw(tree,0,8,x,y,w,h);
  165.     form=wind_do(&wind,0,mesg_buf[8]);
  166.     switch(form)
  167.     {
  168.         case -1: HandleMesg();
  169.                  break;
  170.                  ....
  171.     }
  172.     form_dial(FMD_SHRINK,0,0,0,0,x,y,w,h);
  173.     form_wclose(&wind);
  174. /*  war: form_dial(FMD_FINISH,...) */
  175.     ...
  176. }
  177.  
  178. Die Unterschiede sind sind also zunächst nicht umwerfend. Sie liegen
  179. aber im Detail. Insbesondere müssen die Ergebnisse von wind_do()
  180. erweitert betrachtet werden:
  181. - darauf achten, da₧ bei return: -1 (Message) kein Objekt versucht
  182.   zu zeichnen (tree[-1] macht wohl kaum einen Sinn)
  183. - wie auch bei form_do() wird ein Doppelklick durch setzen des
  184.   obersten Bits im Returnwert gekennzeichnet. Also bei Bedarf ausmas-
  185.   kieren (form&0x7fff). Dadurch wird natürlich die Messagekennung auch
  186.   zu 0x7fff (statt -1).
  187. - Es können natürlich auch Menüs, andere Fenster ... angewählt werden.
  188.   Das sollte beachtet werden.
  189. - Es können mehrere Dialoge parallel bearbeitet werden. (wenn vom Programm
  190.   unterstützt)
  191. - Die Fenster und damit die Dialoge können verschoben werden.
  192. - Das Fenster hat einen Schlie₧knopf. Die Meldung WM_CLOSED sollte
  193.   also ausgewertet werden.
  194. - Bei Einsatz in Accessorys mu₧ die Meldung AC_CLOSE unbedingt zum
  195.   Schlie₧en des Fensters führen.
  196. - Für die Behandlung der beiden obigen Meldungen schlage ich gleiche
  197.   Behandlung wie bei CPX-Modulen vor: WM_CLOSED als Abbruch und
  198.   AC_CLOSE als OK. (sofern es in dieser Art einen Sinn macht)
  199.  
  200. Ach so, wenn Let 'em fly installiert ist, wird dieses zur Auswertung
  201. von Tastaturshortcuts genutzt (in Abhängigkeit vom Flag ltmf).
  202.  
  203. 4. Bugs
  204.  
  205. Viele Fehler sind uns noch nicht aufgefallen. Aber in Zusammenarbeit mit
  206. Let 'em fly gibt es einige (zwei) Probleme:
  207.  
  208. - Aus ungeklärten Gründen stürzt der Rechner ab, wenn zwei wind_dials()
  209.   aktiv sind und ein
  210.     - Programm die Dialogbox schlie₧t,
  211.     - wind_update(BEG_MCTRL) macht,
  212.     - dann die Fileselectbox aufruft,
  213.     - ein wind_update(END_MCTRL) macht.
  214.  
  215. Wahrscheinlich im zweiten wind_update passiert der Absturz. Zum Probieren
  216. am besten zweimal RENUMBER als Accessory laden und aus einem eine Datei
  217. auswählen.
  218.  
  219. - Wird der Dialog teilweise aus dem Bildschirm geschoben, werden die Unter-
  220.   stricht von Let 'em fly mitten auf dem Schirm plaziert. Das liegt wahr-
  221.   scheinlich daran, das in Let 'em fly kein VDI-Clipping gemacht wird.
  222.  
  223. Bei der Erstellung der winddials stand mir Let 'em fly Version 1.14 zur
  224. Verfügung.
  225.  
  226. 5. Kontakte
  227.  
  228. Für Kommentare, Anfeindungen, Danksagungen, Tips e.t.c. bin ich im Mausnetz
  229. unter
  230.  
  231. Jan Starzynski @ HRO
  232.  
  233. zu erreichen.
  234.  
  235. PS: Im Programm "RENUMBER.PRG" wird von diesen Dialogen Gebrauch gemacht.
  236.  
  237.