SIPChanged fired in a wrong place

[IoSonoPiero]

Hello,
I've noticed that SIPChanged event associated to a form in a module is fired from another module in another form!

In detail:

I have the Main module that has three forms
I have an Editor Module that has one form

In the editor module I've associated an Hardware Object to the form.

If In one of three forms of the main module I open/close the SIP, I've seen that the SIPChange event from the Editor module is fired and it generates NullReferenceException!

Is this normal???

 

[IoSonoPiero]

I'm managing this issue with exceptions.
But I'm the only one that have this issue?

 

[agraham]

When an any event occurs all event Subs associated with that event run regardless of the module they are defined in.

 

[IoSonoPiero]

Yes, but...
normally in a form if a click on a button, this will fire an event, but only focused on the button I press.

Why here if I open the SIP in a form, the events that is contained in another form with another object associated is fired?

 

[klaus]

The harware object is independant of a module and a form.

When you open the SIP it fires the event, elsewhere the harware_SIPChanged routine is located.

You could declare the hardware object and the harware_SIPChanged routine in the main module.
Then you could add the SytemState library,
add a SystemState object
declare it with
SysState.New1("ActiveApplication")
and with
SysState.CurrentValue
you can find the active form.

Attached a small test program.

Best regards.

 

[IoSonoPiero]

Very good, Klaus, thanks to you all other people on the forum!

 

[agraham]

Why here if I open the SIP in a form, the events that is contained in another form with another object associated is fired?

Firstly I think you are confusing Form with Module, Forms have nothing to do with this. Event Subs belong to modules and are associated with Controls or Objects. Controls and library Objects belong to modules but are visible globally.

Changing the state of the SIP, wherever it is done, always causes the SIPChanged event which always runs any event Sub associated with it regardless of which module it is defined in.

You normally predefine Event Subs in the module that owns the Control or Object by "Sub Name_Event" and Basic4ppc automatically associates that Sub with the event. However instead, using AddEvent, you can associate any Sub, whatever its name, to an event and the Sub doesn't then have to be in the same module that owns the Control or Object.

 

[IoSonoPiero]

Firstly I think you are confusing Form with Module, Forms have nothing to do with this.

Well, I've programmed something with Visual Basic and Visual Basic 2005, so, to say that I'm confusing Form with Module, it's too much for me, eheh !

Event Subs belong to modules and are associated with Controls or Objects. Controls and library Objects belong to modules but are visible globally.

Changing the state of the SIP, wherever it is done, always causes the SIPChanged event which always runs any event Sub associated with it regardless of which module it is defined in.

I just thinked that the SIP_Changed event belongs only to the module where I created the object.

You normally predefine Event Subs in the module that owns the Control or Object by "Sub Name_Event" and Basic4ppc automatically associates that Sub with the event. However instead, using AddEvent, you can associate any Sub, whatever its name, to an event and the Sub doesn't then have to be in the same module that owns the Control or Object.

Ok, thanks agraham, repetita iuvant!