By Terry Carroll - 3/9/2011
Has anyone had problems with modal forms not staying on top?
Intermittently while running an application in debug mode, a browsedialog will open then abruptly move under its parent window. When this happens the only out is to stop debugging. This has been occurring on and off for months.
Also from the object mapper when I try to open the dialog to select a table from a SQL database the form moves to the back and can’t be selected. The only option I have found is to move the configuration property form well off the desktop with only the Select button visible. When the Select button is clicked the form with the list of databases can be selected. However it will not move to the front.
Windows option to cascade or set side by side etc. has no effect.
I’m using Windows 7 Ultimate 64 bit, VS 2010 Version 10.0.30319.1
Not yet a work stopper, but it’s annoying.
Terry C
|
By Ivan George Borges - 3/9/2011
Hi Terry.
Just to let you know, I work on the same configuration over here and have not experienced this. Working on debug mode and setting brake points might have an effect on modal screens, maybe this could be it.
|
By Trent L. Taylor - 3/10/2011
Ivan is correct in regards to a debug environment. Things fire slightly differently when in a debug environment which can cause a modality issue. However, you can control the parent or owner of any dialog you call, including a browse dialog. You can pass in a IWin32Window that will tell the modal form being called to whom it belongs. This can prevent these types of issues. The issue you are running into can happen at run-time as well under certain conditions and is related to Windows and the handle management. The deeper that you go in modality, the more possibility there is for this to happen.
That is why they introduced this logic, way back when, so that you can complete control of ownership instead of the ownership being interpreted. My most recent frustration with this was dealing with type editors. In our medical application we have our own screen generator to build charting screens. We have used the PropertyGrid with many customizations. But the beauty is that we can take advantage of the type editors, etc. Modality and window ownership goes to a new height in this environment!  So this logic can be very help then.
Just FYI, most likely won't resolve a debug scenario, but it is the run-time that really matters.
using System; using System.Collections.Generic; using System.Text; namespace MicroFour.StrataFrame { using System.Windows.Forms; public class Win32Window : IWin32Window { #region [ Constructors ] /// <summary> /// Default constructor /// </summary> /// <param name="hwnd"></param> public Win32Window(IntPtr hwnd) { this._hwnd = hwnd; } #endregion #region [ Public Properties ] private IntPtr _hwnd; public System.IntPtr Handle { get { return _hwnd; } } #endregion } }
You then use the class like this. Let's assume I am on a form calling a modal form:
MyModalForm f = new MyModalForm();
f.ShowDialog(new Win32Window(this.Handle));
Any control that has a handle can be used.
|
By Terry Carroll - 3/10/2011
Thank you for the tip. That should work with all of my code, however while in visual studio the Strataframe Object mapper is very hard to use because the modal forms keep going to the back. Do you use this technique in the Object Mapper Add-In?
Terry
|
By Trent L. Taylor - 3/10/2011
Hmmmmm....I guess I hadn't read enough before I answered. I have not experienced this inside of the VS IDE....well, with StrataFrame anyway. What all add-ins do you have in VS? Is there a consistent way that you can reproduce this?
|
By Terry Carroll - 3/15/2011
No, I haven’t seen the issue in any other addins. Another Strataframe developer I work with has experienced the behavior with the browsedialog but not with the Mapper. Even with the browsedialog the problem seems to manifest itself when the wait window appears during a search. Seems like the wait window wants to be the top window and somehow sends the underlying modal form behind the previous form.
I will continue to investigate this on my end. It’s probably something unique to my machine setup.
It’s not a work stopper, just wanted to know if anyone else has had the same experience.
Terry
|
By Trent L. Taylor - 3/15/2011
Well, I want to see if I can reproduce it as well. You mentioned that this was happening as part of the BrowseDialog. But I can't think of a place that the BrowseDialog itself is executed within the designer. However, there are type editors that come up when looking for an Enum, etc. What are the steps that you most commonly use to get this to happen?
|
By Terry Carroll - 3/17/2011
The issue with the browsedialog is completely different from the one with the Object Mapper, although similar. With regards to the browsedialog I have learned how to correct it. When a calling forms “TopMost” is set to true a browsedialog opened will not come to the top unless it’s property, ForceWindowTopMost is set to True. That issue is fixed.
The second issue is with the Object Mapper. With the Object Mapper form open, I select “properties” for a business object and when I click the button “Select Source” the source selection form moves behind the properties form and then they both move behind the Object Mapper. Only by arranging the forms partially off the desktop I’m I able to see the “Select Source” form. It reacts similar to the browsedialog, so I suspected the Property and Source form should also have their form property TopMost set to True.
Other Strataframe users I know have not experienced this behavior. In the event it happens to other users maybe setting the “TopMost” on the Modal forms will eliminate this behavior. As I have said before, I can live with it.
Thank You for your time.
Terry Carroll
|
By Trent L. Taylor - 3/18/2011
Thanks for the tip. I will look at this to see if there is something that could help prevent this.
|