Bug 295826 - setVisible(false) on ISubModuleNode causes unexpected jumps
Summary: setVisible(false) on ISubModuleNode causes unexpected jumps
Status: NEW
Alias: None
Product: Riena
Classification: RT
Component: navigation (show other bugs)
Version: 1.2.0   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-11-23 03:15 EST by Nataliya Sinkevych CLA
Modified: 2009-11-30 15:16 EST (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nataliya Sinkevych CLA 2009-11-23 03:15:49 EST
Example:
	@Override
	protected void onAfterDeactivated(ISubModuleNode source) {
	super.onAfterDeactivated(source);
	source.setVisible(false);
	 }
	 
In this case the SubModuleNode becomes invisible, then the last seen/activated node becomes shortly visible and then the first node in the navigation tree is activated and becomes visible. The last jump is very confusing and interferes some actions.
Comment 1 Christian Campo CLA 2009-11-25 04:40:03 EST
The reason is that the SWT tree item is made invisible while it is still the one that has the selection in the tree. SWT triggers an event to then select the first node. A solution is a make the source available sometime later.

So instead write:
		Thread t = new Thread() {

			@Override
			public void run() {
				try {
					Thread.sleep(20);
				} catch (InterruptedException e) {
					// TODO Auto-generated catch block
					e.printStackTrace();
				}
				Display.getCurrent().syncExec(new Runnable() {

					@Override
					public void run() {
						source.setVisible(false);
					}
				});
			}
		};
		t.start();

Display.syncExec alone is not enough. With the code above you get the desired behaviour. Not sure we can fix that in Riena. I leave the bug open for further investigation.
Comment 2 Christian Campo CLA 2009-11-25 11:20:06 EST
setting the severity to normal, since we have a working workaround.
Comment 3 Christian Campo CLA 2009-11-27 09:02:13 EST
I experienced sometimes a NPE using Display.getCurrent() what worked for me was using Display.getDefault().

So you should replace Display.getCurrent() with Display.getDefault()
Comment 4 Elias Volanakis CLA 2009-11-30 15:15:07 EST
Actually both Display.getXXX variants are "evil" and should not be avoided where possible. The problem is that their return value depends on the thread that calls them. Please use PlatformUI.getWorkbench().getDisplay(). :-)
Comment 5 Elias Volanakis CLA 2009-11-30 15:16:20 EST
typo - the above should read: "Display.getXXX should BE avoided..."