Community
Participate
Working Groups
HEAD. The Javadoc of Button(...) says: Style bits are also inherited from superclasses. While this is mostly true it is not for this class as the set of allowed styles is entirely defined in the Javadoc of the Button class. Also, the Javadoc should mention what happens when other/wrong style bits are set, e.g. SWT.NONE defaults back to SWT.PUSH.
(In reply to comment #0) > HEAD. > The Javadoc of Button(...) says: > Style bits are also inherited from superclasses. > While this is mostly true it is not for this class as the set of allowed styles > is entirely defined in the Javadoc of the Button class. It is true for Button, button inherits the Styles BORDER, LEFT_TO_RIGHT, RIGHT_TO_LEFT from Control. Agreed ? > Also, the Javadoc should mention what happens when other/wrong style bits are > set, e.g. SWT.NONE defaults back to SWT.PUSH. Usually we don't spec what happens when the toolkit is used the wrong way. In button for example, passing NO_SCROLL you give a radio button. In short, if a wrong bit is passed in, we don't know what is going to happen. What can be said is: If none of ARROW, CHECK, PUSH, RADIO, and TOGGLE is set, the button defaults to PUSH.
(In reply to comment #1) > (In reply to comment #0) > > HEAD. > > The Javadoc of Button(...) says: > > Style bits are also inherited from superclasses. > > While this is mostly true it is not for this class as the set of allowed styles > > is entirely defined in the Javadoc of the Button class. >Agreed ? Ah yes, true. I was mainly detecting and filing this bug because someone tried SWT.NONE which is legal since it is inherited. However, the behavior for this legal use is not documented. > What can be said is: If none of ARROW, CHECK, PUSH, RADIO, and TOGGLE is set, > the button defaults to PUSH. OK.
(In reply to comment #2) > Ah yes, true. I was mainly detecting and filing this bug because someone tried > SWT.NONE which is legal since it is inherited. However, the behavior for this > legal use is not documented. Where do we say SWT.NONE is legal ? Not sure if I want to say SWT.NONE->SWT.PUSH for button. If I do that for button then it would make sense to do it for all other controls, for example: in Text SWT.NONE->SWT.SINGLE in Combo: SWT.NONE->SWT.SIMPLE etc
(In reply to comment #3) > (In reply to comment #2) > > Ah yes, true. I was mainly detecting and filing this bug because someone tried > > SWT.NONE which is legal since it is inherited. However, the behavior for this > > legal use is not documented. > > Where do we say SWT.NONE is legal ? The constructor says: * Style bits are also inherited from superclasses. and Button inherits from Widget, which says: * <dt><b>Styles:</b></dt> * <dd>(none)</dd>
(In reply to comment #4) > * <dt><b>Styles:</b></dt> > * <dd>(none)</dd> IMO the person who wrote that did not mean that SWT.NONE is a valid bit, it just means no style. Car, since you are lot better than I in language skills, can you please decide what is the best way to make our java doc more clear.
(In reply to comment #5) > (In reply to comment #4) > > * <dt><b>Styles:</b></dt> > > * <dd>(none)</dd> > > IMO the person who wrote that did not mean that SWT.NONE is a valid bit, it > just means no style. Well, I'm not going to debate what that person had in mind ;-) SWT.NONE: * A constant known to be zero (0), typically used in operations * which take bit flags to indicate that "no bits are set". This seems to fit fine with what's defined in 'Widget'. ==> simply remove the part in Javadoc that speaks about inheritance.
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.
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. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. 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. -- The automated Eclipse Genie.
