Trigger dialog method from non-windows app
-
Windows 7, Visual Studio 2008, C++ I am writing a TCP/IP utility that can be run/used by a non-windowing application. An MFC dialog stands in for the main app during development. The utility runs as a separate thread and communicates with the main app via events and a shared memory structure. Keeping this short: Is there a mechanism that the TCP utility can use to trigger a method in the MFC? Details Presume the dialog has: OnBnClickedShowStatus(…) When the button is clicked this method reads some variables from the shared structure and displays them in the dialog. Can that button, or its essential code, be triggered by an event from the TCP utility? The alternative is to create a timer and have it run every 300 milliseconds or so. I am hoping for something that is as simple as the timer and causes minimal additional coding in the TCP utility.
Thank you for your time If you work with telemetry, please check this bulletin board: www.irigbb.com
-
Windows 7, Visual Studio 2008, C++ I am writing a TCP/IP utility that can be run/used by a non-windowing application. An MFC dialog stands in for the main app during development. The utility runs as a separate thread and communicates with the main app via events and a shared memory structure. Keeping this short: Is there a mechanism that the TCP utility can use to trigger a method in the MFC? Details Presume the dialog has: OnBnClickedShowStatus(…) When the button is clicked this method reads some variables from the shared structure and displays them in the dialog. Can that button, or its essential code, be triggered by an event from the TCP utility? The alternative is to create a timer and have it run every 300 milliseconds or so. I am hoping for something that is as simple as the timer and causes minimal additional coding in the TCP utility.
Thank you for your time If you work with telemetry, please check this bulletin board: www.irigbb.com
A better solution would be to implement the TCP utility as a library that can be called from any other application: windows, non-windows, MFC or not. It could incorporate a call back feature that would allow it to call into the controlling app whenever necessary.
-
A better solution would be to implement the TCP utility as a library that can be called from any other application: windows, non-windows, MFC or not. It could incorporate a call back feature that would allow it to call into the controlling app whenever necessary.
I don't have any idea of how to do that, but it sounds like a good concept. I did some searching and will look into that. Still, finding this particular concept of having the thread call into the controlling app may be a bit difficult to discover. Can you give me a few words or a link that discusses that in particular?
Thank you for your time If you work with telemetry, please check this bulletin board: www.irigbb.com
-
I don't have any idea of how to do that, but it sounds like a good concept. I did some searching and will look into that. Still, finding this particular concept of having the thread call into the controlling app may be a bit difficult to discover. Can you give me a few words or a link that discusses that in particular?
Thank you for your time If you work with telemetry, please check this bulletin board: www.irigbb.com
Export an API from the library that takes a function pointer as an argument. Then use this API from the main program to pass a function pointer into the library so it can call back to the main program.
The difficult we do right away... ...the impossible takes slightly longer.
-
Export an API from the library that takes a function pointer as an argument. Then use this API from the main program to pass a function pointer into the library so it can call back to the main program.
The difficult we do right away... ...the impossible takes slightly longer.
I am having a bit of trouble with that concept. I am currently writing and testing this utility, a TCP/IP class that is run under a thread separate from the main app. The main app instantiates a class call C_Log_Writer to write data to a log file. Main handed a pointer to C_Log_Writer to the thread and it tried to write some data to the log. That crashed the app repeatedly. The prompted the conclusion that since they are in separate threads each with its own execution pointer, that was not a good idea. Creating a new instance of C_Log_Writer for the thread resolved the problem. There are two log files, but that's okay. That makes me concerned that calling a function across a thread boundary might be a problem. That said: When you write: Export an API from the library, I take that to mean export a function from the TCP utility. Do I follow you correctly?
Thank you for your time If you work with telemetry, please check this bulletin board: www.irigbb.com
-
I am having a bit of trouble with that concept. I am currently writing and testing this utility, a TCP/IP class that is run under a thread separate from the main app. The main app instantiates a class call C_Log_Writer to write data to a log file. Main handed a pointer to C_Log_Writer to the thread and it tried to write some data to the log. That crashed the app repeatedly. The prompted the conclusion that since they are in separate threads each with its own execution pointer, that was not a good idea. Creating a new instance of C_Log_Writer for the thread resolved the problem. There are two log files, but that's okay. That makes me concerned that calling a function across a thread boundary might be a problem. That said: When you write: Export an API from the library, I take that to mean export a function from the TCP utility. Do I follow you correctly?
Thank you for your time If you work with telemetry, please check this bulletin board: www.irigbb.com
1. Yes, export a function from the utility 2. About the crashing when passing a pointer to your log class: Where did it crash? Can you pinpoint that? It might have something to do with the TCP utility using a different heap from the main exe.
The difficult we do right away... ...the impossible takes slightly longer.
