Hi all,
I have a really odd problem with some Visual Basic .NET 2003 code;
I have a program that creates a number of windows which contain
RichTextBox, Timers (disabled) and menus. The code runs fine and
creates the windows as required, BUT if the program is left to do
nothing for several hours, when it is brought back into focus it
generates an exception error (Object reference not set to instance of
an object - this always coincides with a LOT of disk activity) when it
tries to access a window handle. The really odd thing is, if the
excepton is trapped with a breakpoint, examining the values it's
trying to manipulate (and which presumably causes the exception)
reveals nothing wrong.
The code is:
Dim NewForm As New Form2
Dim MyWindowHandle as System.IntPtr
NewForm.Show()
Try
MyWindowHandle = NewForm.Handle ' this occassionally goes "bang"
Catch ex As Exception
MsgBox("Exception") ' by this point, NewForm.Handle has a valid
handle in it.
End Try
If I put a breakpoint on the MsgBox line, when the code generates an
exception, NewForm.Handle has a valid value; I can see absolutely no
reason why this code causes an exception. The NewForm.Show() works
without a problem. I wondered if my code was hitting some
resource-limit in XP (like the limit on the number of window handles
that existed in Windows 3.1) so I tried running my "create window"
code 1,000 times via a loop, and it worked fine. In general ("real")
use, the code doesn't get called more than about 30 times.
The code is far more likely to crash if it's run in Debug mode via VS
itself; if it's compiled in Release mode and run outside of VS, the
crashes are less frequent.
My theory is that if the program is left doing nothing for several
hours, XP or .NET swaps the code to disk and when the program's
brought back into focus, it's retrieved from disk but (I'm guessing
here) the code starts executing _before_ all the bits and pieces are
restored to RAM, hence the exception. By the time the breakpoint is
activated, everything's in place and that's why my VS 'watches' on the
variables show nothing amiss. If my theory is correct, is there some
way a program can test whether it (and its objects) are all present
and correct before accessing things like window handles? A couple of
other programs I've written also exhibit this problem. Since things
like MS Word and Excel don't go horribly wrong when brought into
focus, surely there's something Microsoft & others are doing that I'm
not (like not writing programs that use the .NET Framework, I suppose
;-) ). Changing the code to look like the following seemed to confirm
my theory:
Dim NewForm As New Form2
Dim MyWindowHandle as System.IntPtr
NewForm.Show()
Try
MyWindowHandle = NewForm.Handle ' this occassionally goes "bang"
Catch ex As Exception
MsgBox("Exception") ' This gets called fairly often
Thread.Sleep(10000) ' sleep 10 seconds
Try
MyWindowHandle = NewForm.Handle
Catch ex As Exception
MsgBox("Exception #2") 'This rarely gets called
End Try
End Try
The first "MyWindowHandle = NewForm.Handle" crashes more than the 2nd
one, yet they are both the same thing.
My PC is running Windows XP Home Edition SP1 with all the latest
fixes, I'm using Visual Studio 2003 Standard Edition, with the latest
patch (the 75MB one released last year to apply "documentation
updates" (75 megabytes of them??)). I'm running Microsoft .NET
Framework 1.1. My PC has 512MB RAM and an Intel P4 (non-HT) 3.06Ghz
CPU.
Thanks in advance for any help or suggestions,
Fiona.
