ShowModelessDialog and disappearing dialogs

[mohnston]

I'm posting both my problem and solution here in the hopes that it saves a programmer some time and frustration. Feel free to comment and critique.

The problem had to do with the ShowModelessDialog mechanism remembering my dialog size and location.
Normally this would be a good thing and I would welcome it . . . however I have some users with dual monitors.
They would move my dialog to a second screen, then sometime later would go from two monitors to one. (this can also happen if a user changes resolution)
My dialog would show up off screen. (Bad programmer, you should check for such things)
So I wrote a function (stack-overflow copy paste) to check to see if the form is on a screen and if not set it's location to someplace that is visible.
That should work except the ShowModelessDialog mechanism forces to form to the location *it* remembers and ignores mine.

The solution was to use what was already in the API.
Application.ShowModelessDialog(null, new frmMyForm(), false);
The last argument is persistSizeAndPosition (should be persistSizeAndLocation) and setting it to false gave me back control of my form's location.

By the way, I had to set the first argument to null to get it to work.
I tried (as suggested elsewhere) Application.ShowModelessDialog(Application.MainWindow, new frmMyForm(), false);
But the compiler complained about Application.MainWindow not being a System.IntPtr blah blah blah.
The help said this: "This method calls the ShowModelessDialog(System.Windows.Forms.IWin32Window owner, System.Windows.Forms.Form formToShow) method with owner set to null."
So I set it to null and it stopped complaining.

I'm working with AutoCAD 2010 - VS 2008

[Anonymous]

Mark - The problem you noted with the first argument to ShowModelessDialog
has to do with changes in the AutoCAD API, that results in confusion between
two interfaces with the same name:

System.Windows.IWin32Window

System.Windows.Forms.IWin32Window

In earler releases, the object returned by the Application's MainWindow
property implements the second interface above. On AutoCAD 2010, it was
changed to implement the other one (System.Windows.IWin32Window).

In earlier releases, you could pass the value of the MainWindow property,
but in 2010, you have to pass the handle instead, like this:

ShowModelessDialog( Application.MainWindow.Handle... )

There's another aspect to this problem (Autodesk actually botched this one),
that also breaks a lot of existing WinForms-based applications.

On AutoCAD 2010, any APIs that used to take the IWin32Window
interface from System.Windows.Forms, now requires the same-
named interface from System.Windows.

If you are not using WPF, and need to pass the AutoCAD MainWindow
to an API that requires a System.Windows.Forms.IWin32Window, here
is how to do it:

{code}

using Autodesk.AutoCAD.ApplicationServices;

// Note that this class implements the IWin32Window
// interface from System.Windows.Forms, rather than
// the one from System.Windows:

public class AcadMainWindow : System.Windows.Forms.IWin32Window
{
public IntPtr Handle
{
get
{
return Application.MainWindow.Handle;
}
}
}

// Example using System.Windows.Forms.MessageBox.Show:

using System.Windows.Forms;
using Acad = Autodesk.AutoCAD.ApplicationServices.Application;

public class class1
{
public static void ShowMessageBox()
{
// This worked in AutoCAD 2009 or earlier, but will NOT
// work in AutoCAD 2010 or later:

MessageBox.Show( Acad.MainWindow, "Hello World");

// This will work in any release:

MessageBox.Show( new AcadMainWindow(), "Hello World");
}
}

{code}


--
http://www.caddzone.com

AcadXTabs: MDI Document Tabs for AutoCAD
Supporting AutoCAD 2000 through 2010

http://www.acadxtabs.com

Email: string.Format("{0}@{1}.com", "tonyt", "caddzone");

wrote in message news:6283655@discussion.autodesk.com...
I'm posting both my problem and solution here in the hopes that it saves a
programmer some time and frustration. Feel free to comment and critique.

The problem had to do with the ShowModelessDialog mechanism remembering my
dialog size and location.
Normally this would be a good thing and I would welcome it . . . however I
have some users with dual monitors.
They would move my dialog to a second screen, then sometime later would go
from two monitors to one. (this can also happen if a user changes
resolution)
My dialog would show up off screen. (Bad programmer, you should check for
such things)
So I wrote a function (stack-overflow copy paste) to check to see if the
form is on a screen and if not set it's location to someplace that is
visible.
That should work except the ShowModelessDialog mechanism forces to form to
the location *it* remembers and ignores mine.

The solution was to use what was already in the API.
Application.ShowModelessDialog(null, new frmMyForm(), false);
The last argument is persistSizeAndPosition (should be
persistSizeAndLocation) and setting it to false gave me back control of my
form's location.

By the way, I had to set the first argument to null to get it to work.
I tried (as suggested elsewhere)
Application.ShowModelessDialog(Application.MainWindow, new frmMyForm(),
false);
But the compiler complained about Application.MainWindow not being a
System.IntPtr blah blah blah.
The help said this: "This method calls the
ShowModelessDialog(System.Windows.Forms.IWin32Window owner,
System.Windows.Forms.Form formToShow) method with owner set to null."
So I set it to null and it stopped complaining.

I'm working with AutoCAD 2010 - VS 2008

[mohnston]

The help file is incorrect then. But as usual your answer got me thinking.

I don't know if there is a question here anywhere but here goes.
One signature allows me to pass just the form to ShowModelessDialog and it works fine.
Internally null is passed as the first (owner) argument.
I think it works something like this pseudo code.
ShowModelessDialog(Form form)
{
ShowModelessDialog(null, form);
}

ShowModelessDialog(System.Windows.IWin32Window owner, Form form)
{
If (owner == null)
{
owner = GetAutoCADMainWindow();
}
// Handle form here
}

I wonder then why not just pass null and not worry about the owner? Or even why have an owner argument at all?
Or is the owner argument there in case there are multiple sessions of AutoCAD?

(What do you know, a couple of questions and a question/answer.) Edited by: mohnston on Nov 5, 2009 8:43 AM

[Anonymous]

If you pass null for the IWin32Window, the active window is used
(via the GetActiveWindow() Windows API).

In most cases it would not matter, except perhaps when you have
a form that might be displayed from another active Form in some
cases, and by itself in others.

--
http://www.caddzone.com

AcadXTabs: MDI Document Tabs for AutoCAD
Supporting AutoCAD 2000 through 2010

http://www.acadxtabs.com

Email: string.Format("{0}@{1}.com", "tonyt", "caddzone");

wrote in message news:6284225@discussion.autodesk.com...
The help file is incorrect then. But as usual your answer got me thinking.

I don't know if there is a question here anywhere but here goes.
One signature allows me to pass just the form to ShowModelessDialog and it
works fine.
Internally null is passed as the first (owner) argument.
I think it works something like this pseudo code.
ShowModelessDialog(Form form)
{
ShowModelessDialog(null, form);
}

ShowModelessDialog(System.Windows.IWin32Window owner, Form form)
{
If (owner == null)
{
owner = GetAutoCADMainWindow();
}
// Handle form here
}

I wonder then why not just pass null and not worry about the owner? Or even
why have an owner argument at all?
Or is the owner argument there in case there are multiple sessions of
AutoCAD?

(What do you know, a couple of questions and a question/answer.)

Edited by: mohnston on Nov 5, 2009 8:43 AM