Topic Designer hangs VS2008

Topics: Bugs
Jul 29, 2010 at 6:26 AM
Edited Jul 29, 2010 at 6:29 AM

The toolbar option "Topic Designer for the active DocProject" will hang VS. Only way to fix it is to use Task Manager to kill the process.

Hang happens with toolbar or when trying to open "Topic Designer" from the project properties page.

"Topic Explorer for the active DocProject or DocSite" opens without a problem.

Any idea what may be wrong?


Jul 29, 2010 at 6:48 AM


That's a new one.  I don't recall ever experiencing this myself or anybody else reporting it.  I wonder if it has something to do with loading the files from disc.  If you're running Vista or Win 7, and you have UAC enabled, and your project is located in an unsafe location (such as C:\Projects\...), then please try starting VS as an Administrator, if you're not already.  Ok, that's a long shot.

Another option would be to run two instances of VS and attach one to the other.  Then click the Topic Designer button in the other and break into the former.  You may be able to locate the managed thread that DocProject is using in the VS Threads window.  Please send me the stack trace if you can.  You may also want to wait a few seconds and then break again, just to see if the stack changes at all.

- Dave

Jul 29, 2010 at 10:01 PM

Solution found, see below.

Initial response: It looks like it's trying to display DocProject.SandCastle.ContentManagement.XmlContentDialog. I'm positive that the modal form is being launched but it's just not visible in my display. I can see Topic Designer in the list of Windows. but I have two monitors, 1680x1050 each. The form may be displaying off-screen, or perhaps not visible, or maybe with a height/width of 0/0.

Solution: I used the WinXP keyboard tricks to (alt+tab, then alt+space,m) to get a hold of the window even though I couldn't see it. I then used the arrow keys until the window moved onto my screen. I have no idea where it was but the x,y was certainly off at form.Show.

Thanks Dave.


Jul 30, 2010 at 5:15 AM


Thanks for following up.

DocProject supports multiple monitors and remembers the last position of its dialogs.  It was designed for desktop scenarios, however, so if you're using a laptop and you have multiple docks that use different mutli-monitor setups, then perhaps you had opened the window on a peripheral monitor, moved the laptop, and then tried to open the dialog on a different setup where the position values were off-screen.  Is this an accurate description?

I'll create a work item to investigate whether it's possible to check the last screen coordinates against the current monitor setup and then default to center screen if the coordinates are not longer valid.

- Dave

Jul 30, 2010 at 5:20 AM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.
Jul 30, 2010 at 5:35 PM
Edited Jul 30, 2010 at 5:37 PM

Hi Dave, Can not view the Issue at the moment as TFS is not accessible (The Team Foundation Server is currently unavailable. Cannot view work item at this time.)
So I will post here, this may not be accurate but is some of my notes when I was working this out myself. typically nothing will go wrong if the Dialogue/SubForm is bound to the parent correctly example: new SubForm(this); // where this is Registering with the SubForm as the Parent.

This was common in a few of my applications (loosing dialogues/forms off the screen causing what would appear to be a hang as the user describes) after saving the user setting positions but on the next run the monitor may not be plugged in or the settings have changed for the resolution and so on.

The solution is really simple. You can get the Screen Size, its actual working area (minus the start bar/side bar etc)

Bind these outputs to some labels and see if this helps anyway.

        private Screen CurrentScreen { get { return Screen.FromControl(this); } }

        private void OnUpdate()
            CurrentScreen.DeviceName; // the GraphicsDisplays Name for the Device
            CurrentScreen.WorkingArea.ToString(); //(this will give you the working area your Control can fit within the viewable area of the screen)
            CurrentScreen.Bounds.ToString(); // returns actual bounds of the screen (this is the working area + any other area taken up from the likes of the start bar/side bar if they are in fixed mode)
            CurrentScreen.Primary.ToString(); // returns true if the primary monitor.
            Screen.AllScreens.Length.ToString() // Number of available monitors (switched on)
The aim of this is to check the controls size (from your control) when its loaded/updated to ensure it is not to big for the screen.

Now that you no where you can display the control all you need to do is verify how big your control is from its Location .Y and .X and the controls Width and Height. Then comes some math.

The aim of this is to check the controls position (from your control) when its loaded/updated to ensure it did not just fly off the screen.

My laptops main screen starts at pixel 0 (CurrentScreen.WorkingArea.X witch is the upper left corner, If I change my settings this can change) and ends at pixel 1280 (get this from CurrentScreen.WorkingArea.Width) so my control needs to fit here, for the width of my control is 1200 then I can calculate and move it to ensure its between CurrentScreen.WorkingArea.X 0 to 280 so 280/2 is 140. Simple Centering, bind this back to your controls.X that simple and most people stop here and have forms that go off the bottom of the screen so do this for the height also and adjust any sizes for your control if its just to big,

By the way if its a MainForm then you can just call this.CenterToScreen(), If its a SubForm/Dialogue then better to use this.CenterToParent()

using the working area of the current screen you can get a lot of information to ensure things go as expected in regards to displaying.

Hope that is enough info and what you are needing to get this working. TIP, make a base class that all ways performs these actions so you can use it in other apps.




Aug 5, 2010 at 1:44 PM


Thanks for the tips, I'll look into it.

- Dave