I am using the UndoRedo.Manager to implement Undo/Redo functionality in a Netbeans RCP application. The undoableEditListener can be added to any Document, that limits its use to text-related fields. Does anyone know how i can add such a listener to elements without a Document, like a JCheckBox?
Just create custom CompoundEdits or even separate edits. See for example the edits merging in one http://java-sl.com/tip_merge_undo_edits.html
I think all you need is to keep own events stack and implement custom UndoableEdits which don't change model (Document) but change state. In other words you need more complicated model to keep checkbox state as well as Document in one. All the complicated model changes (state change or docuemnt change) should be represented by custom UndoableEdit class. The class instance could be wrapper for Docuemnt edit event or just custom event.
Related
I'm dealing with a WebApp (Vaadin19) and stuck now in the question, how to share an object-state change from one component to another. There is one object instance in two or more components. After changing an attribute of the object in one component and going back to another component, I want to see the changed attribute.
Let me explain, what I mean:
There is a grid with some lines of data. The grid shows only a subset of the data to respect the clarity.
A click on the grid opens a detailed view in "read mode". The data is structured (contains sub-objects itself).
A click on the "read mode"-view opens then a dialog with tabs. The activated tab depends on the sub-object, that was clicked before.
After changing an element in the sub-object and closing the dialog, I want that the UI will reload/revalidate it's content. I think it's clear, that I use there the same object-instance.
Is there an event I have to submit to the UI?
Or:
What is the best approach for this?
The actual refresh is easy: theGrid.getDataProvider().refreshAll(), or refreshItem instead if you have access to the item that has been changed and it has a good implementation of equals and hashCode.
How to hook things up so that the dialog notifies the grid is then really depending on your architecture.
If they are already close to each other in the code, then you could e.g. store a reference to the Grid in an instance field and just reference that in the dialog handler.
If you want to decouple, then you need some kind of event bus. You can use the regular Spring event mechanisms as long as you ensure that the event stays within the UI scope. Alternatively, you can use ComponentUtil::addListener and ComponentUtil::fireEvent to use e.g. UI.getCurrent as a simple event bus.
I want to get my event listener called when the component is repainted (JComponent). I read about different Event Listeners but none seems to be the correct one for Invalidate or Repaints. Any way to do this?
Why I want this: I'm trying to get notified when there is some change in a control, in order to fire the method that tracks the changes (as in the file has changed, "do you want to save changes?").
Another use for this is for manually invoking the custom layout manager of a non-added-to-the-container-but-drawn component (this one is kind of complex, it's for a GUI editor program).
Why I want this: I'm trying to get notified when there is some change in a control, in order to fire the method that tracks the changes (as in the file has changed, "do you want to save changes?").
Normally, you track changes to an edited file in the GUI model class. Every time your model adds or removes a character, you set a dirty flag in the model that you check later.
Another use for this is for manually invoking the custom layout manager of a non-added-to-the-container-but-drawn component (this one is kind of complex, it's for a GUI editor program).
Your understanding of Swing appears to be backwards. The components don't drive the layout. The layout arranges the components.
Here's one example of a Swing character based text editor.
Here's a Stack Overflow question about a GUI builder editor.
I have designed an html document editor and I wanted some help in resolving a design problem in it. The problem is as follows -
The document editor consists of a surface (JFrame) and a menu bar. Inside the surface I have three panels - a tool panel, text panel and status panel (which are all extensions of JPanel). The text panel has the customized text pane (extension of JTextPane). Now the problem is that - there are lots of scenarios where the menus and the widgets items on the tool panel need access to the underlying document model of the JTextPane. E.g. to implement list/paragraph dragging functionality, the ruler needs to know the position of the caret inside the document model, so that I can mark the paragraph whose left inset I need to increase.
The way I have organized my design right now is that - surface is a singleton, so to access the html document model inside the JTextPane you need to code your way through the following maze -
Give me surface -> go to text panel -> go to text pane -> go to document of the text pane
Another alternative to make the reference of the document inside the text pane static, so that it can be accessed directly.
TextPane.getTextDocument ()
Also the html document inside the Text Pane I am using is not customized right now. So I am just using the default HTMLDocument returned by the text pane. Though in future I may have to replace it with a more customized extension of HTMLDocument (e.g. to implement cusom tags)
I am somewhat of a design novice. Can some design guru throw some light/insight into this?
I think if you get 10 responses you'll get 11 answers. :-)
First, there is no need for a Singleton. In this scenario, it's just a way of cheating with a global variable. And what happens when you want to have two or three text documents open?
Do your menus have ready access to the tool panel? Since toolpanel is a sibling of the textpanel, and in a 1-1 relationship (I think?) it is somewhat "reasonable" for toolpanel to know about textdocument (have a link it) and a convenience method, getTextDocument(). And it seems reasonable for your widgets to know about their immediate parent, the tool panel.
That would be my way of approaching the problem - what links between objects "make sense". You want as little coupling as possible, but there are places where you do need coupling. Maybe I have misunderstood your problem, or maybe you think a lot differently than me, in which case you should do it another way. Also, you are making a best guess as to how your code might evolve in the future. Good luck with that! :-)
One big question for any solution - does the text document change? (e.g., is there a File->New menu or a File->Open menu?). If so, that needs to be considered. In my proposal, the JFrame, on a File->Open, would create the text document and then change the link to it in the ToolBar.
p.s. MVC purists - please add appropriate models and controllers! I just talked about the graphical components to keep things simpler...
p.p.s. Examples of "thinking ahead" for reasonable enhancements
Would this handle multiple JFrames open at once? Yes.
Would this handle a single JFrame, but with multiple documents (say, a tabbed interface for the text document)? Almost. The method has to be a little smarter to know which of the many documents is active, but you can easily imagine doing that.
How about when I need to hold a lot more info about the dicument, like the name (so Save gives a good default), last time saved, is it "dirty", is it HTML or XHTML or whatever... At this point, you'll probably want to add one more model layer. But you can sortof imagine, with one more layer of indirection (one more link) this being o.k. So it depends on how close you are to implementing #3 how you want to design.
what is the best way to have JFrames, JDialogs, etc that derive from a common parent but differ some, to be able to have the common parts update automatically when the parent does, but also have new components which are still easily modified in a GUI builder.
One approach I have used before is having placeholder JPanels that populate with existing isolated components at runtime, but I suspect that this is not the best way.
Example frame visual inheritence:
Don't use a GUIBuilder unless you creating some sort of prototype or other throw away code.
Have the components that need to update automatically setup as listeners for some sort of change event. Once an update is needed fire of an "Event" to each listener.
I have been looking into JTree and TreeCellRenderer. It seems in general, the application (with one JTree) has only one instance of TreeCellRenderer. The application makes multiple calls to TreeCellRenderer's getTreeCellRendererComponent method to decide how each TreeCell is drawn, and such call are made in many occasions (when a cell is selected, deselected, move over, when scrolling, etc.). Why did they decide to do that instead of having multiple instances of TreeCellRenderer, each responsible for one cell??
I am trying to make a JTree where each cell contains a checkbox. The checkbox can be checked/unchecked by the user. Then, the TreeNode userObject's values are set base on the state of these checkboxes. But, from the current JTree design this is impossible - since there is only one instance of JCheckBox, and is only used to show how the Cell looks like (you can't really check it). In some sense I want to separate selection of the TreeCell and the checking of the boxes.
I have some workarounds (implementing MouseAdapter and checking if the mouse click is close by where the checkbox is rendered, then emulate a check on the box by changing its appearence in TreeCellRenderer), but still I want to know if this can be done more directly. Thanks!
Why did they decide to do that instead of having multiple instances of TreeCellRenderer, each responsible for one cell?
This is a nice example of the flyweight pattern.
For a check box tree, I like org.netbeans.swing.outline.Outline, mentioned here, but other examples are available.
Addendum: Reading your question more closely, you ask:
In some sense I want to separate selection of the TreeCell and the checking of the boxes.
This is the correct instinct: The data (checked or unchecked) should be stored in the model (TreeModel), not the view (JCheckBox). The example uses instances of CheckBoxNode in it's (implicit) model, accordingly.