Invoking event

[Bulldog]

Hi, I'm totally confused as to how to invoke an existing event. I have an event of the form;

private void DataReceived(object sender, DataReceivedEventArgs e)

where DataReceivedEventsArgs is a byte[]. I want to invoke that event from another sub, passing my data into it.

So what I'm trying to do is trigger that event using my available data, so something like this;

DataReceived(this, MyByteArray)

How can I do this?

[kfcSmitty]

You're thinking about it in the wrong way. While there are ways to invoke a binded event, what you should really be doing is calling another function within your DataReceived binding and then call that function from elsewhere.

For example

private void DataReceived(object sender, DataReceivedEventArgs e){
 
  byte[] someValue = whatever you want to make it equal;
 
  WhatIActuallyWantToDo(someValue);
}
 
private void WhatIActuallyWantToDo(byte[] value){
//do stuff!
}

[jmcilhinney]

As kfcSmitty says, you're looking at things totally incorrectly. What you have described is not invoking an event at all. You're simply talking about calling a method. An event handler and an event are two different things. Only the object of which the event is a member can raise an event, so only a SerialPort object can raise the DataReceived event of that SerialPort object. The DataReceived method that you're talking about is a method, not an event, and it's a member of the form, not the SerialPort. The form registers that method as a handler for that event by creating a delegate and passing it to the SerialPort object. When the SerialPort raises the event, it invokes the delegate and the method is executed.

As kfcSmitty suggests, what you are actually talking about is executing the same code on more than one event. You say:

I want to invoke that event from another sub

Apart from the fact that there's no such thing as a "sub" in C#, the method you want to invoke it from will have been executed in the first place as the result of some other event being raised, e.g. the Click event of a Button. Just as kfcSmitty says, if you want to execute the same code on multiple events then you put that code in a method of its own and then call that method from any and every place that you need that code executed. It's a simple principle that you should already be familiar with, i.e. write a method to do a job and then call that method whenever you need that job done.

[Bulldog]

Yes, I agree that a standalone method called by an event or from some other place is a solution. But let me explain a little more.

I'm introducing a test facility into a communications system. The DataReceived is coming from an instrument and what I'm doing is spoofing that data (disregarding what is actually being received and substituting it with test data, which is then sent onwards). This test data allows the system to be checked and tuned using known good data. That is easy enough to do with an 'if in test mode then send spoof data' switch inside the event.

The instrument sends data at specific times. So I'm still reliant on the instrument being connected and sending data to trigger the event. The instrument has an associated DLL (for which I have no source), which handles the comms. So what I'd ideally like to do is;

(a) Send test data on the same schedule as the instrument (done, no problem here)
(b) Trigger the event at will and send test data on an emulated schedule.

I placed my test data in a byte[] global, set a test flag in the event to use it, this gives me "mode (a)".

In order to do "mode (b)", is there a way I can manually raise the DataReceived event?

[jmcilhinney]

Yes, I agree that a standalone method called by an event or from some other place is a solution. But let me explain a little more.

I'm introducing a test facility into a communications system. The DataReceived is coming from an instrument and what I'm doing is spoofing that data (disregarding what is actually being received and substituting it with test data, which is then sent onwards). This test data allows the system to be checked and tuned using known good data. That is easy enough to do with an 'if in test mode then send spoof data' switch inside the event.

The instrument sends data at specific times. So I'm still reliant on the instrument being connected and sending data to trigger the event. The instrument has an associated DLL (for which I have no source), which handles the comms. So what I'd ideally like to do is;

(a) Send test data on the same schedule as the instrument (done, no problem here)
(b) Trigger the event at will and send test data on an emulated schedule.

I placed my test data in a byte[] global, set a test flag in the event to use it, this gives me "mode (a)".

In order to do "mode (b)", is there a way I can manually raise the DataReceived event?

You still obviously don't have a clear understanding of the difference between an event and an event handler if you're talking about doing anything "in" an event. There's no such thing as "in" an event. The event is raised, the handler(s) for that event is/are executed and you can then do something "in" that/those method(s).

There's no way to prompt a SerialPort object to raise its DataReceived event from the outside. I thought to perhaps inherit the SerialPort class and add a public method that would then call the protected OnDataReceived method... but there is no such method. That's how most events get raised but I guess not in this case. It might be possible via Reflection but I haven't looked into that and won't be.

Even if you do that though, what's the point? The event only notifies you that data has been received. It doesn't actually give you that data. The idea is that you then read the received data from the SerialPort itself inside the event handler. Even if you can get the SerialPort to raise the event, the SerialPort object still won't contain any data for you to read.

The logical solution here seems to me to be to write a method that receives a byte array and processes it. You can then call that method from your DataReceived event handler and pass it the byte array that you read from the SerialPort or you can call it from some other place, e.g. the Elapsed event handler of a Timer. Using a System.Timers.Timer allows you to call the method on a regular schedule, as it seems you would be doing via the SerialPort, and also to call it on a secondary thread, further emulating the behaviour of the DataReceived event.

[Bulldog]

The software communicates over a serial port, the instrument's comms are handled by a DLL (the source of which I do not have). The instrument is remote and in a chamber where humans cannot venture.

Spoofing data is easy and that works fine, I create test points within the 'receiver' code, to substitute test data. Using this I can test that the onward processing path is working correctly. The rest of the system will 'think' its getting measurement data.

The challenge is to test the system, not to implement a certain function.

Trying to emulate the instrument for test purposes is not easy and it seems I need the proprietary source code. Only with that can I truly emulate the comms unless I can reverse engineer it. If I create parallel code then all I am doing is testing that parallel code. I know it's a silly example but if I am testing the BFlat tone of a trumpet, I vibrate air into the mouthpiece and press valve one. I can of course create a button marked 'Test BFlat' that plays a wav file of BFlat through a loudspeaker, but the latter is a parallel path that spoofs the required result but does not test the trumpet at all. I don't know whether valve one even moves, or the pipework is completely blocked. My job is to emulate a trumpet player not simulate it making a certain noise.

My real problem is that in this case, I'm trying to retrospectively provide test facilities into a hardware/software system that is grossly deficient.

[Bulldog]

For posterity, I got the solution here and this does indeed use reflection as John suggests.

https://social.msdn.microsoft.com/Fo...forum=netfxbcl