Referencing the control of a calling DLL (or EXE) from the called DLL

[Terry]

I have figured out how to reference a "child" DLL from a "parent" DLL (or Exe), but I haven't figured out to reference in the reverse direction, for instance to reference a parent DLL/EXE control from a child DLL. Not sure if I have the exact terminology right here but hopefully you get the idea. The exact scenario is that the parent is an EXE which hosts a graph control and I want the child to be able to send the data back up to the parent (EXE). Doing this within a common project was not a problem, but now I have broken out my project into seperate assemblies I am still learning how to re-wire everything.

Can anyone suggest what I need to be doing to re-wire references in the reverse direction ("upwards")?

Thanks and sorry for any bad vocabulary.

 

[jmcilhinney]

I have figured out how to reference a "child" DLL from a "parent" DLL (or Exe), but I haven't figured out to reference in the reverse direction, for instance to reference a parent DLL/EXE control from a child DLL. Not sure if I have the exact terminology right here but hopefully you get the idea. The exact scenario is that the parent is an EXE which hosts a graph control and I want the child to be able to send the data back up to the parent (EXE). Doing this within a common project was not a problem, but now I have broken out my project into seperate assemblies I am still learning how to re-wire everything.

Can anyone suggest what I need to be doing to re-wire references in the reverse direction ("upwards")?

Thanks and sorry for any bad vocabulary.

The callee doesn't even know the caller exists, so it can't reference any control in the caller. Think about how what you want is done in existing libraries. How does a form get text from a TextBox when the user types into it? The TextBox raises its TextChanged event, the form handles the event and gets the data from the control's Text property. That's how you need to do it too. When the control wants to notify the outside world that something has happened, it raises the event. It's up to anyone who needs to be notified to be listening by handling that event. Data can be passed out via the event's own arguments or the data can be exposed via properties of the object raising the event. It's up to you to decide which is more appropriate.

To learn a bit more of the specifics, I would suggest that you follow the Blog link in my signature below and check out my posts on Data Among Multiple Forms and also Custom Events. Your situation is not multiple forms but it's similar in that you have a caller/callee relationship. Make sure that you read all three parts of the Multiple Forms post because it's the third one that you should actually follow.

 

[Terry]

Implementing the event raising and data passing between an EXE and a DLL

Many thanks for all that. I just spent an hour or so learning about Event Handlers and managing data between two forms. Congratulations on a very well written set of tutorials! Now I have to figure out what to do in my specific case. I am editting this post as I better discover what it is that I need to do.

In your tutorials you explain very well how to handle events that are raised (in one tutorial) and how to transfer data from one form to another, that are in the same EXE (the transfer of data in my case is between a DLL and an EXE. I would think the mechanism would be different??). Just to outline what I am trying to do once more: I have a chart in my main EXE which I need to be updated in real-time based on information generated in real-time by a procedure in a DLL. However, at the current time it is still not clear how:

a. The event should be triggered in the first place, to alert the EXE that an event has occurred. Perhaps I need to set up a continuous loop in the EXE to periodically "poll" the variable which is passed to the EXE. However, this would need to be tuned so as to not "over-poll" and needlessly take up CPU time. In this case, the concept of Event raising would be irrelevant.
b. The EXE then "reads" the values from the DLL, by way of the Public variables (or passing through the DLL call if we want to keep them seperate) to update the chart.
[SUB]
Thanks for your help and any additional comments.[/SUB]

 

[Terry]

Many thanks for all that. I just spent an hour or so learning about Event Handlers and managing data between two forms. Congratulations on a very well written set of tutorials! Now I have to figure out what to do in my specific case. I am editting this post as I better discover what it is that I need to do.

In your tutorials you explain very well how to handle events that are raised (in one tutorial) and how to transfer data from one form to another, that are in the same EXE (the transfer of data in my case is between a DLL and an EXE. I would think the mechanism would be different??). Just to outline what I am trying to do once more: I have a chart in my main EXE which I need to be updated in real-time based on information generated in real-time by a procedure in a DLL. However, at the current time it is still not clear how:

a. The event should be triggered in the first place, to alert the EXE that an event has occurred. Perhaps I need to set up a continuous loop in the EXE to periodically "poll" the variable which is passed to the EXE. However, this would need to be tuned so as to not "over-poll" and needlessly take up CPU time. In this case, the concept of Event raising would be irrelevant.
b. The EXE then "reads" the values from the DLL, by way of the Public variables (or passing through the DLL call if we want to keep them seperate) to update the chart.
[SUB]
Thanks for your help and any additional comments.[/SUB]

Dissappointed still no response on this. All I am trying to do is get a chart in a form to update dynamically. I presume someone somewhere must have done this. The only difference is that that the form will be in a different assembly than the procedure that called the form and is supplying data to the form.