UI Freezes when opening families in command while debugging

[swfaust]

I have an application that needs to pull the list of types from within a family.  It does this with this simple method:

        public void PopulateTypes(FamilyData family)
        {
            var doc = _revitApp.OpenDocumentFile(family.FilePath);
            if (!doc.IsFamilyDocument)
                throw new InvalidOperationException("Only families can be processed");

            foreach (var type in doc.FamilyManager.Types.Cast<FamilyType>())
            {
                family.Types.Add(new TypeData(type.Name));
            }

            doc.Close(false);
        }

Basically it just opens the family, reads the types into my data objects, and then closes it.  This happens from a view model of a dialog I'm running.  The dialog is in 'ShowDialog()' mode in the middle of my command so it isn't returning anything to Revit and should still be in a valid API context.  This dialog has 'pages' that it goes through and after this happens it should go to the next page.

The problem is that when I tell it to go to the next page it acts like it is but never updates the UI.  It's even more strange because I can click on the dialog close button and it actually closes but everything else is frozen.

I've tried with nothing in this method (which obviously doesn't populate the types then) and it works and turns the page properly.  I also tried it with just opening and closing the family (not pulling any types) with just one family and it still freezes.

This seems to be only when debugging, when I run it normally it seems to work.  I guess that's ok, but it makes it hard to debug those routines...

Anyone have any idea why this would freeze up the UI thread (at least that's what I'm guessing is happening) but only with debugger attached? 

[swfaust · Accepted solution]

Sorry, disregard.  This must have been something weird with my machine.  I started noticing a few other weird things with Visual Studio so I restarted and now it's working as expected with the Debugger as well as without...

If admins want to delete this post feel free, I don't see a way for me to do it on my own.

[jeremytammik]

Oops, I posted this without noticing your second notice.

Anyway, my following thoughts still apply; they describe how I would go about it, as a UI avoider:

The Revit API context runs in a single thread, and that thread is shared by Revit. Hence, one can block the other. The modal dialogue blocks things too, and so does the debugger. Result: complication and confusion. I suggest you try to close or hide your model dialogue before trying to change anything in the Revit UI. Why do you need a user interface and a dialogue at all? It sounds as if all your worries would disappear if you simply rewrote this as a batch process. Display the dialogue first, gather input from the user, close the dialogue and do the work. 

[swfaust]

Fair enough, but generally this type of thing works in my experience unless it's actually blocking the thread.  In this case I could step through my code and verify that it completed so there shouldn't be anything blocking.  Also going without UI is fine in some cases but wouldn't work in this case as it was fetching data from Revit that was needed for the next update of the UI.

Anyway, as mentioned it was just some type of temporal glitch in my VS it seems so all is well.  Thanks for the response.