Community
Participate
Working Groups
The docs for WizardNewFolderMainPage and WizardNewProjectCreationPage say that they can be subclassed. Yet their design is very restrictive. They are best to be used as is. The current apis in these classes do not expose the widgets, or methods in them, which means that someone subclassing them really has little to work with. Specific Example: 1) in the new folder page, how go I get what the user entered as a folder name? If I ovveride handleEvent method, how do I know which widget caused the event? event.widget gives me the widget that actually caused the event, but I do not have a handle to the parent widgets to do compares against! public void handleEvent(Event ev) { super.handleEvent(ev); System.out.println(ev); Widget source = ev.widget; if (source instanceof Text) System.out.println(((Text) source)); else System.out.println(source); } The above code will give me instances of Text objects for source, but how do I tell if this was "Enter or select the folder" text field or the "Folder name" text field? Widgets used in these pages should be exposed to allow for subclasses to add listeners... Mazen Faraj
Exposing the widgets is very dangerous. For example you would then be able to dispose them, change the layout in unexpected ways, add children, etc etc. This significantly increases the complexity and provides marginal improvements to the user. I am going to reclassify this defect report as a P3 enhancement.
Reopen to investigate
Created attachment 1822 [details] Java file demonstrating why I opened defect
Created attachment 1823 [details] Page resulting from previos Java attachment
I have attached a subclass that demostrates what I was trying to do. I understand that my code has a terrible hack, but it was a trade off between quickly writting the wizard page, or having to rewrite it myself.
There are currently no plans to work on this feature