in the dialog InstallationProgress the control IDC_PARCEL_STATUS, at runtime, there isn't shown the current installing package. I get allways shown the next one or perhaps the last one.
I don't think there's going to be a workaround for this. I'll look into this to see if I can reproduce it internally, or if we've already fixed it for the SP. I assume the reproduction steps are something like: create a suite that installs three .msi files with different names that take long enough for you to tell if the messages are correct. Run and observe.
Okay, I've verified this, and it will be fixed by the SP. It appears to me that we have two semantically hierarchical messages (ISInstallStatus and ISParcelStatus), and changes to the former were not updating the latter. This led to stale information being shown. The fix will clear out or otherwise update ISParcelStatus when updating ISInstallStatus.
Michael, It would be awesome if there was a list box below the progress bar that displayed all features selected for install and highlighted the feature currently being installed. This would be useful when you have multiple features and have selected a subset of those to be installed. Is that possible?
I don't think you can put this together. We might be able to, but there's one fundamental disconnect. We show a tree of Suite features to the end user, but we do not ever really install a feature as such. Instead we traverse the feature tree to figure out whether packages need to be installed, removed, or whatever.
In a simple scenario, you might have a single feature for each package, so you could map back from package to feature. However that doesn't address the different orderings possible - either the features would install out of order, or we'd have to reorder them to reflect package order. In a more complex scenario where a single package is associated with multiple features, I'm not even sure what this should show. Would both features be in the process of installing?
Michael, I think I see what you are saying. My current project is rather simple in that there is one package per feature. I think what you are saying is that there could be multiple packages per feature and some of those packages could be associated with more than one feature. Yikes! As you implied... not so easy.
Right, that's definitely the problem. I'm not sure what the solution is. It could be a matter of documenting how it works and suggesting people only use the theoretical control if they have a simple case and their package order corresponds. Or it could be to come up with "good" behavior for those cases; figure out a way to say which is the canonical feature which a package corresponds to, etc.
