| [9] | 1 | <?xml version="1.0" encoding="UTF-8"?>
|
|---|
| 2 | <?xml-stylesheet type="text/css"
|
|---|
| 3 | href="eclipseos2-xxe.css"
|
|---|
| 4 | ?>
|
|---|
| 5 | <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
|
|---|
| 6 | "xhtml1-strict.dtd">
|
|---|
| 7 | <html>
|
|---|
| 8 | <head>
|
|---|
| 9 | <link href="eclipseos2.css" rel="stylesheet" type="text/css" />
|
|---|
| 10 |
|
|---|
| 11 | <title>Eclipse for OS/2 Transitional Project Notes</title>
|
|---|
| 12 | </head>
|
|---|
| 13 |
|
|---|
| 14 | <body>
|
|---|
| 15 | <h1>SWT Step 7. Buttons</h1>
|
|---|
| 16 |
|
|---|
| 17 | <h2>Objective</h2>
|
|---|
| 18 |
|
|---|
| 19 | <p>Complete the implementation of the <code>o.e.swt.widgets.Button</code>
|
|---|
| 20 | widget. The test example should demonstrate all types of buttons that
|
|---|
| 21 | exist in SWT.</p>
|
|---|
| 22 |
|
|---|
| 23 | <h2>Task notes</h2>
|
|---|
| 24 |
|
|---|
| 25 | <p>Button text and icon alignment styles (<code>SWT.LEFT</code>,
|
|---|
| 26 | <code>SWT.RIGHT</code>, <code>SWT.CENTER</code>) are not currently
|
|---|
| 27 | supported. I personally see no need in these styles at all. Besides this,
|
|---|
| 28 | supporting them will make it impossible to keep the system look and feel
|
|---|
| 29 | for <code>SWT.PUSH</code> buttons (for example, provided by eStyler).</p>
|
|---|
| 30 |
|
|---|
| 31 | <p>However, <code>SWT.TOGGLE</code> buttons currently lose the pushbutton
|
|---|
| 32 | L&F provided by eStyler in any case, since they are completely drawn
|
|---|
| 33 | by hand due to lack of this type of buttons in OS/2. We're in contact with
|
|---|
| 34 | the eStyler author and hope this will be worked around later.</p>
|
|---|
| 35 |
|
|---|
| 36 | <p>When implementing this step, it turned out that some other
|
|---|
| 37 | functionality has to be implemented within it, and something needs to be
|
|---|
| 38 | changed. In particular, the following has been additionally
|
|---|
| 39 | implemented:</p>
|
|---|
| 40 |
|
|---|
| 41 | <ul>
|
|---|
| 42 | <li>keyboard handling (<code>SWT.KeyDown</code>/<code>KeyUp</code>
|
|---|
| 43 | events)</li>
|
|---|
| 44 |
|
|---|
| 45 | <li>focus traversal (<code>SWT.FocusIn</code>/<code>FocusOut</code>)
|
|---|
| 46 | using the keyboard (<kbd>TAB</kbd>/<kbd>Shift-TAB</kbd>, arrows,
|
|---|
| 47 | mnemonic keys [with and w/o the <kbd>Alt</kbd> key])</li>
|
|---|
| 48 |
|
|---|
| 49 | <li>shell activation/deactivation
|
|---|
| 50 | (<code>SWT.Activate</code>/<code>Deactivate</code>)</li>
|
|---|
| 51 | </ul>
|
|---|
| 52 |
|
|---|
| 53 | <p>Also, it became necessary to change the <code>Decorations</code>
|
|---|
| 54 | implementation.</p>
|
|---|
| 55 |
|
|---|
| 56 | <p>The following subsections provide some further details.</p>
|
|---|
| 57 |
|
|---|
| 58 | <h4>keyboard handling</h4>
|
|---|
| 59 |
|
|---|
| 60 | <p>The current implementation of keyboard events is very simple: OS/2
|
|---|
| 61 | virtual keys supported by Eclipse are reported as Eclipse virtual keys
|
|---|
| 62 | (<code>KeyEvent::keyCode</code>) with <code>KeyEvent::character</code> set
|
|---|
| 63 | to zero. All other events have <code>keyCode</code> set to zero and
|
|---|
| 64 | <code>character</code> equal to what OS/2 reports in the <code>usch</code>
|
|---|
| 65 | parameter of the <code>WM_CHAR</code> message (converted to unicode
|
|---|
| 66 | according to the curent locale), except the situation when both
|
|---|
| 67 | <code>keyCode</code> and <code>character</code> are zero (no
|
|---|
| 68 | <code>KeyEvent</code> is generated in this case).</p>
|
|---|
| 69 |
|
|---|
| 70 | <p>This differs a bit from how Eclipse/Win32 generates key events. For
|
|---|
| 71 | example, when we press <kbd>Ctrl</kbd> and then press and release the
|
|---|
| 72 | <kbd>A</kbd> key, Eclipse/OS2 reports <kbd>a</kbd> (<code>0x71</code>) in
|
|---|
| 73 | the <code>character</code> field of the key press event and the control
|
|---|
| 74 | code <code>0x11</code> in the same field of the key release event (i.e.
|
|---|
| 75 | key press character doesn't match key release character); Win32 reports
|
|---|
| 76 | <code>0x11</code> in both cases. Another example is <kbd>Alt</kbd> plus
|
|---|
| 77 | letter. Eclipse/OS2 doesn't generate the key release event for the letter
|
|---|
| 78 | at all, since <code>usch</code> in <code>WM_CHAR</code> is zero in this
|
|---|
| 79 | case (Win32 reports both).</p>
|
|---|
| 80 |
|
|---|
| 81 | <p>The reason why I left the OS/2 behavior as is for now (i.e. not fully
|
|---|
| 82 | compatible with Win32) is simple: currently, I don't get the logic how
|
|---|
| 83 | keyboard messages are handled in Win32. For example, if you press
|
|---|
| 84 | <kbd>Alt</kbd> there, then press some letter, then release <kbd>Alt</kbd>
|
|---|
| 85 | and finally release the letter you get three events: a press event with
|
|---|
| 86 | <code>keyCode=SWT.ALT</code> and <code>character=0</code>, a press event
|
|---|
| 87 | with <code>keyCode=0</code> and <code>character=<letter></code>, and
|
|---|
| 88 | a combined release event with <code>keyCode=SWT.ALT</code> and
|
|---|
| 89 | <code>character=<letter></code> (i.e. we also get press/release pair
|
|---|
| 90 | mismatch) -- that seems strage to me. But all this is related to the
|
|---|
| 91 | pretty outdated SWT version 2.01, and I think things have changed in
|
|---|
| 92 | recent SWT/Win32 releases, so the keyboard handling in Eclipse/OS2 will be
|
|---|
| 93 | improved later, when we move the whole project to one of current Eclipse
|
|---|
| 94 | releases.</p>
|
|---|
| 95 |
|
|---|
| 96 | <h4>Decorations reimplementation</h4>
|
|---|
| 97 |
|
|---|
| 98 | <p>The previous <code>Decorations</code> <a
|
|---|
| 99 | href="swt003.html#FrameClientWindow">implementation</a> involved a special
|
|---|
| 100 | internal SWT widget (<code>ClientArea</code>) to represent the client area
|
|---|
| 101 | of any top-level window. This caused lots of problems related (not only)
|
|---|
| 102 | to focus traversal because of the explicitly expressed parent-child
|
|---|
| 103 | relationship (on SWT level) between the frame and client window
|
|---|
| 104 | (<code>ClientArea</code> was created as a child of
|
|---|
| 105 | <code>Decorations</code>, both in OS/2 and in SWT terms). This broke the
|
|---|
| 106 | children-related functionality in SWT and led to some other issues.</p>
|
|---|
| 107 |
|
|---|
| 108 | <p>So, I chose a bit different solution. Instead of having a special SWT
|
|---|
| 109 | class for the client area, <code>Decorations</code> now maintains two
|
|---|
| 110 | window handles directly -- one is a regular <code>Control::handle</code>
|
|---|
| 111 | field that now holds a handle to the client window (not a frame window
|
|---|
| 112 | handle as before), and another one is a separate field,
|
|---|
| 113 | <code>Decorations::frameHandle</code>, to hold the frame window
|
|---|
| 114 | (<code>WC_FRAME</code>) handle. Both windows are created by
|
|---|
| 115 | <code>Decorations::createHandle()</code>. The majority of new or overriden
|
|---|
| 116 | <code>Decorations</code> methods use the <code>frameHandle</code> field,
|
|---|
| 117 | while methods derived from <code>Composite</code>, <code>Control</code>
|
|---|
| 118 | etc. continue to use the <code>handle</code> field. Also, PM message
|
|---|
| 119 | handling was explicitely separated: <code>Decorations</code> has an
|
|---|
| 120 | additional window procedure, <code>windowFrameProc()</code>, that delivers
|
|---|
| 121 | messages addressed to the <code>WC_FRAME</code> window to
|
|---|
| 122 | <code>Decoration</code>'s methods. These methods are named
|
|---|
| 123 | <code>FRAME_WM_*</code> to differ from regular <code>WM_*</code> messages
|
|---|
| 124 | processed by <code>windowProc()</code> as usual.</p>
|
|---|
| 125 |
|
|---|
| 126 | <p>The <code>ClientArea</code> class has been completely removed.</p>
|
|---|
| 127 | </body>
|
|---|
| 128 | </html>
|
|---|
