The below is an involved problem, I've done a great amount of research, but have been unable to solve it thus far. I'm happy to find either a solution or a workaround. Although the framework is old (1.0) I am not at this stage able to upgrade to 1.1 or later (the client isn't willing to pay for the conversion at present), and I'm not even sure that this would solve the problem... Any help is much appreciated :
Platform : .NET 1.0 VB.NET Windows Forms MDI application running on Windows XP
Problem : An MDI child window (child1) calls the .Show()
method of a different MDI child window (child2) and a NullReferenceException
is thrown.
This only happens from one particular form (child1), and only when that child form is in a maximized state, and the MDI parent window is also in a maximized state.
The exception is thrown for any other child form that is opened from code within child1 (i.e. the error is not isolated to opening one type of form).
The exception is only thrown when running from the debugger with 'Break Into The Debugger When An Exception Is Thrown' on (although this error is manifesting itself later on which is the real problem). This behaviour seems to be explained in the framework in so far as an exception is caught but nothing is done with it (see reflected code below).
The exception seems to be being thrown from within the framework (1.0) itself. See the stack trace below:
system.windows.forms.dll!System.Windows.Forms.NativeWindow::WindowClassCallback(__int32 hWnd = 461572, __int32 msg = 36, __int32 wparam = 0, __int32 lparam = 1239164) + 0x48 bytes
system.windows.forms.dll!System.Windows.Forms.UnsafeNativeMethods::CreateWindowEx(__int32 dwExStyle = 327744, String* lpszClassName = 'WindowsForms10.Window.8.app13', String* lpszWindowName = 'Diary Entry: ROSIE MILES', __int32 style = 1204748288, __int32 x = -2147483648, __int32 y = -2147483648, __int32 width = 480, __int32 height = 380, __int32 hWndParent = 920114, __int32 hMenu = 0, __int32 hInst = 285212672, System.Object pvParam = null) + 0x3c bytes
system.windows.forms.dll!System.Windows.Forms.NativeWindow::CreateHandle(System.Windows.Forms.CreateParams cp = {System.Windows.Forms.CreateParams}) + 0x1d6 bytes
system.windows.forms.dll!System.Windows.Forms.Control::CreateHandle() + 0x19a bytes
system.windows.forms.dll!System.Windows.Forms.Form::CreateHandle() + 0x12f bytes
system.windows.forms.dll!System.Windows.Forms.Control::get_Handle() + 0x2f bytes
system.windows.forms.dll!System.Windows.Forms.Form::SetVisibleCore(bool value = true) + 0x1e9 bytes
system.windows.forms.dll!System.Windows.Forms.Control::set_Visible(bool value = true) + 0x1e bytes
system.windows.forms.dll!System.Windows.Forms.Control::Show() + 0x14 bytes
> SpecMed.exe!SpecMed.ScheduleForm.viewScheduleMenuItem_Click(Object sender = {System.Windows.Forms.MenuItem}, System.EventArgs e = {System.EventArgs}) Line 1508 + 0xb bytes Basic
system.windows.forms.dll!System.Windows.Forms.MenuItem::OnClick(System.EventArgs e = {System.EventArgs}) + 0x8d bytes
system.windows.forms.dll!MenuItemData::Execute() + 0x1e bytes
system.windows.forms.dll!System.Windows.Forms.Command::Invoke() + 0x4c bytes
system.windows.forms.dll!System.Windows.Forms.Command::DispatchID(__int32 id = 299) + 0x2c bytes
system.windows.forms.dll!System.Windows.Forms.Control::WmCommand(System.Windows.Forms.Message m = {System.Windows.Forms.Message}) + 0x4a bytes
system.windows.forms.dll!System.Windows.Forms.Control::WndProc(System.Windows.Forms.Message m = {System.Windows.Forms.Message}) + 0x1f3 bytes
system.windows.forms.dll!ControlNativeWindow::OnMessage(System.Windows.Forms.Message m = {System.Windows.Forms.Message}) + 0x19 bytes
system.windows.forms.dll!ControlNativeWindow::WndProc(System.Windows.Forms.Message m = {System.Windows.Forms.Message}) + 0xda bytes
system.windows.forms.dll!System.Windows.Forms.NativeWindow::Callback(__int32 hWnd = 6621754, __int32 msg = 273, __int32 wparam = 299, __int32 lparam = 0) + 0x4a bytes
system.windows.forms.dll!System.Windows.Forms.Application::ComponentManagerSystem.Windows.Forms.UnsafeNativeMethods+IMsoComponentManager.FPushMessageLoop(__int32 dwComponentID = 1, __int32 reason = -1, __int32 pvLoopData = 0) + 0x2c1 bytes
system.windows.forms.dll!ThreadContext::RunMessageLoop(__int32 reason = -1, System.Windows.Forms.ApplicationContext context = {System.Windows.Forms.ApplicationContext}) + 0x1c5 bytes
system.windows.forms.dll!System.Windows.Forms.Application::Run(System.Windows.Forms.Form mainForm = {SpecMed.MainForm}) + 0x34 bytes
SpecMed.exe!SpecMed.Program.Main() Line 15 + 0x1d bytes Basic
I have reflected this method on the off-chance of gaining some insight into the problem. The code for WindowClass.Callback() method is:
public IntPtr Callback(IntPtr hWnd, int msg, IntPtr wparam, IntPtr lparam)
{
try
{
UnsafeNativeMethods.SetWindowLong(hWnd, -4, this.defWindowProc);
this.targetWindow.AssignHandle(hWnd);
return this.targetWindow.Callback(hWnd, msg, wparam, lparam);
}
catch (Exception)
{
}
return IntPtr.Zero;
}
As you can see, the exception is caught but nothing is done with it.
UI Manifestation :
The cause of this exception then seems to manifest itself later on, with terrible behaviour of the calling (child1) and called (child2) child forms .
In the UI, even thought he exception is ignored the MDI parent displays two MDI Child control boxes (i.e. two sets of minimise, restore and close boxes) and two child icons (see screenshots). One control box is disabled.
alt text http://www.freeimagehosting.net/uploads/a65a085cd3.jpg alt text http://www.freeimagehosting.net/uploads/fcbee0eccf.jpg
After closing the child2 form, child1 becomes non-responsive and fails to repaint.
Research :
Searching on the web, I've found the following articles, which seem to describe similar or almost identical problems (but on different frameworks), but none of these solutions have helped.
http://social.msdn.microsoft.com/Forums/en-US/winforms/thread/66cee5a3-c743-4be6-ae63-7416b81a9688/ (Sounds like exactly the same problems, but no solution seems to have ever been posted).
http://support.microsoft.com/kb/871045 (Similar but not the same problems, solution doesn't seem to help).
http://www.devnewsgroups.net/group/microsoft.public.dotnet.framework.windowsforms/topic39112.aspx : (Sounds like the same problem, but for different framework).
The calling child form (child1), has some third-party controls on it (Janus WinForms Suite), which I suspect are somehow causing the problem. These controls are .NET controls and not Activex.
Attempted Solutions
I've tried raising an event on child1, that the MDI Parent handles, and then the MDI Parent opens child2. Still the same problem.
I've tried setting the MDI parent of child2 , after child1 calls the child2.Show(). Still no improvement.
I've tried setting the MDI Parent of child2 prior to the child2.InitialiseComponents() call. No improvement.
After typing all this, I'm starting to think that the problem isn't with calling child2 as such, but rather how child1 is being handled when child2 is opened, maximized and therefore sending child1 behind it?
If anyone can help me out, or point in me the right direction, I sure would appreciate it.
Thanks
Answers:
Workaround :
I've found a workaround, that isn't particularly elegant, but currently seems to work:
By checking if the calling form is maximised and storing this, it is then possible to minimise (or restore) the calling form prior to the .Show() call (preventing the problem), then setting the called forms WindowState to maximised. Setting the called forms state to maximised emulates the behaviour of what should normally happen (apart from a bit of flickering with the resizing of forms).
Code :
'-- workaround to prevent UI problem with maximised child form calling another maxmised child form --'
Dim isMaximised As Boolean = (WindowState = FormWindowState.Maximized)
'-- minimise the current form so the problem wont occur when we call the new child Form --'
If isMaximised Then WindowState = FormWindowState.Minimized
Dim form As DiaryEntryForm = DiaryEntryForm.GetForm(scheduleId, Me)
'-- if the calling child was originally maximised, then maximsed the called form to similute what should normally happen --'
If isMaximised Then form.WindowState = FormWindowState.Maximized
form.Show()
I'll keep trying to find a solution however. Any help appreciated. Thanks.
Answers:
Are you attempting to merge menus as a part of the MDI child showing? If so you may be running into this issue
http://support.microsoft.com/kb/895579
The hotfix there will work around the problem if it's the one you're seeing.
No comments:
Post a Comment