Error in Form Load

[ALX]

'Hard to tell whether to post this here or in GDI...
Including this line in the Load process for one of my forms...

AddHandler MyBase.Paint, AddressOf Graph1_Paint

causes an error for an inheriting form in the designer. >>>Object Reference not set to an instance of an object
The program runs OK, it's just that this error makes me uneasy. I have to cut this line from the base form in order to display or work on the inheriting form. I've read Microsoft's discussion about this but they don't offer a fix. I can't think of anywhere else to put this line other that the form Load procedure...
Any ideas ???

 

[jmcilhinney]

Don't use AddHandler for events of the form. Get the IDE to create an event handler for you with the appropriate event in the Handles clause. In the code Window select the form's events from the drop down list at the top left and the event from the top right. Now put the desired code in the method that was generated.

 

[ALX]

I've moved the event handler into it's own sub...

Private Sub GraphBase_Paint(ByVal sender As Object, ByVal e As System.Windows.Forms.PaintEventArgs) Handles MyBase.Paint

... and the error persists. I have to delete the sub in the base form to display or modify the inheriting form in the designer. The only reference I can find to this issue is in the following link... And, unless I'm mostly brain dead... I don't see a fix here.

http://support.microsoft.com/kb/893709

 

[ALX]

OK...
A little more research has narrowed down the culprit. It appears that when
displaying an INHERITING form, the designer actually calls the form Load & Paint event handlers in the BASE form in order to display the form in the designer. Any calls to other subs or functions within those event handlers are also called. Some (if not all) of the objects in those called subs / functions are not instaniated at the time the designer is running. I find it curious that that same subs are not called when viewing the BASE form in the designer.
Since these called functions are critical to my program while it is running, I guess the only way to solve this problem is to determine (in the code) whether the operating mode is DESIGN or RUN so I can bypass calls to other subs or functions when in design mode. So my question is:
Is there an environment-type property or something that I can query to find out if this program is in design mode or running mode ?

 

[JohnH]

I didn't get any error with this AddHandler in VB2005, but loads of errors I've never seen before when inheriting different forms in VB2003, even without the AddHandler, so perhaps you could try to do the same with VB2005 Express to compare if it could be a Visual Studio issue? There were some of those in VB2003. I also see that with VB2005 the default form event Handles point to 'Me', not 'MyBase' like in VB2003. Using 'Me' with Handles is not legal in VB2003, but works with AddHandler, maybe you could try adding handler to Me.Paint event instead. MS definitely changed something with the object model underhood from .Net1 to .Net2. Regardless, .Net2 and VB2005 is something you should really try out.

 

[jmcilhinney]

All controls, including forms, have a DesignMode property. It returns True if the current instance is in design mode. Note that it is a Protected member so it is only available from withing the the control. That means that within a form's code you can refer to 'Me.DesignMode', but you cannot refer to something like 'Me.TextBox1.DesignMode'. Note also that if you create a custom control and refer to its DesignMode property in its code, when you add an instance of that control to a form its DesignMode property will return False, because it is the form that is in design mode and not the control. That's not an issue for you in this case though.

 

[ALX]

Thanks for your input. 'Guess it's time to step up to VB2005

 

[ALX]

The DesignMode property solved my problem.
...Thanks jm...
I also downloaded VB2005 Express and discovered a world of sloppy programming in my VB2003 code. It immediately exceeded the alotted 103 warning / errors when I loaded my VB2003 program. VB2005 has also solved some problems that I couldn't figue out how to deal with. Such as trying to close a form by clicking the "x" in the title bar while in a recursive loop. In 2003, I would have to break the loop before the form would close. 2005 breaks the loop & closes the form, so now I don't have to deal with that. I'm hoping this Express edition will do everything I need to do so I don't have to spring the $$$ to buy the professional edition. Any way, thanks for the push JohnH.