Community
Participate
Working Groups
Combo's vertical size is fixed to 24 pixels. When you try to resize it taller than this, the visual display snaps back to 24 pixels, but the source code and property inspector show the size at whatever the rubber band snapped to. If the size of a component is fixed in some way, the source and property inspector should also be fixed in the same way.
This is an expected behavior and not a bug. Attempt to set the height makes no difference to Combo widget, only width is important. I double checked with sources for Combo.setBounds() and the following comment proves the statement above: /* * Feature in Windows. If the combo box has the CBS_DROPDOWN * or CBS_DROPDOWNLIST style, Windows uses the height that the * programmer sets in SetWindowPos () to control height of the * drop down list. When the width is non-zero, Windows remembers * this value and sets the height to be the height of the text * field part of the combo box. If the width is zero, Windows * allows the height to have any value. Therefore, when the * programmer sets and then queries the height, the values can * be different depending on the width. The problem occurs when * the programmer uses computeSize () to determine the preferred * height (always the height of the text field) and then uses * this value to set the height of the combo box. The result * is a combo box with a zero size drop down list. The fix, is * to always set the height to show a fixed number of combo box * items and ignore the height value that the programmer supplies. */ Peter? should mark it as INVALID?
Not a bug. Combo widget ignores height setting as described in my previous comment
The problem is that if the Combo widget cannot be vertically resized beyond 24 pixels, VE shouldn't codegen code to ask it to size bigger than 24 pixels.
Peter? I can't think of any solutions other than just adding a warning in the status line...what do you think? I believe there is nothing wrong with setting height for the combo.
Right now it appears that our code uses the following algorithm: Draw rubberband while resizing On MouseUp: note size of rubberband Change model to size of rubberband Would it be hard to change this to draw rubberband while resizing On MouseUp: ask the remote VM to resize the control ask the remote VM what size the control actually resized itself Change model to size the control actually resized itself Is this reasonble? Is it correct?
>On MouseUp: > ask the remote VM to resize the control > ask the remote VM what size the control actually resized itself > Change model to size the control actually resized itself This is not the way the VE was designed and would have a lot of side affects because of the listeners that get called and the order in which they are called. Or we could provide a lot of special code just to handle this case but that seems like a lot of overkill just to handle this. I tried this on Linux and the same behavior occurs although the drop down only shows one item in the running app. That's because the property visibleItemCount (default is 5) seems to be ignored on Linux. Not sure if this is a bug or something Linux SUSE 9.0 ignores in its OS. Haven't tried it on other Linux OS's. If the desired behavior is to have the Combo drop down further that it currently does in the running app, you can change the visibleItemCount to a larger number. But this shouldn't affect the design time look in VE. I believe the desired behavior for Combo is to not allow changes to its height. I don't think the user would want to have a height change applied to a Combo, otherwise it would more resemble a List with a text field. The only problem I see in VE is that it allows you to rubber band in the vertical direction which implies you can change it's height... which is applied in the remote VM and in the running application... but totally ignored by SWT since it's subject to the limitations in the OS and what's actually desired for a Combo. The rubber banding is by GEF as part of the size policies and we would have to write a special policy and editpart to ensure the rubber banding goes in the horizontal direction only to allow width changes but not height changes. We would also have to provide special cell editors for bounds and size to prevent changes to the height since it's not applicable. If you feel this should be done as a usability aid, please reopen as an 'enhancement' and we'll look at doing this for the next release. I don't think it merits a lot of development effort at this point for 1.0. Do you agree?
Peter, I agree with your assesment that this is a usability issue and should not be critical path to getting 1.0 out the door. As you request, I'm reopening with priority of enhancement.
Peter im reassigning this enh request to you as you asked yesterday
