Canvas parent-children issue ...

[ghost277]

I have this strange behavior in my application, where it seems children aren't added under their expected parents. I can verify this by using the debug console. The issue is that when I call the destroy on these parents, my children/member objects aren't destroyed and thus leading to various subsequent issues - not counting the excessive use of memory.

I have created a test case code that can reproduce the issue and I want your opinion if this a bug or just me not doing the stuff as expected. The code that seams to work is the following:

		//Create a tabSet with some panes
		VLayout hLayout = new VLayout();
		
		tabSet = new TabSet();
		tabSet.setWidth(500);
		tabSet.setHeight(500);
		
		//Create some labels.
		Label label1 = new Label("Tab1");
		Label label2 = new Label("Tab2");
		Label label3 = new Label("Tab3");
		
		//Create some tabs.
		Tab tab1 = new Tab("Tab1");
		Tab tab2 = new Tab("Tab2");
		Tab tab3 = new Tab("Tab3");


		//Add the labels as part of the tabs.
		tab1.setPane(label1);
		tab2.setPane(label2);
		tab2.setDisabled(true);
		
		tab3.setPane(label3);
		tab3.setDisabled(true);

		IButton button = new IButton("Destroy!");
		button.addClickHandler(new ClickHandler() {
			
			@Override
			public void onClick(ClickEvent event) {
				destroyTabSet();
				
			}
		});

		//Add tabs as part of tabSet
		tabSet.addTab(tab1);
		tabSet.addTab(tab2);
		tabSet.addTab(tab3);

		
		hLayout.addMember(tabSet);
		hLayout.addMember(button);
		
		hLayout.show();

And the debug console shows a correct canvas objects tree as can be seen in the tree_correct.png image attached. Check how all the isc_Label objects are below the tabSet object in the tree. Thus when I push the destroy button they are destroyed as expected.

Now check the below snippet:

		//Create a tabSet with some panes
		VLayout hLayout = new VLayout();
		
		tabSet = new TabSet();
		tabSet.setWidth(500);
		tabSet.setHeight(500);
		
		//Create some labels.
		Label label1 = new Label("Tab1");
		Label label2 = new Label("Tab2");
		Label label3 = new Label("Tab3");
		
		//Create some tabs.
		Tab tab1 = new Tab("Tab1");
		Tab tab2 = new Tab("Tab2");
		Tab tab3 = new Tab("Tab3");

		//Add tabs as part of tabSet
		tabSet.addTab(tab1);
		tabSet.addTab(tab2);
		tabSet.addTab(tab3);

		//Add the labels as part of the tabs.
		tab1.setPane(label1);
		tab2.setPane(label2);
		tab2.setDisabled(true);
		
		tab3.setPane(label3);
		tab3.setDisabled(true);
		

		IButton button = new IButton("Destroy!");
		button.addClickHandler(new ClickHandler() {
			
			@Override
			public void onClick(ClickEvent event) {
				destroyTabSet();
				
			}
		});
		
		
		hLayout.addMember(tabSet);
		hLayout.addMember(button);
		
		hLayout.show();

The resulted canvases tree is the one shown in the tree_erroneous.png image attached. The problem is with the isc_Label_2 object, which is now not under the tabSet object, and if I press the destroy button this object will remain intact ... clearly not what one would expect. The only difference is of course the order of the addMember calls inside the code, and there is not notification to the programmer that this can lead to errors, making it harder if impossible to foresee such cases.

I have tested this with latest stable and current trunk releases of SmartGwt (r1621). Tested it on latest Chrome dev release (10.0.648.18), FF (3.6.15) and IE8. First two under Linux Ubuntu 10.10 and the last under Win7.

The issue is that although the above case is a simple example and can be easily "corrected", this can not be said for a more complex application. With many lines creating objects and adding them under parents to build an objects hierarchy, one can easily get into situations that trigger the problem that exists in the erroneous snippet of code. This leading to objects not be destroyed when their expected parent is destroyed. Any thoughts or comments on the above would be much appreciated.

