I have a ListSelectionDialog. Something like this for instance:
Now what I'd like to do is to have some items permanently selected and disabled (Basically I'd like to indicate to the user that these are part of the "core" selections and are not optional).
Is there a way to do this?
Unfortunately this dialog does not provide the functionality that you need. It uses the JFace CheckboxTableViewer to display the items, which does not support the "disabled" state of the check boxes very well (as of Eclipse 3.5). Furthermore this dialog is not intended to be subclassed.
the viewer used by this dialog is the CheckboxTableViewer.
You can try to add a checkstatelistener to cancel the unselection of the "core" selections.
Also you can use the method setGrayedElements to make them visually disabled.
I am not sure if this will give the wanted behaviour though.
Related
I'm trying to detect ChoiceBox item selection. I read this post and I know that it is possible to do, this way:
choiceBoxObject.getSelectionModel().selectedIndexProperty().addListener(myChangeListenerObject)
also I saw this sentence in Documentation for ChoiceBox class which confirms code above:
ChoiceBox item selection is handled by SelectionModel As with ListView
and ComboBox
Another solution came to my mind and I was wondering is there anything wrong with it? why nobody mentioned this way? What is the difference between these two approaches?
choiceBoxObject.valueProperty().addListener(myChangeListenerObject);
There's nothing wrong with using the valueProperty, and in fact for simply reacting to changes in the selected value, it's probably the preferred solution.
The documentation is just indicating that there is a complete SelectionModel underlying the selection of items. This has a far richer API than simply knowing what is selected: there are selectNext(), selectFirst() methods, etc etc. So if you needed to programmatically change the selection there is a rich API available. As also pointed out in the documentation, you can even replace the selection model with a different implementation, though use cases for this are likely to be (very) rare.
I'm using the Eclipse AWT framework, and I've got a combobox.
I've set the visible amount of items in the combobox to 0, so that clicking the dropdown doesn't show anything (even though the box is populated).
I have an AutoCompleteField on the box, so that anyone typing into the combobox sees the Eclipse-style AutoCompleteField. This works perfectly.
However, I'd like to be able to trigger the AutoCompleteField to appear in certain circumstances, and not just when the user starts typing. For instance, I'd like it to appear when the user clicks the dropdown triangle, so it's like the Eclipse-style AutoCompleteField appears instead of the normal drop-down.
Unfortunately, the AutoCompleteField exposes NO useful methods, and I hardly understand how it works.
How can I get it to appear at whim?
I assume you mean the SWT / JFace AutoCompleteField (AWT is the old Java GUI).
AutoCompleteField is only intended for the simplest use of the auto complete, for anything more complex you need to use the lower level classes.
This is what AutoCompleteField sets up:
Control control = your control
IControlContentAdapter controlContentAdapter = your control context adapter
String[] proposals = your proposals
SimpleContentProposalProvider proposalProvider = new SimpleContentProposalProvider(proposals);
proposalProvider.setFiltering(true);
ContentProposalAdapter adapter = new ContentProposalAdapter(control, controlContentAdapter, proposalProvider, null, null);
adapter.setPropagateKeys(true);
adapter.setProposalAcceptanceStyle(ContentProposalAdapter.PROPOSAL_REPLACE);
It is the ContentProposalAdapter that can open the assist as required using the openProposalPopup() method - this is a protected method so would need to use a class derived from ContentProposalAdapter to use it.
ContentProposalAdapter also has parameters for a KeyStroke to activate the assist and a set of auto-activation characters.
I'm using Swing with default UI (without any special skins).
How to make some buttons/textfields more bright or more pale? It means the user is expected/not expected(although not completely disabled) to press the button.
Example: user had changed a field - "save" button becomes more bright (for example, green). Status is "compilation failed" - "execute" button is pale (although user can still execute previous version of something). User filled in "password" field - he expected to fill in "password confirmation" - so it becomes bright.
I have: {normal, disabled, invisible}
I want: {bright, normal, pale, disabled, invisibe}.
How to make it properly, without hacking with drawing things, with separation of content and presentation? I want it to look well even if user overridden colour settings in the system. Should I use some other toolkit?
I expect something like I set hints for the given control, and then skin read hints and applies additional look and feel options (such as brighter background) without me dealing with concrete colours. May be one skin will use other background and some other skin will use other font for this effect. Like in enabled/disabled case, but more flexible.
Just use setBackground() to change the color to match the component's status. Maybe even create a Custom Component that has a method to change the status and it knowns which color matches that status.
I'm not sure that I see the value in what you're trying to achieve from the examples that you've provided. Is it possible that users could get confused about how the application works if you give them functionality that differs from their expected user experience?
If the user hasn't yet changed a field, the save button could be completely disabled. What's the value in being able to save if there have been no changes made. Alternatively, if you still dead set on making this distinction, can you do it in another way? Perhaps a visual queue, an icon next to the field that's changed, cell highlighting, or a * appended to the end of the text on the window name to show that there are unsaved changes in a window, perhaps?
From a purely user experience perspective, I don't think you want to go messing with the way people expect applications to behave unless you have a really good reason!
Sorry for the odd choice of words for the title, however, "border" seems to be the inappropriate term. While it is true that the visible line surrounding an icon in a JToggleButton can be made invisible by using setBorderPainted(false), the same is not true for JCheckBox and JRadioButton.
I can not use the JToggleButton and therefore need to use either the JCheckBox or JRadioButton (or some derivative of JToggleButton I am not aware of), but need the square or circle, respectively, to be non-visible when there is no icon on the button. Also, using setVisible(false) eliminates the button from the layout, however, I need the space to be reserved and not have the component layout change (using GroupLayout).
Any suggestions? Am I going to have to create a custom renderer? I will be looking at that in the mean time.
The route into this would be through customising the look at feel by changing some of the UI properties in the UImanager (the sort of thing that allows you to make simple tweaks with fonts and colours and presumably the images used for the checkboxes or radiobuttons) -- but it's many years since I last did that sort of thing and can't remember the details.
A little Googling turned up this project to inspect current property values, so might at least help with indicating the right part of the APIs to be looking at.
You have to choices here:
1) Customize Look and Feel as described in previous entry.
2) Create your own custom controls by inheriting from existing ones and overriding component painting.
I found a cheap and easy (read hack) for this. I created an empty transparent icon and used it when I didn't want any item to be displayed.
I am working on a project that is using a JTable to display, among other things, a column of dates. We needed validation for the user input for dates, so I have implemented a combination of masking for format validation and parsing for actual date validation. I have done this using a custom CellEditor for the date column.
Inside my MaskedCellEditor, I have a JFormattedTextField. I setup the masking for dates. Then I add an InputVerifier to allow for actual validation. My InputVerifier implements verify() to check: 1. textField.isEditValid() 2. DateValidator.ValidDate(). If either is invalid, verify returns false and the InputVerifier locks the focus into the text field (the cell editor) and a small message dialog is displayed reminding the user of the date format.
The error message is a small, undecorated, non-modal, non-focusable JDialog that pops up underneath the cell being edited. It disappears on a keypress or a successful date verification. It is working great except for a small edge case.
If the user selects a menu button on the top of the application while an invalid edit has popped up the dialog, it switches screens, destroying everything currently on the screen (including the table). However, since the dialog is being shown and a keypress/successful edit has not occurred, the dialog is never hidden. It remains visible in a completely unrelated context on a different screen. Once the user has switched off the screen with the table, there is no way for the user to get rid of the dialog.
I have debated throwing either a Timer and/or a MouseListener on the dialog itself that would cause it to disappear, but I feel that I am ignoring the actual problem. The dialog is never being disposed of and I am pretty sure its because it is still set to be visible and it is preventing the garbage collector from getting rid of it.
I have a Cleanup method on the panel holding the JTable, but I cannot find a good way to reference the dialog (a component of the InputVerifier) in order to get rid of it. The dialog is pretty far removed from the table's parent panel. (Panel -> JTable -> CellEditor -> JFormattedTextField -> InputVerifier -> JDialog)
Any ideas on how to force the dialog to be hidden when the table is destroyed? If you need more details, let me know. I'm trying not to get you guys bogged down in the details, but there is a lot going on.
As a first thought, can you not go down the listener approach. If you have a closeErrorDialog() type method that gets called when upon successful valdiation, then you can also call it when a menu action is selected.
As an alternative, perhaps you could control the transition from menu to menu in some way, and create a "cleanup" method which will close down any exisiting error dialogs. This would allow for any other actions that need to take place when changing menus, to happen in the same place.
Just a couple of quick ideas of the top of my head. Hope they are along the lines of what you meant
Many people will vote me down for saying this, but it sounds like your dialog should be modal so that users can't switch away from it without dismissing it first. Or at least disable the menus that allow people to switch away while this dialog is displayed.