Community
Participate
Working Groups
Build Identifier: 8.0.0 Every new instance of MBSWizardHandler created re-initializes the MBSCustomPageManager and reloads extensions (in loadCustomPages()). This causes any custom page to have numerous instances created for a single wizard whose references are not stored in the MBSCustomPageManager but do remain in the MBSWizardHandler.customPages. Due to this problem any custom page that we add through extensions cannot maintain a state () because when MBSWizardHandler is asked to check if it canFinish, it utilizes its locally saved instances, whereas any other page uses MBSCustomPageManager to check pages, which contains the most recently loaded instances. A workaround I think for now to save a state is to use MBSCustomPageManager.addPageProperty() to save the state between multiple instances. If this is on purpose, a comment on MBSCustomPage would be helpful. But it doesn't seem to be a good way to handle things, since for each instance it is possible that new controls are created repeatedly. Reproducible: Always
Hi Waqas. I haven't looked into the issue deeply yet, but can you try with 8.0.2? I made a change in bug 292534 that might affect this. Thanks!
(In reply to comment #1) > Hi Waqas. I haven't looked into the issue deeply yet, but can you try with > 8.0.2? I made a change in bug 292534 that might affect this. Thanks! Hi Marc. I did not try out the 8.0.2 but I did look at the patch attached to the defect and if my understanding below is incorrect let me know and I will try it out specifically. Sorry for the long comment. I don't think the fix will change much for the problem I reported. Since each MBSWizardHandler instance has its own set of instances of all custom pages, so depending on what you select on the first page the custom page instance is actually different for each selection. The page instance who gets to create its control and show something to user is the one that is the most recently loaded instance in the MBSCustomPageManager. However, with the fix above, this will change a little bit. Now each time you make a selection on the first page, everything gets reloaded and it is ensured that the MBSWizardHandler instance does in fact have the most recently loaded instances of custom pages. So perhaps a part of the problem does get fixed here. That is the handler does not call canFinish on instances that are actually not being shown to the user. But the other problem remains that because changing each selection causes different instances to be created, it is not possible to maintain a state in the instance of a custom page. And since MBSCutomPageManager gets reinitialized so many times we cannot even use MBSCustomPageManager.addPageProperty(). To ensure that user selection is retained between next to a custom and back to the starting page, I am relying on static variables in the class and some convoluted logic to avoid the user seeing his selections getting reset each time he visits the page. Of course behind the scene each selection on first page could be creating new controls behind the scene that don't get destroyed and never get displayed if selection changes on first page, so that is an additional problem. I think the solution is that MBSCustomPageManager should be initialized only once per wizard. So that we have a single instance of a custom page for an entire wizard session, that creates its controls once only. Would perhaps make sense to have MBSCutomPageManager as an instance in the wizard, instead of having static access. Each MBSWizardHandler might need to change the list of "stock pages" but does not have to do anything with the custom pages, they are shown depending on toolchain selection. This defect makes the custom pages feature almost unusable.
