ProjectBrowser view type and ViewActivated event

[Sherbs]

Hi Folks,

Using the 2015 API...

Perhaps I'm thinking of this the wrong way but something here just doesn't seem consistent...

In my app, I've wired up to the UIApplication.ViewActivated event.  I do this to understand when the user has changed views and/or documents.

What I've found though, is that if the user enters the project browser (or system browser) and takes some action, these "views" become my active view (as verified by checking Document.ActiveView.ViewType).  But, I don't get any sort of callback into my ViewActivated event handler even though my active view has obviously changed from, lets say a ViewType.FloorPlan to ViewType.ProjectBrowser.

Are these windows really considered views in the same sense as the other ViewTypes?  If so, why aren't they treated consistently in terms of triggering a ViewActivated event?

What led to this discovery is that I've found that if I call PromptForFamilyInstancePlacement while the ProjectBrowser is the active view, I get an internal revit exception from which recovery is 50/50 at best.

I could make better decisions in my application if I know ahead of time that the user is in specific types of views before they try to take some action.

Am I just looking at this the wrong way or am I missing something in its entirety here?

Its a bit confusing that there are view types of ProjectBrowser and SystemBrowser in the same enum that FloorPlan, CeilingPlan, Detail, and other such views.  To me they are very different things.

Thanks much for any input!

-G

[arnostlobel]

Hello Sherbs!

The answer is not going to be easy, but I'll try my best.

First of all, to answer one of the core questions in your post: No, a Project Browser is not considered to be the same kind of a view like the standard documents views are. And that is why the view events are only fired for the latter type, not the former.

Then you rightly asked why there are were the views under the same, common ViewType Enumeration. That is a good question, indeed. I believe it is mostly for internal, but also historical and compatibility reasons. We did not always have all the types exposed since the inception of the API. Non-Graphical views were under the common "internal" type. However, there were cases when users wanted to get more detailed information about them, thus we added special types for those special views. And they are all within the same enumeration because internally they share more data and functionality than what they do not share. I do not want to (and cannot, in fact) go into all details, but just in a nutshell, we have about three kinds of view classes per each exposed API View. All the views have, internally, at least one of the internal view instances, and that is the most important aspect for us (internally). That is why we can treat them all the same, uniformly, to a degree. However, the Views you can draw stuff in have all special graphic context attached to them, which makes them applicable for drawing.

I think that is enough of theory. Practically, it is in your control to know what kind of view you are in at any given time. Beginning with R2015 user have two properties available in the UIDocument class. ActiveView and ActiveGraphicalView. The former one is the one we have always had. It could therefore return one of the "system" views as the currently active one. The latter one, new in R2015, returns the currently active graphical of the current document, even when it is not the actually active view (meaning, it does not have the focus).

I believe the problem with PromptForFamilyInstancePlacement while in a system view has been fixed already (not released yet though.) I will double-check on this one and if it is not I will make sure a bug is filed and addressed accordingly.

By the way, try to stay away from the Document.ActiveView property. Use UIDocument.ActiveView instead. The former is kept in the API for backward compatibility only (since times we did not have UIDocument yet) and will be eventually obsoleted.

[Sherbs]

Thanks much Arnošt!

Really appreciate the quick response & detailed explanation.  As of now, my app is being defensive and checking the active view type before calling into PromptForFamilyInstancePlacement.

I'll look more into ActiveGraphicalView as well and see how I can take advantage of it either now or in the future.  Will also update my code to use UIDocument.ActiveView.

It would seem that, once the fix for PromptForFamilyInstancePlacement is released, I may not have particular need to do this defensive check at all.

Looking forward to the update!

-Greg-