Community
Participate
Working Groups
1) If your widget has a client area (e.g. overrides computeSize()) then when anything happens that could change the size of the client area (e.g. scrollbars appear/disappear, font changes and changes the size of the header area) then a "fake" SWT.Resize event should be sent to all your children. Be careful because when you use notifyListeners, the SWT.Resize event will also get sent to your widget if you are listening for the SWT.Resize event.
KR> I just read your article. I think it's very well written and easy to understand (for me anyway <g>) *except* for the Spinner example. I was surprised to see that you implement the Spinner using fat natives after Steve's article preaches the benefits of the 1:1 Java to native mapping. I think readers might be confused if they read Steve's article first and then the custom widget article. It's not going to get the message out on how to best do your own native wrapper. It would be nice if the Spinner example built on the initial SWT article. You could even include a reference pointing to the discussion about fat vs. light natives. SN> You missed the point entirely... we don't want customers accessing our internal classes. We did it on purpose. Also, the idea was to show how to interface a native widget, not write the PI, that would cloud the issue. KR> Good point about the internal classes. Since all the OS stuff you refer to in the SWT article is in swt.interal it's off limits for customers. Perhaps Car's article should mention this? I think the chapter generally is good and it makes sense to have it. It's just not clear why you implement the widget in the natives and not do what SWT does. I should have known that you did this because the customer isn't supposed to use swt.internal stuff. However, the customer won't know (unless they read Jeem's article and didn't forget about the internal package rule). After reading Steve's article they'd probably just do what SWT does and use OS.java.
AW> In Car's article about Layouts, she mentiones at the very end how to overwrite layout if you install your own ControlListener. However, IMHO it is not stressed enough how important this is for clients because they want to be able to use a polymorphic layout() that works under all circumstances without having to know whether a Layout or whether a ControlListener has been installed. In fact in your & Car's article 'Creating your own widgets with SWT' in section 'Positioning children on resize' I would not introduce a private method 'resize' which implements the layout but would rather overwrite 'layout (boolean)' to follow the rule.
Maybe should have an example dialog, now that Dialog has been opened up.
Really old doc bug. Either fix or close.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
