Different screen readers (VoiceOver, NVDA, Narrator) ignore my code on different locations of the UI. The method getName(AccessibleEvent e) gets called and supplies the correct result, yet it sometimes is ignored by either VoiceOver, NVDA or Narrator. This behaviour seems so random.
The following case is working with VoiceOver, yet NVDA completely ignores it.
Accessible accessible = getControlForAccesible().getAccessible();
accessible.addAccessibleListener(new AccessibleAdapter() {
#Override
public void getName(AccessibleEvent e) {
e.result = getTextForScreenReader();
}
});
This code is inside a subclass of Composite which acts as button in my case. So there is no subview inside this button. I draw the text with the drawText-method of GC. It also attached a tooltip to the composite which is ignored as well.
No matter which of the methods of the AccessibleAdapter i use, still the same result, whereas on some other parts of my code, those different methods supply different results.
Does anyone had similar problems?
Related
So my questions is pretty basic. I have a code of 7-8 lines which does the exact same thing, gets the text of 4 Text Panes and updates them to a 5th Text Pane, now thing is whenever any change is made to one of those 4 Text Panes, this 5th text pane will be updated, so I have to use that same 7-8 lines of code on all the ActionPerformed methods of those 4 Text Panes. Is there any way to make a method somewhere which has those 7-8 lines and just call it in all those 4 Text Panes.
I just read you're using the NetBeans graphical editor and it auto generated those methods for you.
The easiest solution would be to create a method yourself somewhere all the other methods can access and then just call that in all the ActionPerformed()s.
// use the same parameters as currently given to your ActionPerformed
public void ActionPerformed1(Event param) {
onTextPaneUpdate(param);
}
public void ActionPerformed2(Event param) {
onTextPaneUpdate(param);
}
public void ActionPerformed3(Event param) {
onTextPaneUpdate(param);
}
// use the same parameters as currently given to your ActionPerformed
public void onTextPaneUpdate(Event param) {
// your code for all methods
}
If the ActionPerformeds are in different classes / files, you can just create your own class e.g. MyTextPaneUpdateListener and declare this onTextPaneUpdate method static, this way you could call it from everywhere without having any object to call it on. (MyTextPaneUpdateListener.onTextPaneUpdate(params...))
In case this doesn't help you please provide example code that you're currently using as the answer heavily depends on your current implementation.
I am having trouble understanding the undo/redo functions using UndoManager, and integrating it with the MVC model.
I am not sure where to put the various methods(in model, view or control)
and I am still not sure how to use the undo manager.
My control class implements UndoableEditListener
It creates:
private UndoManager manager = new UndoManager();
and in:
public void actionPerformed(ActionEvent e) {
if (e.getActionCommand().equals("Undo")) {
try {
manager.undo();
} catch (CannotUndoException ex) {
ex.printStackTrace();
}
}
}
I understand up to here, but the rest I am not sure what to do. I know I will have to add more in the model and view class, but not sure where.
DO I have to have the following classes?
public class UndoAction extends AbstractAction {}
public void undoableEditHappened(UndoableEditEvent e) {
I am simply placing an integer number in a textfield, and then I want to be able to undo this.I set the number in the textfield in the view class.I want to acheive this the simplest way possible, no fancy coding! This is a minor part of my assg but I just cant get it working!!
==========================================================
Here is a more detailed description of my code, maybe it will help:
I have a model, view and control package.
Contol has:
ButtonGUIControl.java, which implements both
ActionListener and
UndoableEditListener.
final UndoManager manager = new UndoManager();
In the actionPerformed method, it calls
if (e.getActionCommand().equals("Undo")){
try {
manager.undo();
}
and in:
public void undoableEditHappened(UndoableEditEvent evt) {
manager.addEdit(evt.getEdit());
}
In the View:
Grid.java , which extends JTextField will add the following, wherever it needs to display a number on the GUI:(model is simply an instance of my Model class)
getDocument().addUndoableEditListener(new ButtonGUIControl(model));
Could it be because the UndoManager is being created in a different package? I really have no idea how to debug this anymore!!
I could post my entire code if that helps. I guess Im not sure how to integrate this with my mvc model structure.
Take a step back for a second. The whole idea here is that a user will use your app and will make a series of changes to something. A text editor is a good example. You can insert characters and lines, delete them again, replace text with other text, scroll the text, etc. In order to support this with MVC you have a model that holds state and a View that displays it.
Your first instinct might be to have the view directly access the model, and then refresh the view every time the user makes a change, but it's very hard to undo those changes with that implementation. Instead, you encode every kind of change the user can make in classes that are able to perform that change and can later undo that change.
For example, an action that inserts text would be implemented by a class that knows the character offset of the insertion point and the string of characters that is to be inserted. The perform action would insert the string at the offset and the undo action would remove the right number of characters after that insertion point. You'd have a different class that would handle deletion, another to handle scrolling etc.
Every time the user takes some action, the view would construct one of these UndoableEdit classes and would tell the instance to run itself (redo()). Once executed, you put that UndoableEdit at the end of a list of UndoableEdit instances that represent all of the actions the user has taken so far. This list makes it very easy to support any sequence of undo requests, redo requests and actual edit actions (resulting in more UndoableEdit's being put on the list).
So back to your question. If your app needs to support undo and redo, then you'll need to implement an UndoManager which simply manages the list of UndoableEdit's and performs undo and redo as necessary. You also have to implement a whole bunch of UndoableEdits, one for each kind of thing your user will do against the UI. As for a listener, I can't see that you really need to do that one.
If you need only simple undo/redo, you can use UndoManager as it is, you don't need to subclass or customize it in any way.
JTextField (more specifically its model, the Document) has some built-in support for undo, which means you don't need to write UndoableEdit implementations either, the UndoableEdit objects will be automagically created for you (actually AbstractDocument.DefaultDocumentEvent implements UndoableEdit).
Full simple working example is here
I've subclassed Swingx's ComponentProvider to provide JButtons but on some lines of my JXTreeTable, I don't want to show any button. The final "result" I want is to have an empty cell, like what I get when showing an empty text in a column for which I haven't set a provider.
Is it possible to hide the rendered component on certain rows (depending on the value for example)? Setting setVisible(false) on the rendered component in format() or configureState() doesn't work.
Is it possible to subclass ComponentProvider to provide different several types of Components? If yes, how would that work?
Where can I find some examples of the possibilities that the ComponentProvider offers and a clear explanation of which method does what (for example, I hardly understand the difference between configureState() and format())?
EDIT
Is it possible to prevent a JButton displayed in a JX(Tree)?Table to be as wide as the cell?
If I create another highlighter, can I use another predicate (ROLLOVER or something) to change the cursor? The cursor change to a hand (over a link) even if the button is hidden.
Many thanks!
Interesting :-)
generally doesn't work because the CellRendererPane doesn't respect the component's visible property - it stamps it always. BUT: can work in SwingX if the actual provider it wrapped into a WrappingProvider and then that wrapper's component is set invisible.
a snippet, just as proof-of-concept
table.getColumn(1).setCellRenderer(new DefaultTableRenderer(
new WrappingProvider(IconValues.NONE, new ButtonProvider(), false) {
#Override
protected void configureState(CellContext context) {
super.configureState(context);
rendererComponent.getComponent().setVisible(context.getRow() != 5);
}
}
));
On the other hand, the provider is not the place for plugging in custom context-dependent configuration. That should be done in a Highlighter, as f.i. in
AbstractHighlighter highlighter = new AbstractHighlighter(HighlightPredicate.EVEN) {
#Override
protected Component doHighlight(Component component,
ComponentAdapter adapter) {
((WrappingIconPanel) component).getComponent().setVisible(false);
return component;
}
#Override
protected boolean canHighlight(Component component,
ComponentAdapter adapter) {
return component instanceof WrappingIconPanel;
}
};
table.addHighlighter(highlighter);
Which doesn't work as expected (the button is always hidden) because is not one of the properties which are guaranteed to be reset in the provider. Nothing prevents custom providers to extend those guarantees, like
table.getColumn(1).setCellRenderer(new DefaultTableRenderer(
// custom wrappingProvider which guarantees the reset of visible
// property of the wrapped component
new WrappingProvider(IconValues.NONE, new ButtonProvider(), false) {
#Override
protected void configureState(CellContext context) {
super.configureState(context);
rendererComponent.getComponent().setVisible(true);
}
}
));
Now the highlighter can fearlessly change the visible based on context. A slight visual glitch: the WrappingIconPanel always leaves some space for the icon, even if there is none - not quite sure why that happens or whether it would be safe (in SwingX) to remove that spacing (the wrappingProvider originally is meant for use in JXTree, it's not installed by default because there are still issues with ComponentOrientation).
(2 in the question) not supported, the componentProvider is designed to return the same single component configured with the exact same properties on each call
(3 in the question) cough ... no, nothing but the sources and examples (in the demos and the test packages)
Edit (to answer the edited part of the question)
no, with the current WrappingIconpPanel: it does use a Borderlayout which - as we all know :-) doesn't respect max size. Using a BoxLayout would but had issues that I don't fully remember. Nevertheless, that would be the place to tweak, so that the button's max would be respected
hmmm ... not entirely sure how you implemented the cursor change. Assuming that it's in your ButtonProvider: implement the isRolloverEnabled to return true/false depending on whether it is visible or not Edit-in-Edit doesn't work. Don't know why, could be that this is a bug in rollover-dectection and/or handling in WrappingProvider
Off into the weekend now :-)
I started to look into using GWT in combination with UiBuilder. I'm a bit puzzled about how you can use the #UiHandler(..) directive to make simple event handle code as written down in the GWT documentation:
#UiHandler("button")
void handleClick(ClickEvent e) {
Window.alert("Hello, AJAX");
}
In this case the method handleClick is used.
How do you know for each GWT widget what methods can be created with #UiHandler? For some you can also create a doClose() method.
But what can you use with, for instance, a ListBox to get an event an item is selected? Where in the documentation can I see this?
The parameter you pass to the #UiHandler annotation is the name of the appropriate field you want to assign that *Handler. So, in this case you are assigning a ClickHandler to a Button button (actually, we just know the field's name).
As for how this exactly works - it's part of GWT magic :) My guess is that, just like any other UiBinder related code (I think there was a presentation on Google IO, that showed the code that UiBinder generates), at compilation time the compiler figures out what goes where. In this example: we have a Button button, and we have a #UiHandler annotated method that has a ClickEvent parameter -> that must mean it's a ClickHandler (notice that the method's name doesn't matter). So let's add some code at compile time (in the constructor, probably) that adds that handler to the button. If you are interested in a more comprehensive answer - check out the source :D
But what can you use with, for
instance, a ListBox to get an event
an item is selected? Where in the
documentation can I see this?
In the GWT API reference. In this case, you are probably looking for ListBox.addChangeHandler. But you usually won't find #UiHandler related code there - that's because it would be redundant - you always construct the #UiHandler methods the same way:
You check the *Handler that you want to add, say ChangeHandler
It has a void onChange(ChangeEvent event) - so, your method needs a ChangeEvent parameter and should look like this:
#UiHandler("listBox")
void whateverName(ChangeEvent event) {
// ...
}
Probably your problem is in your onModuleLoad method:
public void onModuleLoad()
{
HelloWorld helloWorld = new HelloWorld("BOTAO");
// Using this way #UiHandler will not work
//Document.get().getBody().appendChild(helloWorld.getElement());
// correct way
RootPanel.get().add(helloWorld);
}
i think this not a specific problem to me; everybody might have encountered this issue before.
To properly illustrate it, here's a simple UI:
As you can see, those two spinners are controlling a single variable -- "A". The only difference is that they control it using different views.
Since these two spinners' displaying values are synchronized, cyclic event shows up.
If i change the top spinner, "A" will be changed and the bottom spinner's value will also be updated accordingly. However, updating the bottom spinner's call (such as setValue) will also trigger another event instructing the top spinner to update based on the bottom spinner's value. Thus creates a bad cycle which can eventually cause a StackOverFlow exception.
My previously solution is kinda cumbersome: i placed a guarding boolean to indicate whether the 2nd updating call should be performed.
Now i'd like to ask "how can i handle such situation elegantly? ( in general, not specific to spinners )"
thx
Update:
Since i've got 2 answers suggesting me to utilize the observer structure, i have to say something about it.
Like what i've said, it's great but far from being perfect. Not only because of its inherent complexity, but also Its inability to solve the problem.
Why? To see the reason, you must realize the tight coupling of the View and Model-Controller in Java Swing. Lets take my spinner UI for an example. Suppose the variable A is actually an Observer object. Then, after firing the first state change event from the top spinner, the Observer "A" will update its value and fire a PropertyChange event to notify the bottom spinner. Then comes the 2nd updating which updates the bottom spinner's View. However, changing bottom spinner's view inevitably triggers a redundant event that will try to set "A"'s value again. Afterwards, the deadly loop is fully constructed and the stack overflow will be thrown.
In theory, the Observer model tries to solve the direct cycle by introducing 2 independent feedback paths. The chained updating odds(in event-response codes) implicitly form a bridge connecting both paths, making a cycle again.
Going back to Model-View-Controller, think about what your Model is, and what your View is.
In your current implementation, you have two models (one for each Spinner control), and they're being synced through the View layer.
What you should be doing though is share the same backing model. For the spinner with a subtracted value, create a proxy to the original model. ie:
class ProxySpinnerModel implements SpinnerModel {
getValue() { return originalSpinner.getValue() - 10 }
setValue(v) { originalSpinner.setValue(v+10) }
}
spinnerA = new JSpinner()
spinnerB = new JSpinner( new ProxySpinnerModel( spinnerA.getModel() ) )
Now, you don't need to add listeners, since they're both working off the same model and the default implementation (the originalModel) already has change listeners which it fires to the view.
Problem Solved
I've got many different suggestions. Particularly,
i want to thank Marc W & Reverend Gonzo. I'm here to make a summary for these ideas; this can save your time navigating thru big chunk of texts.
This problem can be easily bypassed if you carefully decouple the View and Model-Controller.
The dead cycle is caused by dependent writes: write_1 -> write_2 -> write_1 ->.... Intuitively, breaking the dependency can solve the problem elegantly.
If we look into the problem in depth, we can find updating the corresponding views doesn't necessarily involves an external write call. Actually, a view only depends on the data it's representing. Known this, we can then re-write the logic as follow: write_1 -> read_2 & write_2 -> read_1.
To illustrate this idea, lets compare the 3 methods mentioned by different posters:
alt text http://www.freeimagehosting.net/uploads/2707f1b483.png
As you can see, only the proxied view can solve all the dependency thus it's the generic solution for this knid of problem.
In practice, it can be implemented as something like this (in your event-response codes):
setValue(newValue);
anotherSyncUI.parse(); // not anotherSyncUI.setValue() any more
anotherSyncUI.repaint();
No more loops. Solved.
It's a bit complicated, but you could make A actually be an object that's observable. Both spinners (or whatever needs to update itself based on A's value) would then observe A. Whenever A changes, the spinners (or again, whatever object) update themselves to reflect the new value of A. This decouples the spinners' logic from one another. In your example here, the spinners should not be coupled to one another because they really have nothing to do with each other. Instead, they should both simply be bound to A and take care of their own view updating individually.
Whenever the value in the first spinner is changed, you would simply update A's value to match it. Whenever the value in the second spinner is changed, you would of course add 10 to its value before assigning it to A.
Update
In response to the update to your original question, my answer is that the spinners do not listen to one another's change events. Have a separate event handling method for each spinner. A user clicking the up or down arrows in the spinner generates a different event than calling setValue on the spinner programmatically, correct? If the spinners are completely independent of one another, there will be no infinite loop.
E.g. for the second spinner, calculate A-10 and then compare it to the current value of the spinner. If it's the same, do nothing, ending the infinite loop. Similarly for the first spinner.
I think there are also ways to update the spinner's model in a way that doesn't fire an event, but I don't know them off the top of my head.
Use a single SpinnerModel for both JSpinners. See the following code:
Note that the call to setValue() is only made once each time a new value is defined by one of the JSpinners.
import java.awt.BorderLayout;
import javax.swing.*;
public class Test {
public static void main(String[] args) {
JFrame jf = new JFrame();
SpinnerModel spinModel = new MySpinnerModel();
JSpinner jspin1 = new JSpinner(spinModel);
JSpinner jspin2 = new JSpinner(spinModel);
jf.setLayout(new BorderLayout());
jf.add(jspin1, BorderLayout.NORTH);
jf.add(jspin2, BorderLayout.SOUTH);
jf.pack();
jf.setVisible(true);
jf.setDefaultCloseOperation(3);
}
}
class MySpinnerModel extends AbstractSpinnerModel {
private int _value = 0;
private int _min = 0;
private int _max = 10;
#Override
public Object getNextValue() {
if (_value == _max) {
return null;
}
return _value + 1;
}
#Override
public Object getPreviousValue() {
if (_value == _min) {
return null;
}
return _value - 1;
}
#Override
public Object getValue() {
return _value;
}
#Override
public void setValue(Object value) {
System.out.println("setValue(" + value + ")");
if (value instanceof Integer) {
_value = (Integer) value;
fireStateChanged();
}
}
}
It seems you're really observing the wrong thing. From the example given I presume what you want to detect is the user's actions on the controls, not the changes in the values themselves. As you've outlined, changes in your model are reflected in the values of the spinners, and it is this which forms the infinite loop of events.
However, diving further into the UI implementation may not be the answer you want. In that case I'd say the best you can do is either your current guard solution, or to better extract the logic into your model (similar to what Marc and William have said). How that can be done will depend on the 'real world' model behind a particular implementation of the provided puzzle.
As a rule, your model should not be defined by your GUI. Ie, the SpinnerModel that backs each JSpinner should not be your value A. (That would be a horribly inelegant tightly coupled dependency on a particular view.)
Instead, your value A should either be a POJO or a property of an object. In which case, you can add PropertyChangeSupport to it. (And presumably have already done so in any case, as you want your spinners to update automatically if A is changed by other parts of your program).
I realise this is similar to Marc W's answer, and you were concerned that it's "complicated", but PropertyChangeSupport does almost all of it for you.
In fact, for trivially simple cases, you can just use a single class that wires a "setProperty" method through to a "firePropertyChange" call (as well as storing the value in a HashMap for any "getProperty" calls).
I don't really want to solve your problem but I find it interesting. I have already been confront to it and solved it each time a different way. But when I think about the 'why ?' and not about the 'how ?' am staying perplexed.
This problem only exists because I am using an automatism (MVC) which had to help me, and exactly in that way. The art how the components are used make this automatism a barrier to a beautiful code.
Why do set #setEvent() has to produce the same event as a GUI action?
Though, my opinion is also pretty close to Observer pattern but it is a bit lighter than that!!!
Have A as a variable with a setter
private Integer A;
setA(int A)
{
this.A = A;
refreshSpinners();
}
refreshSpinners()
{
setSpinnerA();
setSpinnerAMinus10();
}
setSpinnerA()
{
// show value of A
}
setSpinnerAMinus10()
{
// show value of A-10
}