From 7279f74fd0f1fc7ad0e7c6a67530bf438b28f294 Mon Sep 17 00:00:00 2001 From: Chris Recoskie Date: Fri, 9 Jun 2006 15:55:15 +0000 Subject: [PATCH] fix for 146239 from Beth Tibbitts, plus some other minor formatting and wording changes --- .../Managed_Build_Extensibility.html | 49 ++++++++++++------- 1 file changed, 30 insertions(+), 19 deletions(-) diff --git a/doc/org.eclipse.cdt.doc.isv/guide/mbs/extensibilityGuide/Managed_Build_Extensibility.html b/doc/org.eclipse.cdt.doc.isv/guide/mbs/extensibilityGuide/Managed_Build_Extensibility.html index a4736c46421..d7025e159f8 100644 --- a/doc/org.eclipse.cdt.doc.isv/guide/mbs/extensibilityGuide/Managed_Build_Extensibility.html +++ b/doc/org.eclipse.cdt.doc.isv/guide/mbs/extensibilityGuide/Managed_Build_Extensibility.html @@ -7006,16 +7006,26 @@ IWizardPage interface.
style="mso-bookmark:OLE_LINK10">Wizard pages as GUI elements by themselves are really not all that useful.  More than likely if someone is defining their own wizard pages -it?s because they need some additional operations to happen upon project +it's because they need some additional operations to happen upon project creation in addition to the stock behaviour of creating a basic project, and they want to use their new wizard pages to provide a front end to these operations.

-

As such, along with a specification + +

Note that during the display of the wizard page, and the user possibly +entering information, no permanent changes should be executed, since the user +can abort the creation of the new project at any time. For this reason, +the actual changes indicated on the wizard pages should be executed +once the user has completed the new project wizard: after the "Finish" button +has been selected. User data can be saved in a storage area for any of these +pages, and retrieved later when needed. + +

+As such, along with a specification of the GUI wizard page, ISVs may specify a runnable operation that will -be executed in the wizard?s doRunEpilogue() method.  These contributions will all be +be executed in the wizard's doRunEpilogue() method, +after the new project creation is committed. + +These contributions will all be executed in the order that the wizard pages were added to the wizard.  Not all pages need have such a contribution however, as ISVs may need to perform all the operations @@ -7089,7 +7099,7 @@ Element Schema:

which implements the added page.  This class must implement the org.eclipse.jface.wizard.IWizardPage + face="Courier New">org.eclipse.jface.wizard.IWizardPage interface

toolchain (§7.14.1.1.3) or project nature (§4.1.1.1.4).

+ style='mso-field-code:" REF _Ref98746447 \\r \\h "'>7.14.1.1.4).

projectType Element Schema:

  One instance of this element is provided per nature supported.

-

 This +

This would for example allow one to add pages to the New Managed C Project wizard but not the New Managed C++ project wizard, or other hypothetical natures that might be supported by MBS in the future (e.g. someday there @@ -7316,7 +7326,7 @@ might be a Fortran nature).

assumed that the page potentially applies to all project natures, although it may still be excluded based on project type (§7.14.1.1.2) or toolchain (§4.1.1.1.3)

+ style='mso-field-code:" REF _Ref98746447 \\r \\h "'>7.14.1.1.3)

natureID element Schema:

  This +


The main entry point to the system is a central manager class called MBSCustomPageManager.  This class is responsible for managing classes which handle the aggregation of page data (MBSCustomPageData).

For convenience sake, an abstract base class for wizard pages exists (MBSCustomPage) which ISVs can subclass to implement the default behaviour of @@ -7427,22 +7437,23 @@ make available to other pages


This class is a singleton. All non-constructor methods are static.

When the wizard is initialized, it -makes a call to MBSCustomPageManager.loadExtensions(). This method looks contributions to the org.eclipse.cdt.managedbuilder.ui.newWizardPages +makes a call to MBSCustomPageManager.loadExtensions(). This method looks for contributions to the org.eclipse.cdt.managedbuilder.ui.newWizardPages extension point.  The loaded data is used to instantiate and populate an MBSCustomPageData object for each page discovered.

As the user manipulates the wizard, each page can -publish data they wish to export for use by other pages.  This is done via the +publish data they wish to export for use by other pages, or for use by the optional Runnable operation that +may execute when the wizard pages are completed. +  This is done via the addPageProperty() method, which allows for the storage of string data by string key, using the string ID of the page as a sort of namespace.  The data can be -retrieved by other pages via the getPageProperty() method, and this is the standard way for pages to interface to eachother.

+retrieved by other pages via the getPageProperty() method, and this is the standard way for pages to interface to each other.

Individual pages are expected to somehow consult the getNextPage() and getPreviousPage() methods of the manager when their own getNextPage() and getPreviousPage() methods are called by the wizard.  This allows the -pages to properly navigate amongst eachother while taking into account +pages to properly navigate amongst each other while taking into account user choices such as project nature, toolchain, and project type.  It should be noted that the manager can only do so much as it fills the role of an advisor.7.14.3.2 MBSCustomPageData for the page manager to store information on a custom wizard page.  On startup, the page manager loads all contributions to the newWizardPages extension point, and -stores the loaded data in these records for later use. There is a nested class, ToochainData, which is used to maintain information on each individual toolchain a given custom page supports. The MBSCustomPage manager calls various methods on this class (e.g. MBSCustomPageData.shouldBeVisibleForNature()) to determine when a given page should be visible in the wizard.
+stores the loaded data in these records for later use. There is a nested class, ToolchainData, which is used to maintain information on each individual toolchain that a given custom page supports. The MBSCustomPage manager calls various methods on this class (e.g. MBSCustomPageData.shouldBeVisibleForNature()) to determine when a given page should be visible in the wizard.

@@ -7480,7 +7491,7 @@ implementation of the IWizardPage interface.  This class provides implementations of the getNextPage() and getPreviousPage() methods which consult with the page manager to determine which pages are to be -displayed.  If an ISV?s +displayed.  If an ISV's custom pages do not subclass MBSCustomPage then their page implementation must be carefully coded to function properly while still respecting the rules laid out by the page manager.