Validate CTabFolder before switching tabs - java

In a CTabFolder, I'd like to check the content for unsaved data before the user can switch from one tab to another. SWT does not provide a PreSelection event, as stated here.
I found a workaround, suggesting to switch back to the old tab when a selection is triggered, validate the data and then perform the desired switch again, if data is valid.
I do understand the general idea of this workaround, however, it is not working for me. oldPageIndex and newPageIndex do always have the same value, though I did not click on the same tab.
this.tabContainer.addSelectionListener(new SelectionAdapter() {
#Override
public void widgetSelected(SelectionEvent event) {
int oldPageIndex = tabContainer.getSelectionIndex();
int newPageIndex = tabContainer.indexOf((CTabItem)event.item);
// Here: oldPageIndex == newPageIndex
...
}
});
Is this workaround still working or is there anything I could possibly be doing wrong? Or maybe, has there been any fix for a real PreSelection event in the meantime? I tried using event.doit, but the SelectionEvent is fired, when the tabs have been switched already.

You can use the selection listener but as you have found the getSelectionIndex() does not give you the old tab. So you will have to maintain the old tab index yourself.
This is the technique used by the Eclipse FormEditor.

Related

GWT forbid History.back() to exit current site

I'm wondering if there is a simple way in GWT to forbid History.back() (or .forward()) to lead to an external site, and define a fallback url if one of this happen.
For example :
Assuming that mysite.com#token, contains a component triggering a History.back().
I am on stackoverflow.com, I paste mysite.com#token in my browser, then click on my component which move me back to stackoverflow, is it possible that click goes in mysite.com instead as a back exit my site?
Thanks for your help!
Use this approach
Window.addWindowClosingHandler(new ClosingHandler() {
public void onWindowClosing(ClosingEvent event) {
event.setMessage("Do you want to leave this site");
}
});

How to listen on save button or assign an event after it was clicked in Vaadin 7

When I am editing grid inline I can save or cancel my grid row changes. I want to update my database entries after button 'save' will be pushed(Data base mechanism has already done) How can I implement it?
My container:
BeanItemContainer<CategoryOfService> beansContainer;
Editing view:
All what I need it know which listeners I have to use. I found some CommitHandler which I can add by EditorFieldGroup class but I can't implement it properly maybe there is have to be another way to resolve problem.
There's kind of a way to capture inline Save click on the grid.
grid.getEditorFieldGroup().addCommitHandler(new FieldGroup.CommitHandler() {
#Override
public void preCommit(FieldGroup.CommitEvent commitEvent) throws FieldGroup.CommitException {
//...
}
#Override
public void postCommit(FieldGroup.CommitEvent commitEvent) throws FieldGroup.CommitException {
//...
}
});
After clicking Save both methods preCommit and postCommit get called.
Hope it helps :)
Grid does not currently give you any direct way of adding listeners to the save and cancel buttons for the inline editor, although that is something that might change in Vaadin 7.6.
As a workaround before that happens, the CommitHandler approach that you already mentioned is still supposed to work. You can find a basic example here. The contents of your BeanItemContainer should be fully updated in the postCommit phase.
grid.getEditor().addSaveListener((EditorSaveListener<Product>) event -> {
//your stuf
HibernateDataSource.updateProduct(event.getBean());
});

GWT event prevent default not working in Java

