home *** CD-ROM | disk | FTP | other *** search
/ Turbo Toolbox / Turbo_Toolbox.iso / 1990 / 09 / grdlagen / textbox.asc < prev    next >
Text File  |  1990-07-16  |  5KB  |  137 lines
  1. Erklärende Hinweise zu:
  2.  
  3.  
  4.  
  5.  
  6.  
  7.                     " Begegnungen mit OS/2, Teil 6 "
  8.  
  9.               " Wenn der Text nicht in das Fenster paßt... "
  10.  
  11.      ( Theorie und Praxis des Scrollens mit dem PM, toolbox 9/90 )
  12.  
  13.  
  14.           ( vergleiche Listing und Kommentare in "Scroll1.C" )
  15. ( der 2. Teil zum Thema Scolling wird voraussichtlich in 10/90 erscheinen )
  16.  
  17.  
  18.  
  19.  
  20.  
  21.  
  22.  
  23.  
  24.  
  25.  
  26.                  Fensterklassen und Fensterprozeduren:
  27.  
  28. Was im Client eines Fensters passiert, wird gesteuert von einer
  29. selbstgeschriebenen Fensterprozedur wie ClientWindowProc. Die
  30. Beziehung zwischen dem Fenster und den zugehörigen Prozeduren erfolgt
  31. aber nicht direkt, sondern über den Umweg der Fensterklassen. Ganz
  32. allgemein gehört zu jeder Fensterklasse genau 1 Fensterprozedur.
  33. Jedoch können mehrere Fenster zu derselben Klasse gehören. Wenn 2
  34. Fenster zu derselben Fensterklasse gehören, reagieren sie gleich.
  35.  
  36. In unserem Beispielprogramm wird mit WinRegisterClass die Prozedur
  37. ClientWindowProc der Klasse szClientClass (eigener Name) zugeordnet.
  38. Weil diese Klasse im 4. Argument von WinCreateStdWindow angegeben ist,
  39. wird für alle Messages des Client die Fensterprozedur ClientWindowProc
  40. aufgerufen.
  41.  
  42. Abgesehen von diesen selbst zu definierenden Fensterprozeduren und
  43. Fensterklassen, gibt es auch PM-interne ("pre-defined") Klassen und
  44. Prozeduren. Da auch die internen Fensterprozeduren zu bekannten
  45. Klassen gehören, kann man diese benutzen und durch zusätzliche
  46. Filtermechanismen (zum Beispiel Subclassing) modifizieren, ohne sie im
  47. Detail zu kennen. Jedoch wäre es sicher jedem Programmierer noch
  48. lieber, wenn er die Sourcen selbst ansehen könnte, so wie es jeder
  49. MOTIF-Programmierer kann.
  50.  
  51. Zu den internen gehört auch die Klasse der Scrollbars. Die PM-internen
  52. Fensterklassen haben eindeutige Nummern, die in PMWIN.h definiert
  53. sind: z.B. WC_SCROLLBAR oder WC_TITLEBAR für den Titel.
  54.  
  55. Ein mit dem Flag FCF_VERTSCROLL in WinCreateStdWindow erzeugter
  56. senkrechter Scrollbar gehört also zur Klasse WC_SCROLLBAR.
  57.  
  58. So wie jede Klasse ihre Nummer hat, so hat auch jedes Fenster seine
  59. ID: der senkrechte Scrollbar hat die ID FID_VERTSCROLL.
  60.  
  61. Statt den Scrollbar mit WinCreateStdWindow und FCF_VERTSCROLL zu
  62. erzeugen, könnte man ihn auch mit WinCreateWindow erzeugen: diese noch
  63. allgemeinere Fenstergenerierungsprozedur verlangt explizit die Klasse
  64. ( WC_SCROLLBAR ) und die Fenster-ID. Außerdem ist der Stil des
  65. Fensters mit SBS_VERT anzugeben, wenn man einen senkrechten Scrollbar
  66. erzeugen will; beim waagrechten ist SBS_HORZSCROLL anzugeben.
  67.  
  68. Scrollbars sind eine besondere Sorte von Controls: zusätzlich zu der
  69. PM-internen Fensterprozedur muß in der Anwendung noch eine Menge Logik
  70. implementiert werden: der durch FCF_VERTSCROLL erzeugte Scrollbar ist
  71. nur da, um in bestimmten Situationen Messages zu senden oder zu
  72. empfangen. In den anderen Fensterbereichen passiert dadurch aber nur
  73. etwas, wenn man die Reaktionen auf die vom Scrollbar abgeschickten
  74. Messages explizit codiert.
  75.  
  76.  
  77.  
  78.  
  79.  
  80.  
  81.  
  82.  
  83.            Notification-Messages:
  84.  
  85. Ebenso wie der Titel, die System-Menübox, die
  86. Minimize/Maximize-Box und der Actionbar gehören auch die
  87. Scrollbars zu den Kindern des Frames. Der Frame ist aber
  88. nicht nur der Vater, sondern auch der "Owner" dieser
  89. Fenster. Umgekehrt heißen diese Fenster "Controls" des
  90. Frames. Die Owner-Control-Beziehung hat im Unterschied
  91. zur Vater-Kind-Beziehung nichts mit der Anzeige und dem
  92. Clippen der Fenster zu tun. Die Owner-Control-Beziehung
  93. bestimmt, an wen Messages zwischen Fenstern
  94. weitergegeben werden. Ein Fenster hat stets einen Vater
  95. - dagegen muß ein Fenster nicht unbedingt einen Owner
  96. haben! Siehe auch im Kasten "Fensterbeziehungen".
  97.  
  98. Controls schicken sogenannte Notification-Messages an
  99. ihren Owner, wenn der Benutzer mit den Controls
  100. kommuniziert. Der Owner verarbeitet diese Messages:
  101. "verarbeiten" bedeutet meist weiterleiten! Wenn der
  102. Benutzer irgendwo im Scrollbar klickt, schickt dieser
  103. eine WM_VSCROLL- (bzw. WM_HSCROLL-) Message an den
  104. Frame. Dieser wiederum schickt sie an den Client, dessen
  105. Fensterprozedur sie dann endgültig verarbeitet.
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114.  
  115.  
  116.                    Fensterbeziehungen:
  117.  
  118. Die Beziehungen zwischen Fenstern kann man mit WinQueryWindow
  119. erfragen. Die wichtigsten Fragen sind die nach dem Vater und die nach
  120. dem Owner eines gegebenen Fensters (gegeben heißt, daß man den Handle
  121. des Fensters kennt). Beispielsweise erhält man den Vater von
  122. hwndClient mit
  123.  
  124. hwndFrame = WinQueryWindow( hwndClient,
  125.                             QW_PARENT,
  126.                             FALSE );
  127.  
  128. Die Beziehung zwischen dem 1. Argument und dem Handle des Ergebnis-
  129. Fensters wird also über das 2. Argument festgelegt: der PM unterstützt
  130. eine ganze Anzahl von Konstanten, die alle mit dem Präfix QW_
  131. beginnen. Um den Owner von hwndClient zu bestimmen, müßte man als 2.
  132. Argument also QW_OWNER angeben. Die anderen QW-Konstanten betreffen
  133. die sogenannte Z-Order der Fenster. Dies benötigen wir im Moment aber
  134. ebensowenig wie das 3. Argument, mit dem man Fenster sperren kann.
  135.  
  136.                             -- ENDE --
  137.