Without selecting/entering any name for the configuration, it is allowed to move to next screen. Is this correct behavior? Also, there is no default configuration name exists.

changed to P1

Still need to implement combobox logic for list of customizations. The existing behavior writes output to the current working directory. This is definitely a P1 bug. Moving TFV to M7.

We can't do this in M7.

Reality check. Major work on CCK won't happen until profile manager is done. Moving these to M10 as a group. Feel free to bring them in if possible :-)

We can brand this as 'cache' bug. Right now, the cck.che file gets created as a sibling to exe file. So, in WizardMachine.cpp, when we load cache file, we load it directly i.e., with no path involved. When create a new customization, that gets added to the customizations combobox. The name of the customozation will be the name of the folder and it will be created under the folder name 'customizations'. Cache (cck.che) related to that cutomization lives under that folder. As wizardmachine searches for the cache file, it creates a one if it does not exists. As we select a customization, we need to remember the name of the customization as that constitues the name of the path to reach the cck.che of that customization. But we need to remember the name of the customization selected too, as we run the app for the second time. So, in the past we thought of having a separate cache for the customization selected and then derive the cahce file for new customization for the rest of the app from the combobox (customizations picker). WizardUI.cpp is the UI file handling all the events.

A number of changes were required before implementing this fix. SetGlobals now used findWidget and overwrites values if found. FillGlobalWidgetArray now uses SetGlobals. ComboBox handling now remembers which item was selected or selects item #0 if none. onNext handling is now implemented and interprets the commands Reload and VerifySet. The Reload command changes the CachePath and tries to load it on top of the existing globals. This has the effect of making the top-level cache file become the defaults for new configs. To test this, try the various combinations of actions available on the first page that include the combobox and the next button. The only case I know it won't handle gracefully is if we don't have write access to the customizations directory - oh well...

marking this Verified Fixed