non-MFC DLL with MFC app question.

Hi,

I have two applications and a DLL:

App A -> MFC aplication that load the DLL. I haven't the code of this app
App B -> non-MFC aplication that load the DLL also. I have the code of this app.
DLL -> is one programmed by me. It is a non-MFC DLL. It is a DLL which create a thread and send data to the application at periodic intervals. My problem is that the DLL runs fine with B, but not with A.

For testing purposes, I made a v2 of the DLL that does not create threads, and it works fine with app. A. The conclusion is that having threads in a non-MFC DLL is incompatible with a MFC application.

So the questions are:

- Are there any way to make my non-MFC-thread DLL compatible with a MFC application without the need to migrate the dll to mfc?

- If the only way to make the dll compatible with app A is a migration, has anybody any example of a MFC DLL whitch create a thread? I am a complete blind programmer in MFC.

thanks for yours replys.
FS

What method are you using to send the data to the app?

--
Mats

Quote:

---

Originally Posted by matsp

What method are you using to send the data to the app?

--
Mats

---

The DLL use two different ways of comunication.

1) Comunication with and external port contected machine. I use WriteFile and ReadFile (with WaitCommEvent) to write and read from the port. I have not problems here as comunication is Ok with A and B apps.

2) Comunication with the application. When then application correctly loads the DLL , the it invokes a "Register event function", in which the application let know the DLL what callback function to call when that event happend. Example:
- Load the DLL
- Call 'Register log function" with the address of the app function (f1) to call when from the DLL we want to register an event in the log of the app.
- From the DLL, when appropiate, we call f1 with data to let know the app we want to send string paramenter to log file.

I hope my explanation is clear....

Anyway, what I have discoved until now is that threads are non supported bethween mfc app and non-mfc dll.

thx
FS

I think MFC in general isn't very good for multithreading. I expect that you can use threads that do not use MFC itself, but if you use MFC in the function f1, then it should run in the same thread as the MFC main application.

Perhaps you can use a hybrid between the thread and no-thread variant. where your code creates a thread, but also allows the original thread to run the f1 function?

--
Mats

Quote:

---

Originally Posted by matsp

but if you use MFC in the function f1, then it should run in the same thread as the MFC main application.

---

Well, I think this is actually the problem. As I initialize a thread a DLL load, is that thread which call f1 (the function at mfc application). I am calling the f1 function from a thread which is different of the application thread.... so the win32 need something to make both compatible in the some application, but as dll thread is not mfc. it can't manage it. Maybe the problem is when calling mutex or semphores. .....

Problem is, I believe, that you create a Win32 thread and from there call back to the MFC app?
MFC requires you to use its own thread creating functions since it stores thread-specific data.
Otherwise, you must not use ANY MFC inside the app from a regular thread. That works, too.

MFC isn't the problem. "App A" is the problem. The implementers of App A need to know that the callback can occur on a separate thread that they didn't create. So it's hardly your fault if they crash during f1 invocation.

*Why* App A is crashing could be related to MFC, or any other number of reasons. So the question is: Is there a 3rd party that can fix App A? If not, then that means the existing DLL interface is "in stone" - which means you'll have to somehow invoke a f1 on the same thread that called the registration function. I have one idea for this, but it's certainly not ideal.

gg

>> I made a v2 of the DLL that does not create threads, and it works fine with app. A.
I [now] see you've already done a non-threaded version. How did you do it without changing the interface?

gg

Quote:

---

Originally Posted by Codeplug

>> I made a v2 of the DLL that does not create threads, and it works fine with app. A.
I [now] see you've already done a non-threaded version. How did you do it without changing the interface?

gg

---

That version was not completly compliant with the interface. I made only for testing. Basically when calling the registering function, aside from storing the function address, I made few comunications tests and they run ok.

That version was not valid for the real situation

Quote:

---

Originally Posted by Codeplug

MFC isn't the problem. "App A" is the problem. The implementers of App A need to know that the callback can occur on a separate thread that they didn't create. So it's hardly your fault if they crash during f1 invocation.

*Why* App A is crashing could be related to MFC, or any other number of reasons. So the question is: Is there a 3rd party that can fix App A? If not, then that means the existing DLL interface is "in stone" - which means you'll have to somehow invoke a f1 on the same thread that called the registration function. I have one idea for this, but it's certainly not ideal.

gg

---

There is not 3th party that can fix it. It is an application that was implemented in my work by a software developtment company that does not exist now..... and it was so many years ago that people does not know what happens with source-code. :(

My idea was to call SetTimer() with a function callback during the DLL registration function. Then your timer callback will be called within the context of the main application's message loop (assuming the message loop thread calls your registration function). Within the timer callback, you would then hand off all accumulated data to f1.

Of course, this all assumes that threading the cause of the crash to begin with :)

gg