I have a TitleAreaDialog with a TableViewer which allows the user to select a row from the table. The problem is, that the content of the table may change over time. I would like to implement a refresh behaviour commonly found in browsers (e.g. by pressing F5 the content of the table should refresh).
Below is a screenshot which should hopefully make the scenario a little clearer:
It looks like there is a possible solution in this question, but I think it is flawed for several reasons:
The listener isn't properly detached (e.g if I reopen my dialog I have two filters on my Display)
It doen't add the listener to the TitleAreaDialog or a Widget where I believe it belongs from an architectural point of view.
I would like to avoid manual listener-attaching/detaching (e.g. the listener should get disposed together with the TitleAreaDialog)
Long story short: What is the proper way of adding a KeyListener to a TitleAreaDialog (or Dialog in general) without using the filter mechanism as described in the aforementioned question?
I know that this question somehwhat fails in the SSCCE department, but any pointers into the right direction are highly appreciated.
Adding a Listener for key events is a tricky thing. You want the Listener to be fired when none of the contained Controls has focus and you want it to fire even if a child of the Dialog has focus.
There are basically two solutions to this problem:
The obvious choice: Use addFilter when the Dialog is created and removeFilter when the dialog is closed (in close()).
Create a Listener for SWT.KeyUp and add it to ALL children of the Dialog. This is necessary for the event to fire independent of the focus control.
I prefer solution 1, since it's less clutter and SWT will take care of everything (well, except for adding and removing the filter). Adding a Listener to all child controls is nothing you really should do, but it would do the job as well.
If you don't want to add and remove the filter each time, create a subclass Dialog or TitleAreaDialog that does it once, and reuse it by subclassing again.
If adding and removing the filter is too much hassle in general, then I'm afraid there is no easier solution.
Related
Current GUI with the buttons in question
My problem is that I need to prevent the user from clicking the Next Button when specific conditions are not met, I thought the best way for this would be to overwrite the onClickEvent for this Button but it seems impossible to the required field access to these buttons.
I looked through the available methods in the documentation as well as the source code but I was not able to find anything which would help to achieve my goal.
I have a toggle JButton that, when clicked, either installs or uninstalls some listeners elsewhere (but that's somewhat irrelevant I believe, as it could be just about any code that you don't want executed any number of times in a row, hence, the toggle, you click it once, it does something, you click it again, it undoes that something or whatever). My problem is that I have several instances of this button (or more specifically, several instances of its parent JPanel). This restriction is not my doing and I cannot prevent this. Basically, I'm left with a situation where the user can toggle the button "on" a bunch of times in succession, and needless to say, this screws things up for me.
The buttons themselves are not all visible to the user at once, only one can be seen at any given time. I tried using a component listener, but componentHidden() and componentShown() are never called.
I tried making the button a singleton, but that just had this weird effect of only displaying the button on the last panel it was added to.
I'm kinda stumped. The behaviour I want is simple: Multiple instances of this toggle button that sync their selected state. Ideas?
P.S. I suppose I could construct a list of the instances and update all the other's state when one of them is clicked, but I wonder if there's something simpler out there.
Thanks
Yes, the buttons must all be distinct, but they can either share the same ButtonModel or the same Action. Usually, I try to have them share Actions by creating a single Action that extends AbstractAction, and use it to set the Actions of all the same buttons.
No big reveal here. I solved my problem using my own suggestion, that is, I simply kept a list of all the instances of the button and set their states when any one of them was clicked in an action they all share.
I'm making a map editor using java swing for my tile based java game. the swing application has two major components, the "upper" component is the game map preview, and the "lower" component is modifyable properties of the map, like its height and width.
Currently the user types in to a jtextfield for the map width, then I use a change listener to set that value to the GameMap object. The GameMap object when changed fires a notification event to GameMapListeners, the primary listener it has is the preview display of the map inside the swing application.
This lets the user change the map width and instnatly see the results in a preview pane.
Now I want to go to the other way. I want the user to be able to click and drag the edges of the map in the preview pane, but then the results need to then be sent to the properties panel so it shows the updated width value.
This is where the problem is, if I update the jtextfield it'll fire a change event, which would update the GameMap and update the preview display, and then that would fire an event that changes the jtextfield again (so on and on until the program crashes due to stack overflow)
Are there any kind of design patterns i could use instead, or is there some common way to solve this issue?
In this type of case, you have at least two choices...
You Could
Remove the listener to the other component when you want to trigger a change, adding it back after you've raised the event...
You Could
Change the state of a flag to indicate that you should ignore any changes that might come in, resetting after you're raised the event...
Which one you choose will depend on how much code you want to add and how readily available the reference to the listeners in question are (ie, if you don't have a reference to the listener you want to remove, it's kind of hard to implement)
If I update the jtextfield it'll fire a change event, which would update the GameMap and update the preview display, and then that would fire an event that changes the jtextfield again (so on and on until the program crashes due to stack overflow).
When you have a situation like this, you can temporarily remove event listeners, fire the change event, and add the event listeners back. Yes, this is as much of a pain as it sounds, but it's a good way to prevent the stack overflow.
You can see a detailed explanation as well as a working example of managing event listeners in my Sudoku Solver Swing GUI article.
You can use action events for a JTextField. Action events don't trigger when you change the component programmatically.
I have a JPanel with a set of items (for example combo boxes and text fields). Some action listeners are implemented on those items to register user updates.
If the user selects a value in a JComboBox (for example), the action listener captures the event. The corresponding underlying bean method is called and the panel is refreshed. Changing can have an impact on other fields displayed in the pane.
The problem is that when the panel is refreshed, all listeners are triggered, and they call for a refresh themselves. This leads to an infinite loop.
How can I avoid this? I can't get rid of the listeners, because I need to capture user updates, but I don't want these to fire when I am only refreshing the panel content.
One option is to have a central boolean value or some indicator that each listener can check to prevent the chaining of events.
Another option is to not refresh the field if the value does not change. That way each component is updated at most once per refresh.
I can't get rid of the listeners, because I need to capture user updates, but I don't want these to fire when I am only refreshing the pane content
Then remove the listeners, refresh the pane content and then restore the listeners. This way the listeners only fire when a user change is made.
I think that if your problem is in combobox it just points to a bug. Really, if user changes the value of the combobox, that somehow triggers refresh of the pane the value of the combo box should not be changed second time! So if it is onValueChanged() (or something like this) it should not be called at all when pane is being refreshed.
But if for some reason it happens you can verify whether the old and new values are the same and exit the listener.
If this still does not help I'd suggest you some non-standard solution: try to investigate the stack trace into the listener. Can you identify whether the listener was called as a direct reaction to user's action or after the pane refresh? In this case you can create utility method and put it in the beginning of all relevant listeners.
My applications also suffered from this problem, and solution with the flag, that I should check in every listener and enable/disable in code, feels not very good for me. I always forgot to set this flag to true/false in necessary places.
That is why I decide to implement another solution.
I just subclass all default swing components that I am using often, and implemented custom ValueChanged event that I fire after mouse/keyboard/clipboard/etc events. Now I am always know, that if ValueChanged event is fired, it means, that value was issued by user, not by code. Event handling in this way much more cleaner. This solution solves my problem.
I'm new to GWT, and I've been reviewing the MVP implementation which uses the rpcService and the eventBus. I was wondering how a tab panel can be implemented such that each tab has its own sub-view. I have been waffling between making a custom widget that derives from a panel, or to figuring out how to make a presenter use another presenter, or to make a compound presenter class which handles it all for me.
Does anyone have advice on how to separate the functionality for each tab as opposed to keeping the implementation within one view/presenter pair?
I was in the same situation, but decided to change my implementation to simulate a TabPanel. If your views and presenters don't need to interact with each other (e.g. dragging something from one tab to another) then I think it'll be easier to separate functionality by loading your View into a shared SimplePanel. You can simulate the tabbed portion of the TabPanel with a widget that listens for PlaceChangeEvents (to change the highlighted tab) and sends goTo commands to the PlaceController your app is using (to handle clicks on the different headers).
It took a couple of hours to implement this, and the resulting code is much cleaner. My initial attempt involved listening for PlaceChangeEvents and then calling the appropriate tabPanel.selectTab() function, but trying to figure out how to start and stop the presenters for the different tabs was too jumbled up - like you suggest, you'd have to implement your own compound view model.
I solved this without faking a main tab, but using the one provided with GWT's basic SDK. I did this by:
Add an ArrayList of Presenters to the MainTabPresenter
Constructed each tab's present plus view within the 'go' method of the MainTabPresenter
Called 'go(null)' on each of the tab presenters.
Handled the null situation on each.
Implemented a method in the MainTabView to add the tabs to the DecoratedTabPanel
It all works like a charm. The MainTabPresenter so very thin, and allows for complete implementations of View/Presenters to be written into their own files.