I want to display to user that a check box cannot be selected. I have made it greyed, but I wanted to show a cross (X) in the check box instead of default tick) on selecting.
Is there a way to show cross mark in the check box when it is selected.
SWT Widgets are OS dependent, meaning that the OS determines what they look like.
Consequently, there is no way of making a Button show a "X" without considerable coding on your side.
Your best option would be to create a completely new Widget based on Composite or Canvas and do the painting completely yourself.
Related
Many programs allow to freely rearrange buttons on gui. For instance Firefox and Chrome have "customize" option. How to do it in Java? Sure, I can bring GUI constrains to settings file and let user edit it, but this isn't user friendly.
Is there a better way to do this?
How to do it in Java?
There is no built in support, so you need to provide this yourself.
You might start with a configuration dialog. It could display a JList with the text of all the buttons in the order in which you want the buttons displayed.
Then the user would be able to drag each item in the list to a new location
When the user is finished they would click "Save" and you would store the order in a user properties file.
Then you would iterate through the list and change the order of each button on your panel.
Every time you start your application you would need to read the user properties file and perform step 4.
Check out the Drop Demo Project from the Swing tutorial on Drag and Drop. It will show you how to implement the JList so items can be dragged to a new location.
So basically you need to write the code yourself.
You can try creating a preference menu like you find in Chrome etc. This will provide for a familiar and user friendly method to do so. You can also go ahead and allow the use to change icon or size if you want to.
Another way could be that you allow the buttons to be dragable and resizable across a container and using events based on movements of the mouse to reorder the buttons in question.
In my app I dynamically create a list of buttons. The user should be able to click on them. A short click would select the buttom as the current item, while a long click should enter the editor for this item.
Now I wonder how I can determine and set the colors that i should use. My first idea was to simply read the background and textcolor and switch them, however I'm not sure if this would be really the appropriate way to do this. So I was wondering if there is a an appropriate way of how to retrieve colors.
Of course I could hardcode some colors, but I don't know what color scheme the user has set and they might not be visible in a good way.
Please note, that, since I have to create the buttons dynamically, I can not set it in the XML.
You could simply use a ToggleButton, so android will take care of marking a "clicked" button as selected.
Since ToggleButton is a View, it has a setOnLongClickListener(Listener)-method, which can be used to make the ToggleButton long-clickable.
I have a general question that is Java related.
I am writing an application that has a GUI menu. I am trying to change one part of the GUI menu based on the selection of a Radio button.
Do I need to:
Redraw the whole window or just update that part with:
setVisible(true)?
If I just use the statement from #1 above .. the GUI is fine -- until I move the mouse over it and then I see the previous button choice. What am I doing wrong?
Swing components have a repaint(), revalidate(), and doLayout() method. One of those should probably be able to redraw whichever pieces you want. However, doLayout is not something that you should be taking responsibility for, that's the layout engines responsibility.
You may also want to check out this post, the first response has a pretty good explanation, and links to an article with more detail.
In terms of the second part of your question, I'm not sure, but we may need to see some code to get an idea. Is the 'replaced area' actually being removed from the view?
..in my application the user select which device platform type they want top test (that choice is a set of two radio buttons on the left). When the user selects either Android or iOS, the center grouping of check boxes changes to reflect a group of android devices they can test or a group of iOS devices that they can test.
Put a panel in the 'center grouping'.
Use a CardLayout for the panel.
Add both iOS & Android controls to the panel with the card layout.
Flip between them as needed.
Call revalidate() on the top level component.
I'd like to create a set of buttons in a Java Swing application like you get in a typical tool palette in a paint program. That is, a set of small square buttons, each containing an icon, only one of which is pressed down, and when you press another button, the first is deselected. I've thought of a number of solutions and none of them seem very easy/elegant.
This sounds like a job for JRadioButton, but if you add an Icon to that, you still get the small circle, which is fairly space inefficient. I guess an option would be finding an alternative Look and Feel or painting code for JRadioButton.
Another alternative might be to add JButton to a ButtonGroup, maybe setting a JToggleButton.ToggleButtonModel as the model, but that doesn't have the desired effect, as the painting code for a standard JButton does not keep it depressed when selected. Possibly the JButton code could be modified to do this. Like making it painting "selected" the same way as "pressed".
A third alternative would be to use normal JButton's, and add a common mouse listener that keeps them pressed or not, and communicates the changes between the buttons.
Can anyone advise on the best way to achieve the aim please? A simple method I've missed would be best, but advice on which of these three alternatives would be best and pointers on how to get started would be useful too.
What about a plain JToggleButton in a ButtonGroup? It is not abstract, you can instantiate one with an Icon, and it stays depressed while selected.
See the SwingSet2 demo:
http://java.sun.com/products/plugin/1.4/demos/jfc/SwingSet2/SwingSet2.html
Click the second icon on the toolbar (the one twith the check box and radio button) then tab "Radio buttons". Then click on "Paint Border" on the right panel, under "Display Options".
Source code of the demo is under your JDK install dir, so for example on my PC it's under \jdk1.6.0_01\demo\jfc\SwingSet2\src
When to use this functionality and when to use the other? I personally thing that to switch between two different modes one should use a toggle button but i need to convince some people at work. any formal UI literature on the subject? thanks
I don't have references for you, but as a user I can tell you what I would expect.
I would expect the button to change images when you substitute one action for another because you entered a different mode. This is really relevant to save real estate in your toolbars, etc. For example you could have a dedicated play button and stop button with one always being disabled. Using one button saves space since at no point will both be enabled.
I would expect a normal depressed/unpressed toggle button when there is one mode that you either enable or disable. An example of this is "Toggle Mark Occurrences" in Eclipse. Unpressing that toggle button does not constitute a new action, but rather disabling an active mode.
I’m inclined to go with toggling buttons (buttons that “stick” depressed when “on”) rather than swapping images or label for a command button. I can’t cite any formal literature, but my impression is that it makes it easier both to anticipate the action produced by activation and to read the current state. The appearance and behavior of a toggle button is consistent with physical toggle button switches (like the Play buttons on older physical tape recorders). It’s also consistent with option buttons, check boxes, and state menu items, which all indicate their affirmative states through peripheral graphic design rather than labels. When the control looks like a command button (raised appearance), it’s labeled like a command button, the label indicating the action committed like any command button (e.g., “Connect”). When it looks like a state indicator (sunken, like a text box), its labeled suggest its current state (connected).
A single toggle button should only be used when there are simple True and False states to the process (e.g., Connected or not). Otherwise you need two or more “segmented controls” (abutting toggling buttons) to ambiguously indicate the alternatives (e.g., Forward vs. Reverse). This is analogous to using two option buttons in place of a check box.
Swapping labels to indicate changes in a button’s action can work if you use text labels that unambiguously indicate the action committed on activation, e.g., (“Connect” and “Disconnect”). While the Play/Pause button is a defacto standard, I’d otherwise avoid using an icon or image because it may confuse users on whether the label is indicating the current state or the state they’d get on activation (i.e., the opposite). There have been buttons that do one or the other, so the user can’t rely on experience. An image it not clearly a verb or adjective, so labeling with an image is tantamount to using text labels like “Online” and “Offline.” Even if done right, swapping labels has the disadvantage that the user needs to do a weird mental transformation to read the affirmative state (“It says I can disconnect, therefore I must be online now”). It can also mean you need a wordier label.