| RE: [dsdp-tm-dev] Re: dsdp-tm-dev Digest, Vol 56, Issue 5 |
Hi Jacques, OK. I see. The form is modifying the page completed state of the parent wizard page. Not sure if you have a chance to verify the attached patch. I've guarded the SystemConnectionForm.verify call in getNextPage, but I don't have a quick chance to verify it. > My LTTngDiscoveryNewConnectionWizard is basically a > copy/paste of RSEDefaultNewConnectionWizard. > My goal is to connect to every known peers > (Protocol.getPeers()) and have as many connections in the > tree, instead of only one. For this I have : > > > * overriden performFinish() and > > * changed IHost createdHost to Vector<IHost> createdHosts > to be filled in performFinish() > > Doesn't seem to work yet, I didnt figure out how > createdHost/createdHosts is used to fill the tree. Well, the created host object is consumed by the SystemNewConnectionAction in postProcessWizard, but it is used only if the wizard is (again) of type RSEDefaultNewConnectionWizard. However, the refresh of the tree should have happened via the ISystemRegistry.createHost method, called by the RSEDefaultNewConnectionWizard.performFinish method. I guess you call one if the createHost methods in your performFinish implementation as well. Means the tree should refresh with all the newly created hosts. Best regards, Uwe :) > -----Original Message----- > From: dsdp-tm-dev-bounces@xxxxxxxxxxx > [mailto:dsdp-tm-dev-bounces@xxxxxxxxxxx] On Behalf Of Jacques Arnoux > Sent: Tuesday, March 30, 2010 11:05 PM > To: dsdp-tm-dev@xxxxxxxxxxx > Subject: [dsdp-tm-dev] Re: dsdp-tm-dev Digest, Vol 56, Issue 5 > > Hello Uwe, > Thank you for your answer! Here is the trace you asked: > > java.lang.StackOverflowError > at org.eclipse.swt.widgets.Combo.callWindowProc(Combo.java:296) > at org.eclipse.swt.widgets.Combo.windowProc(Combo.java:2046) > at org.eclipse.swt.widgets.Display.windowProc(Display.java:4632) > at org.eclipse.swt.internal.win32.OS.CallWindowProcW(Native Method) > at org.eclipse.swt.internal.win32.OS.CallWindowProc(OS.java:2314) > at org.eclipse.swt.widgets.Combo.callWindowProc(Combo.java:294) > at org.eclipse.swt.widgets.Control.windowProc(Control.java:4036) > at org.eclipse.swt.widgets.Combo.windowProc(Combo.java:2075) > at org.eclipse.swt.widgets.Display.windowProc(Display.java:4632) > at org.eclipse.swt.internal.win32.OS.GetWindowTextW(Native Method) > at org.eclipse.swt.internal.win32.OS.GetWindowText(OS.java:2743) > at org.eclipse.swt.widgets.Combo.getText(Combo.java:847) > at > org.eclipse.rse.ui.SystemConnectionForm.getHostName(SystemConn > ectionForm.java:580) > at > org.eclipse.rse.ui.SystemConnectionForm.isPageComplete(SystemC > onnectionForm.java:390) > at > org.eclipse.rse.ui.wizards.newconnection.RSEDefaultNewConnecti > onWizardMainPage.isPageComplete(RSEDefaultNewConnectionWizardM > ainPage.java:129) > at > org.eclipse.linuxtools.lttng.remoteui.wizards.newconnection.LT > TngDiscoveryNewConnectionWizard.canFinish(LTTngDiscoveryNewCon > nectionWizard.java:668) > at > org.eclipse.jface.wizard.WizardDialog.updateButtons(WizardDial > og.java:1255) > at > org.eclipse.jface.wizard.WizardPage.setPageComplete(WizardPage > .java:299) > at > org.eclipse.rse.ui.SystemConnectionForm.setPageComplete(System > ConnectionForm.java:1407) > at > org.eclipse.rse.ui.SystemConnectionForm.validateConnectionName > Input(SystemConnectionForm.java:1333) > at > org.eclipse.rse.ui.SystemConnectionForm.verify(SystemConnectio > nForm.java:444) > at > org.eclipse.rse.ui.wizards.newconnection.RSEDefaultNewConnecti > onWizardMainPage.getNextPage(RSEDefaultNewConnectionWizardMain > Page.java:141) > at > org.eclipse.jface.wizard.WizardPage.canFlipToNextPage(WizardPa > ge.java:115) > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<pattern starts here > at > org.eclipse.rse.ui.wizards.newconnection.RSEDefaultNewConnecti > onWizardMainPage.canFlipToNextPage(RSEDefaultNewConnectionWiza > rdMainPage.java:162) > at > org.eclipse.jface.wizard.WizardDialog.updateButtons(WizardDial > og.java:1260) > at > org.eclipse.jface.wizard.WizardPage.setPageComplete(WizardPage > .java:299) > at > org.eclipse.rse.ui.SystemConnectionForm.setPageComplete(System > ConnectionForm.java:1407) > at > org.eclipse.rse.ui.SystemConnectionForm.validateConnectionName > Input(SystemConnectionForm.java:1333) > at > org.eclipse.rse.ui.SystemConnectionForm.verify(SystemConnectio > nForm.java:444) > at > org.eclipse.rse.ui.wizards.newconnection.RSEDefaultNewConnecti > onWizardMainPage.getNextPage(RSEDefaultNewConnectionWizardMain > Page.java:141) > at > org.eclipse.jface.wizard.WizardPage.canFlipToNextPage(WizardPa > ge.java:115) > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<pattern ends here > at > org.eclipse.rse.ui.wizards.newconnection.RSEDefaultNewConnecti > onWizardMainPage.canFlipToNextPage(RSEDefaultNewConnectionWiza > rdMainPage.java:162) > at > org.eclipse.jface.wizard.WizardDialog.updateButtons(WizardDial > og.java:1260) > .......... > etc, etc... > > My LTTngDiscoveryNewConnectionWizard is basically a > copy/paste of RSEDefaultNewConnectionWizard. > My goal is to connect to every known peers > (Protocol.getPeers()) and have as many connections in the > tree, instead of only one. For this I have : > > > * overriden performFinish() and > > * changed IHost createdHost to Vector<IHost> createdHosts > to be filled in performFinish() > > Doesn't seem to work yet, I didnt figure out how > createdHost/createdHosts is used to fill the tree. > Cheers, > Jacques > > > > > > > On 30/03/2010 12:00, dsdp-tm-dev-request@xxxxxxxxxxx wrote: > > Send dsdp-tm-dev mailing list submissions to > dsdp-tm-dev@xxxxxxxxxxx > > To subscribe or unsubscribe via the World Wide Web, visit > https://dev.eclipse.org/mailman/listinfo/dsdp-tm-dev > or, via email, send a message with subject or body 'help' to > dsdp-tm-dev-request@xxxxxxxxxxx > > You can reach the person managing the list at > dsdp-tm-dev-owner@xxxxxxxxxxx > > When replying, please edit your Subject line so it is > more specific > than "Re: Contents of dsdp-tm-dev digest..." > > > Today's Topics: > > 1. RSEDefaultNewConnectionWizardMainPage seems to be more > specific than intended (Jacques Arnoux) > 2. RE: RSEDefaultNewConnectionWizardMainPage seems > to be more > specific than intended (Stieber, Uwe) > > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 30 Mar 2010 00:37:18 -0400 > From: Jacques Arnoux <jacques.arnoux@xxxxxxxxxx> > <mailto:jacques.arnoux@xxxxxxxxxx> > Subject: [dsdp-tm-dev] > RSEDefaultNewConnectionWizardMainPage seems to > be more specific than intended > To: dsdp-tm-dev@xxxxxxxxxxx > Message-ID: <4BB17FFE.2020606@xxxxxxxxxx> > <mailto:4BB17FFE.2020606@xxxxxxxxxx> > Content-Type: text/plain; charset="iso-8859-1" > > Hi all, > I'm currently trying to implement a NewConnectionWizard > that extends > RSEAbstractNewConnectionWizard and uses > RSEDefaultNewConnectionWizardMainPage as a main page. > While typing a hostname into the host name field, I > encountered a stack > overflow I figured out as follow: > while trying to *validate the form*/text typed and > refresh the buttons > > (RSEDefaultNewConnectionWizardMainPage[:154].canFlipToNextPage > ()), the > mainPage checks whether mainPage is a > RSEDefaultNewConnectionWizard or not. > If not (my case), is calls super.canFlipToNextPage() > which in turn seems > to ask to the implementation to *validate the form*, etc, etc... > Isn't RSEDefaultNewConnectionWizardMainPage usable without > RSEDefaultNewConnectionWizard? > > My workaround is to extend > RSEDefaultNewConnectionWizard instead of > RSEAbstractNewConnectionWizard but it's not so great > cause I cannot even > use the super attributes since there is no getters and > setters and my > code differs in only performFinish(). I have to > override everything. > Is this intended and am I missing something here? > Thanks, > Jac > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > https://dev.eclipse.org/mailman/private/dsdp-tm-dev/attachment > s/20100330/7d44032c/attachment.html > > ------------------------------ > > Message: 2 > Date: Tue, 30 Mar 2010 10:33:25 +0200 > From: "Stieber, Uwe" <Uwe.Stieber@xxxxxxxxxxxxx> > <mailto:Uwe.Stieber@xxxxxxxxxxxxx> > Subject: RE: [dsdp-tm-dev] > RSEDefaultNewConnectionWizardMainPage seems > to be more specific than intended > To: "Target Management developer discussions" > <dsdp-tm-dev@xxxxxxxxxxx> > <mailto:dsdp-tm-dev@xxxxxxxxxxx> > Message-ID: > > <F7CF6DC5B863B94BA58A030D02DCD9F4854E7F@xxxxxxxxxxxxxxxxxxxxxx > .com> > <mailto:F7CF6DC5B863B94BA58A030D02DCD9F4854E7F@xxxxxxxxxxxxxxx > .ad.wrs.com> > Content-Type: text/plain; charset="us-ascii" > > Hi Jacques, > > Well, the RSEDefaultNewConnectionWizardMainPage is > (weak) bound to > RSEDefaultNewConnectionWizard, as the > RSEDefaultNewConnectionWizard is > implementing the RSE wizard specific/typical behavior. > > RSEAbstractNewConnectionWizard is provided as common > base class to allow > for 3rd party wizards following a complete different > idea than the > default RSE wizards and more specifically, do not share > UI with the RSE > default wizards. > > Nonetheless, RSEDefaultNewConnectionWizardMainPage > should be usable even > with a non RSEDefaultNewConnectionWizard > implementation. For that > purpose, the RSEDefaultNewConnectionWizardMainPage > forwards to the super > implementation. > > > > > (RSEDefaultNewConnectionWizardMainPage[:154].canFlipToNextPage > ()), the mainPage checks whether mainPage is a > > > RSEDefaultNewConnectionWizard or not. > > To be precise, the main page determines the associated > wizard and checks > if the wizard is of type RSEDefaultNewConnectionWizard or not. > > > > If not (my case), is calls > super.canFlipToNextPage() which in > turn seems to ask to the implementation to > validate the form, > etc, etc... > > > > Well, the super.canFlipToNextPage(), calls for > "isPageComplete()", which > is overwriten in RSEDefaultNewConnectionWizardPage to > forward the call > to the form, and "getNextPage()" which is using the > same check as the > "canFlipToNextPage()". The form itself, which the two > invoked methods > "isPageComplete()" and "isConnectionUnique()" does not > go back to the > page to trigger a "canFlipToNextPage()" again. At least > I cannot see how > from the code. You may educate me by forwarding a short > extract from the > stack overflow error stack traces (run Eclipse with > -Xint if you don't > have a stack trace visible for the error). Probably it is the > "getNextPage()" implementation of the wizard which is > getting back to > the page? > > Thanks, Best regards, > > Uwe Stieber > > > > > > > -----Original Message----- > From: dsdp-tm-dev-bounces@xxxxxxxxxxx > [mailto:dsdp-tm-dev-bounces@xxxxxxxxxxx] On > Behalf Of Jacques Arnoux > Sent: Tuesday, March 30, 2010 6:37 AM > To: dsdp-tm-dev@xxxxxxxxxxx > Subject: [dsdp-tm-dev] > RSEDefaultNewConnectionWizardMainPage > seems to be more specific than intended > > Hi all, > I'm currently trying to implement a > NewConnectionWizard that > extends RSEAbstractNewConnectionWizard and uses > RSEDefaultNewConnectionWizardMainPage as a main page. > While typing a hostname into the host name field, I > encountered a stack overflow I figured out as follow: > while trying to validate the form/text typed > and refresh the > buttons > > (RSEDefaultNewConnectionWizardMainPage[:154].canFlipToNextPage > ()), the mainPage checks whether mainPage is a > RSEDefaultNewConnectionWizard or not. > If not (my case), is calls > super.canFlipToNextPage() which in > turn seems to ask to the implementation to > validate the form, > etc, etc... > Isn't RSEDefaultNewConnectionWizardMainPage > usable without > RSEDefaultNewConnectionWizard? > > My workaround is to extend > RSEDefaultNewConnectionWizard > instead of RSEAbstractNewConnectionWizard but > it's not so > great cause I cannot even use the super > attributes since > there is no getters and setters and my code > differs in only > performFinish(). I have to override everything. > Is this intended and am I missing something here? > Thanks, > Jac > > > > > > > ------------------------------ > > _______________________________________________ > dsdp-tm-dev mailing list > dsdp-tm-dev@xxxxxxxxxxx > https://dev.eclipse.org/mailman/listinfo/dsdp-tm-dev > > > End of dsdp-tm-dev Digest, Vol 56, Issue 5 > ****************************************** > > > >
Attachment:
RSEDefaultNewConnectionWizardMainPage_StackOverflow.patch
Description: RSEDefaultNewConnectionWizardMainPage_StackOverflow.patch