In my code, the UI has the following components:
JSplitPane:
pane1: JTable
pane2: JPanel with some texutal information.
I am listening to the row selection events on the table and then setting the divider location of the splitpane appropriately so that the textual information is visible for some row and is hidden for some other rows.
However, one problem with this approach is the switching to the divider location is very abrupt which gives very less time to the user to understand what happened.
Could you please let me know how to add in some animation so that the divider location switching happens slowly and gives user an idea that textual information is shown for a particular row selection and hidden for some other row selection.
I tried changing the divider location slowly from one value to the next on the AWT thread, but then the UI seemed to not respond properly.
Use a javax.swing.Timer to control the animation, as shown in this example. Note that the animation remains smooth as the frame is resized.
Related
I have written a Swing UI that has a JPanel with numerous controls and on the right hand side a few columns of JCheckBoxes. This is all handled by making the JPanel use a GridLayout. The problem I am having is that a given checkbox toggles it's selection status no matter where in it's grid "cell" you click in. Note, I am not using a JTable approach. The "cell" is just the rectangular area of the screen the GridLayout gave to the checkbox. It can be much bigger than the checkbox. I can't figure out how to make sure the checkboxes are only selectable when you click in the tiny box of the drawn control (not the big box of the "cell" that the checkbox is basically centered in). I've googled a lot and everyone talks about JTables. Again, I am not using a JTable. This issue is causing headaches for my users as they click on the application window and accidentally select an option!
The GridLayout forces all UI components to fill their cell completely, so the actual checkbox only gives the illusion that it's smaller than the cell it occupies. The solution here, as with many other more complex UI designs, is to use multiple layouts nested inside one another.
In your case, try putting all your check boxes inside a BoxLayout and using glue to space them as needed. This BoxLayout should be placed side by side with your GridLayout in another enclosing container (either a JPanel or your ContentPane -- I can't say for sure because you only gave a brief description of your UI with no code or illustration).
Play around with the idea of nesting layouts until you get something you like, and don't forget to try resizing your window to see what the layout manager does under the circumstances. The final appearance isn't always exactly what you imagine it will be.
I am using freeze, hide and showall on NatTable. When I perform freeze on any row, lets suppose 3rd row and hide that row, then the freeze indicator gets shifted to the previous row i.e 2nd row. And when I do showAll rows then the freeze indicator remains below the 2nd row. If I repeat the hiding of the freezed row and perform show all, at a point the freeze indicator will be above 1st row and then it disappears after repeating it once more.
Freeze performed on 3rd row
Hiding the 3rd row
Performing show all rows
Is it expected behaviour or an issue?
If it is an issue, how to resolve it?
The freeze state is based on positions. If you hide a row on the freeze border it is not possible to identify if the row that gets visible again was part of the frozen area or the non-frozen area. Currently the implementation interpretes that case as the new visible column belongs to the non-frozen area. This decision was made IIRC because typically the frozen area is non modifiable, means a user should not hide rows or columns interactively in a frozen area. At least for projects I worked in. That is of course discussable, but that is how it is right now. So if you need to support a fixed freeze border and allow hiding in the frozen area, you probably need to ensure via an event listener that on structural changes the freeze border stays at its fixed position.
I have a JScrollPane with JPanel on it. I have also many different components on JPanel (for example Labels, JTextFields, JTextAreas). These components are added programmatically (at runtime, on the user request).
JPanel uses SpringLayout. The program calculates preferred size of JPanel after adding components, because scrolling doesn't function properly without calculating. Adding components and calculating preferred size are part of my prepareGui() method.
The data displayed on components are periodically refreshed (in my refreshData() method, which is invoked by listener).
My problem: after refreshing, scroll bar always sets to fixed position (I don't know why). I want the scroll bar to stay in old position after refreshing.
I tried to find a place, where the scroll bar moves. I checked some values at the start and at the end of refreshData() method, but they was the same (they didn't change inside of refreshData()):
scrollPane.getVisibleRect().getX()
scrollPane.getVisibleRect().getY()
scrollPane.getVisibleRect().getWidth()
scrollPane.getVisibleRect().getHeight()
panel.getVisibleRect().getX()
panel.getVisibleRect().getY()
panel.getVisibleRect().getWidth()
panel.getVisibleRect().getHeight()
scrollPane.getHorizontalScrollBar().getX()
scrollPane.getHorizontalScrollBar().getY()
scrollPane.getHorizontalScrollBar().getWidth()
scrollPane.getHorizontalScrollBar().getHeight()
scrollPane.getHorizontalScrollBar().getValue()
scrollPane.getVerticalScrollBar().getX()
scrollPane.getVerticalScrollBar().getY()
scrollPane.getVerticalScrollBar().getWidth()
scrollPane.getVerticalScrollBar().getHeight()
scrollPane.getVerticalScrollBar().getValue()
Changing of layout manager didn't take effect.
I noticed one thing (I don't know if it has any meaning). When I set only preferred size (in prepareGui()), the scrollbar moves to the end. When I set also size, the scrollbar moves to strange, fixed position.
How can I prevent this?
The scroll bar should keep it's current position.
I finally found the answer here: https://stackoverflow.com/a/5230477/5694159 (thanks to Johan M) in the topic about JTextArea instead of JPanel.
When the refreshData() is calling in separate thread it works good.
I hope this question and answer will help someone.
I have a pane that contains image content which changes during scrolling. The content is properly updated via a scrollwheel event because I implemented a wheel listener which repaints the image before setting the new scroll value.
However, when the user drags the scrollbar handle with the mouse, the image content was not being updated during the manual drag-scroll. So I implemented a timer which grabs the current scroll value and repaints the content given the new scroll position.
This solution however (despite 10 millisecond adjustments) results in a jumpy scroll experience. The image moves (without the necessary image adjustments) and then gets corrected after-the-fact every 10 milliseconds.
I had originally tried an adjustmentlistener, but it only gets the event after the handle is released. How can I live-update the pane content during a jscrollbar handle drag BEFORE the scrollbar machinery starts to simply move my content as if it was a static image? Can I somehow give the scrollbar machinery a clue that content has changed or something every time it tries to redraw the content? Or can I disable the scrollbar's ability to move the image and just rely on my timer to do it?
I would recommend that you add a ChangeListener to the JScrollBar's model, a BounderedRangeModel, and then based on the value of the model as well as its maximum and minimum, change your image. If you're swapping images, the easiest way to do this is by swapping a JLabel's ImageIcon.
I have a Java swing application with a panel that contains three JComboBoxes that do not draw properly.
The combox boxes just show up as the down arrow on the right side, but without the label of the currently selected value.
The boxes will redraw correctly if the window is resized either bigger or smaller by even one pixel.
All of my googling has pointed to calling revalidate() on the JPanel to fix this, but that hasn't worked for me.
Calling updateUI() on the JPanel has changed it from always displaying incorrectly to displaying incorrectly half of the time.
Has anyone else seen this and found a different way to force a redraw of the combo boxes?
Can you give us some more information on how you add the combo boxes to the JPanel? This is a pretty common thing to do in Swing so I doubt that it's a JVM issue but I guess anything is possible.
Specifically, I would double check to make sure you're not accessing the GUI from any background threads. In this case, maybe you're reading the choices from a DB or something and updating the JComboBox from a background thread, which is a big no-no in Swing. See SwingUtils.invokeLater().