I'm new to GWT and I need to get a right click working. The doco I've read suggests that I need to override the onBrowserEvent() method. I'm just experimenting at this stage. the event is processed and my pop-up appears. However, as soon as I close the pop-up, the usual browser drop down menu appears (with options like "Bookmark this page" and such).
I'm using IceWeasel 24.5.0 (FireFox clone for Debian) and, obviously, Debian (wheezy).
Here's the relevant code:
public ActivityTextCell() {
super(BrowserEvents.MOUSEDOWN, BrowserEvents.MOUSEUP);
}
#Override
public void onBrowserEvent(
com.google.gwt.cell.client.Cell.Context context,
Element parent,
ActivityDTO value,
NativeEvent event,
ValueUpdater<ActivityDTO> valueUpdater) {
super.onBrowserEvent(context, parent, value, event, valueUpdater);
event.preventDefault();
event.stopPropagation();
if (event.getType().equals(BrowserEvents.MOUSEUP)) {
Window.alert("mouse up event");
}
else {
switch ( event.getButton()){
case NativeEvent.BUTTON_RIGHT:
Window.alert("right mouseclick");
break;
case NativeEvent.BUTTON_LEFT:
Window.alert("left mouseclick");
break;
case NativeEvent.BUTTON_MIDDLE:
default:
break; // Do nothing
}
}
The class ActivityTextCell extends AbstractCell.
So what am I missing? How do I stop the browser from reaticng to the mouse click?
Well it certainly wasn't a matter of a few minutes (as can be seen by the fact that it has taken me a week to get back to this), but I have a solution. I tried reversing the order of the the event.preventDefault() and super.onBrowserEvent() but it didn't really help.
I tried a little experiment on a normal web page. It turns out, that the MOUSEDOWN event doesn't do anything in that context and the usual browser selection menu appears on the MOUSEUP. So the if/else logic sort of fell by the wayside.
What did the trick is to include the following in the top level GUI class immediately after adding the main page:
RootLayoutPanel.get().addDomHandler(new ContextMenuHandler() {
#Override
public void onContextMenu(ContextMenuEvent event) {
event.preventDefault();
event.stopPropagation();
}
}, ContextMenuEvent.getType());
This has the additional benefit (for my purposes, at least) of preventing the Browser from reacting to a right click anywhere in the application view.
As an aside: The purpose of preventing the default action is to stop the Browser doing its own thing Stopping propagation is possibly not required, but I left it in anyway (propagation goes fro the node up to the root, not the other way around). The purpose of overridinging onBrowserEvent() is to enable your own application to handel that event. The use of super.onBrowserEvent() is to allow the event to be handled by your code in the first place. I've given the relevant reference in my previous comment. The book "GWT in Action" is well worth a read if you're likely to be doing a lot of GWT coding.
You call super.onBrowserEvent() which triggers the standard browser response.
You should move event.preventDefault() to the if part of your code, and super.onBrowserEvent() to the else part. You want one of them executed depending on a browser event, but not both.

Eclipse RCP view will not update when editor data is modified

I'm attempting to do something that seems like it should be quite common, so I'm surprised I'm having a hard time finding a solution.
I have a simple Eclipse RCP application. It consists of a view, containing a treeViewer that displays elements of an xml file hierarchically. The other side is an editor, which contains various fields such as textboxes, etc, for displaying and also modifying the xml values. The treeviewer displays icons alongside the element name, and what I'm trying to do is change the icon to a "modified" version of the icon whenever a change is made in the editor - signifying that a value of that element has been changed. This is very similar to how Eclipse, when integrated with subversion, shows that a file has been modified from the base revision in the Package Explorer.
I'll try to just show the parts of the code relevant to this specific issue and hope I don't leave anything out. This is the editor class:
public class XmlEditor extends EditorPart
{
protected boolean dirty = false;
public void setDirty(boolean value)
{
dirty = value;
firePropertyChange(PROP_DIRTY);
}
}
and this is the view with the tree:
public class TreeView extends ViewPart implements IPropertyChangeListener {
public void createPartControl(Composite parent) {
treeViewer = new TreeViewer(parent, SWT.BORDER | SWT.MULTI | SWT.V_SCROLL);
getSite().setSelectionProvider(treeViewer);
treeViewer.setLabelProvider(new TreeObjLabelProvider());
treeViewer.setContentProvider(new TreeObjContentProvider());
PlatformUI.getWorkbench().getWorkingSetManager().addPropertyChangeListener(this);
}
public void propertyChange(PropertyChangeEvent event) {
if (event.getProperty().equals(IWorkbenchPartConstants.PROP_DIRTY)) {
treeViewer.refresh();
}
}
}
In this scenario, TreeView::propertyChange() is not getting called, even though firePropertyChange() is getting fired. Any ideas why? I'm also open to any other ideas that don't involve PropertyChangeListener, it just seemed like this would be the easiest way at the time. Thank you.
Here's how I ended up solving the problem:
Changed TreeView to implement IPropertyListener instead of IPropertyChangeListener
Implemented the propertyChanged() method to perform a treeViewer.refresh()
In the XmlEditor::createPartControl() method I got a reference to the Treeview part and then added it to the property listeners like so:
TreeView treeView = (TreeView) getSite().getPage().findView(TreeView.ID);
addPropertyListener(treeView);
Now, TreeView::propertyChanged() gets called after firePropertyChanged(), just like I needed. It took quite a bit of experimentation to learn the difference between IPropertyListener and IPropertyChangeListener, addPropertyListener() and addPartPropertyListener().
Thanks to nitind for giving me a new perspective, and for showing me about Decorators, which is definitely the right way to go as opposed to changing the tree icon to a modified version.
You fired a property change in the editor part, which is unrelated to the working set manager. Nothing you've done connects the view to the editor. If you want the two to talk to each other, write them to talk to each other, or at least create and react to events from making the modifications you describe.
I'm also pretty certain that's not how SVN shows that a file has been modified.
SVN is probably supplying a Decorator: http://eclipse.org/articles/Article-Decorators/decorators.html
Add this bunch of code in your create part control this will may be help you
ResourcesPlugin.getWorkspace().addResourceChangeListener(new IResourceChangeListener() {
#Override
public void resourceChanged(IResourceChangeEvent event) {
treeViewer.refresh();
}
});

Drag&Drop with swing

I need some help. Is it possible to simulate a drag & drop without registering a component?
E.g. I click the mousekey anywhere on the window and hold the mousekey down, at this moment, I want to create or simulate a DragSourceEvent programmatically with Java.
Is this possible?
Update:
Regarding Bob's reply, at least I got it, I can create a listener for the drag & drop:
DragSource dragSource = new DragSource();
DragGestureListener listener = new DragGestureListener() {
public void dragGestureRecognized(DragGestureEvent event) {
event.startDrag (null, strSel) ;
...
}
}
listener.dragGestureRecognized(new DragGestureEvent(
new DragGestureRecognizer(dragSource, component) {
}, DnDConstants.ACTION_COPY, new Point(0,0), events ));
but unfortunately i get this exception:
java.lang.IllegalArgumentException:
source actions at
java.awt.dnd.DragSourceContext.(DragSourceContext.java:169)
at
java.awt.dnd.DragSource.createDragSourceContext(DragSource.java:454)
at
java.awt.dnd.DragSource.startDrag(DragSource.java:293)
at
java.awt.dnd.DragSource.startDrag(DragSource.java:403)
at
java.awt.dnd.DragGestureEvent.startDrag(DragGestureEvent.java:203)
any suggestions?
The question you asked:
I haven't tried it, but in theory you should be able to create the Event object and get a handle on the Swing Event Queue from one of the system classes. However without having a valid component, there may be problems when methods try to work with the event.
What you probably meant:
Registering events for a standard window -- you should be able to set up drag and drop support for an empty JPanel or JFrame, but it'll take some hacking. Drag & Drop is a pain to work with at this level when not built in -- I suggest using something like an invisible component or something instead.

Categories

Resources