[Isomorphic]

Hi Ghost277,
Thanks for the clear test case. We have now resolved this issue - please check with the next nightly build (available here http://www.smartclient.com/builds)

[ghost277]

Thanks for the really fast reply! I will check asap on Monday morning and let you know.

[ghost277]

The problem with the addMember seems to be solved. As far I could check with the provided test case and my apps's code the problems I was having have disappeared. Good work on this, and thanks again.

However, I have a remaining issue that at first thought it was coming from the case I had committed in this thread. It seems thought that this is a new one .. might be connected though. The issue is created by the setControls method of the SectionStackSection class. The below code is a test case for you to verify the issue:

	public void onModuleLoad() {
		//Create a tabSet with some panes
		VLayout hLayout = new VLayout();
		
		tabSet = new TabSet();
		tabSet.setWidth(500);
		tabSet.setHeight(500);
		
		//Create some labels.
		Label label1 = new Label("Tab1");
		
		SectionStack stack = new SectionStack();
		SectionStackSection stackSection = new SectionStackSection();
		
		Label label2 = new Label("Tab2");
		Label label2_1 = new Label("Control");
		label2_1.setID("label2_1");
		
		stackSection.setControls(label2_1);
		stackSection.addItem(label2);
		
		stack.addSection(stackSection);
		
		Label label3 = new Label("Tab3");
		
		//Create some tabs.
		Tab tab1 = new Tab("Tab1");
		Tab tab2 = new Tab("Tab2");
		Tab tab3 = new Tab("Tab3");

		//Add tabs as part of tabSet
		tabSet.addTab(tab1);
		tabSet.addTab(tab2);
		tabSet.addTab(tab3);

		//Add the labels as part of the tabs.
		tab1.setPane(label1);
		tab2.setPane(stack);
		tab2.setDisabled(false);
		
		tab3.setPane(label3);
		tab3.setDisabled(false);
		

		IButton button = new IButton("Destroy!");
		button.addClickHandler(new ClickHandler() {
			
			@Override
			public void onClick(ClickEvent event) {
				destroyTabSet();
				
			}
		});
		
		
		hLayout.addMember(tabSet);
		hLayout.addMember(button);
		
		hLayout.show();
		
	}

Again, I am getting strange placement of the objects in the canvases tree. As you can see in the image setControls_initial.png, when the tabset is first loaded, but the second tab is not yet visible, the label that is set with the setControls method is wrongly placed - at least to what I would expect - below the root of the canvases, and not below the SectionStack object. Thus if I would destroy the TabSet the label would still survive, leaving stale objects in similar cases.

When the second tab is selected, the label2_1 that is set by the setControls method is moved below the SectionStack object in the tree hierarchy - correct behavior IMO - and can be now correctly destroyed upon the destruction of TabSet object. This change in the tree can be seen at the setControls_tab_selected.png image attached. However this shouldn't be a desired functionality, because if the user doesn't select the second tab, as explained in the initial state of the TabSet, the label will not be destroyed. IMO it should be moved in the correct position of the tree, irrelevant if the parent canvas has been shown or not.

THe above is tested with the same browsers and at the same OSs as the initial post. SmartGWT versions used were stable 2.4 and nightly release 2.x/LGPL/2011-02-06.

[Isomorphic]

Hi Ghost,
We've dug into this one and resoled it as well.
The behavior here is actually that the 'controls' for section stack sections are not added as children to the section stack until the stack is drawn. We're leaving this behavior as is, so you'll continue to see the widget hierarchy tree showing the controls outside the section stack until the section stack has first been drawn. However we've added logic to ensure that even in this state, if destroy() is called on the SectionStack, the controls for each section will get destroyed automatically as if they were already children of the stack.

This change has made it into mainline so will show up in tomorrows nightly build.

Thanks
Isomorphic Software

[ghost277]

Yes, it works as you described it. It is perfect now! Thanks for the quick resolution of these issues.