Looks like we have a problem that can be resolved using your approach.

However, we do not understand why following code works 99% of the times, but DID failed once or two.

We have a DeckWorkspace, it will ALWAYS display one of two views. Then we use following code to determine which view is active (displayed):

private ITemplateView CurrentTemplateView
{
get
{
if (object.ReferenceEquals(
this.LayoutWorkspace.ActiveSmartPart,
this._normalViewPresenter.View))
return this._normalViewPresenter.View;
else if (object.ReferenceEquals(
this.LayoutWorkspace.ActiveSmartPart,
this._designViewPresenter.View))
return this._designViewPresenter.View;
else
return null;
}
}

As I said, one of these two views will always displayed in the LayoutWorkspace(A DeckWorkspace), so it should never return null. But for a once or twice, it did. I believe there is an issue in the Workspace.ActiveSmartpart. Could you please clear our mind what is wrong?

Please help. We will highly appreciate it. Thanks a lot.

John

I’ll use your argument, but it has not worked in the past

Anxiously awaiting your post about the full UIService!

Modifying CAB was indeed one of the first solutions I looked at after we came up with the idea for the Guid’s to uniquely identify the views. My thought was: lets not have to sprinkle code everywhere to maintain the active view, let’s just modify the Workspaces and have them do it automatically.

Unfortunately, a few problems arise from the way I chose to go about it, and it was due to my desire to simply augment the Show() method. The biggest problem we ran into is that Maintenance is still required by the developer; the programmer has to know the order of views being displayed when you’re dealing with nested Workspaces (as we have happen with great regularity in our app). It’s not uncommon for us to have a DeckWorkspace view that has a nested DeckWorkspace view on it, and a TabWorkspaces view on that. In order to make sure that the UserControl on a TabWorkspace view is the “active” view when Show() was called, the Deckworkspaces have to be displayed in order from top-down, until the UserControl on the TabWorkspace is the last view activated. Otherwise, suppose the UserControl on the TabWorkspace gets Shown first; then the DeckWorkspace view becomes the “active” view, which isn’t what we really wanted.

So, there’s some ordering issues that had to happen, and personally I dislike having to manage the “order” of my code in an event-driven environment. I would much rather explicitly call a service and tell it “this view is the active view under these conditions” and not have to worry about all of the other workspace and views and whether they’re being shown in any specific order or not (because to the end user it all looks instantaneous anyway).

I had not thought, however, about providing a separate method instead of Show() that would be called something like ShowActiveView(). It would have the same signature as the overrides of Show() I imagine, only it would perform the additional task of setting the ActiveView Guid on the UIService (or some other feature more closely integrated with CAB) prior to calling Show() internally.

I like the idea.

As to the Pros/Cons of modifying CAB: I’ve modified the CAB ever so slightly before for certain things. However, as with all 3rd party applications/frameworks/etc., when you modify something the biggest con is that when the vendor releases a new version, you have to make sure your changes don’t get lost.

Now, with the announcement of Acropolis the P&P team is not going to be doing much more to CAB, so it’s probably safe to modify it.

The other thing I’d consider when making the pitch to your project lead: Frameworks like CAB rarely do everything you want exactly the way you want them to be done. The power in owning a framework like CAB, which makes its source and unit tests fully available, is that you *can* modify it to suit your needs.