#6157 closed defect (fixed)
Problems with combo + editable=false
| Reported by: | rodo | Owned by: | team |
|---|---|---|---|
| Priority: | normal | Milestone: | 21.10 |
| Component: | Core | Version: | |
| Keywords: | preset read only combo | Cc: | francois.lacombe, KorneySan |
Description (last modified by )
As previously discussed in #409 and #6156 it'll be usefull to have a readonly attribute on combo fields.
These feature is clearly described in TaggingPresets and will be very interesting for external presets in some project like HOT.
Attachments (5)
Change History (37)
comment:1 by , 14 years ago
comment:2 by , 14 years ago
I've try these attribute, it works, but the value is not shown and I'm afraid it's not enough user-friendly for non techies people.
by , 13 years ago
| Attachment: | 6157.patch added |
|---|
follow-up: 4 comment:3 by , 13 years ago
| Description: | modified (diff) |
|---|---|
| Summary: | Add a readonly attribute in combo fields → [Patch] Add a readonly attribute in combo fields |
Patch attached. I don't see a reason why to use a custom ListCellRenderer for combo boxes …
comment:4 by , 13 years ago
comment:5 by , 13 years ago
There seems to be some problem when using a <combo> element with editable="false". This is somehow related to the dummy entry which is returned on index -1.
comment:6 by , 13 years ago
| Summary: | [Patch] Add a readonly attribute in combo fields → Add a readonly attribute in combo fields |
|---|
comment:7 by , 12 years ago
| Component: | External preset → Core |
|---|---|
| Keywords: | preset read only combo added |
What is the status of this ticket ?
editable=* is available for combo. Is it still broken ?
follow-ups: 26 27 comment:8 by , 12 years ago
Yes. There are some weird problems with combo + editable=false, like incorrect values displayed, correct value displayed only when clicking on the combo...
comment:9 by , 12 years ago
| Summary: | Add a readonly attribute in combo fields → Problems with combo + editable=false |
|---|---|
| Type: | enhancement → defect |
by , 10 years ago
| Attachment: | editno.png added |
|---|
comment:13 by , 5 years ago
| Cc: | added |
|---|
comment:14 by , 5 years ago
JComboBox height for an editable combobox is max(max(element_height), editor_height).
You can see that by diving down into combobox.reinitialize() > combobox.getPreferredSize() with IntelliJ IDEA.
On my machine this evaluates to max(14, 20) -> 20 for an editable combobox
But for a non-editable combobox this is just max(element_height) -> 14
That's why a non-editable combobox looks squashed.
by , 5 years ago
| Attachment: | force_larger_height_for_non-editable_combo_boxes.patch added |
|---|
here's a quick fix
comment:15 by , 5 years ago
| Summary: | Problems with combo + editable=false → [Patch] Problems with combo + editable=false |
|---|
comment:16 by , 5 years ago
Cannot reproduce the cut off. Probably, different "look and feel".
But I can reproduce the wrong display of values, probably, one reason editable is not present in defaultpresets.
comment:17 by , 5 years ago
I added the broken status and a link to the wiki, please, remove when fixed: wiki:TaggingPresets?action=diff&version=157
by , 5 years ago
| Attachment: | josm_6157_Preset_Debug.zip added |
|---|
condensed sample preset derived from /Presets/MastAndTower
comment:18 by , 5 years ago
See attached example preset where the screenshot was taken of.
OS: Debian 10 (buster)
Relative:URL: ^/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2020-03-30 07:18:28 +0200 (Mon, 30 Mar 2020)
Revision:16220
Build-Date:2020-03-30 23:25:33
URL:https://josm.openstreetmap.de/svn/trunk
follow-up: 20 comment:19 by , 5 years ago
That's a different OS. When the cut off issue is present, height is calculated with JosmComboBox.getPreferredSize() which calls to this.ui.getPreferredSize() and this.ui is an instance of WindowsComboBoxUI
comment:20 by , 5 years ago
Replying to shr:
That's a different OS. When the cut off issue is present, height is calculated with
JosmComboBox.getPreferredSize()which calls tothis.ui.getPreferredSize()andthis.uiis an instance ofWindowsComboBoxUI
Right, I have added the information.
comment:21 by , 5 years ago
@simon04: While you are in the flow ;) could you have a look at the small patch after comment:14?
comment:24 by , 5 years ago
| Milestone: | → 20.06 |
|---|
comment:26 by , 5 years ago
| Milestone: | 20.06 |
|---|---|
| Priority: | minor → normal |
| Resolution: | fixed |
| Status: | closed → reopened |
| Summary: | [Patch] Problems with combo + editable=false → Problems with combo + editable=false |
The patch did address only one problem but there is at least one more, see my comment (comment 18):
Donvip in comment 8:
Yes. There are some weird problems with combo + editable=false, like incorrect values displayed, correct value displayed only when clicking on the combo...
skyper in comment 16:
Cannot reproduce the cut off. Probably, different "look and feel".
But I can reproduce the wrong display of values, probably, one reason
editableis not present in defaultpresets.
comment:27 by , 5 years ago
I can confirm the height is fixed and the other problems (comment:8) are still there.
Also the text in the combo is bold when closed, which is not the case for "normal" combos and even for the ones with extended description.
comment:31 by , 3 years ago
Hello, it seems to me that there's still some bizarre behaviour with this. When I have "editable=false" in a combo, the first value of the list doesn't show up in the field even when clicked on it. Moreover, the value of one field can appear in all the other combo fields of the form. It's only a visual glitch though, because the real values for the keys are still there underneath.
comment:32 by , 3 years ago
@idrizza:
Please, create a new ticket, mentioning this one, with a complete description how to reproduce. Thanks.
Isn't editable property what you're looking for? I didn't actually try it but it's there and it should allow to only select value from list, not enter your own value in edit box.