Thread: non-MFC DLL with MFC app question.

  1. #1
    Registered User
    Join Date
    Feb 2008
    Posts
    147

    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

  2. #2
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    What method are you using to send the data to the app?

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  3. #3
    Registered User
    Join Date
    Feb 2008
    Posts
    147
    Quote Originally Posted by matsp View Post
    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

  4. #4
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    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
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  5. #5
    Registered User
    Join Date
    Feb 2008
    Posts
    147
    Quote Originally Posted by matsp View Post
    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. .....

  6. #6
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    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.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  7. #7
    Registered User Codeplug's Avatar
    Join Date
    Mar 2003
    Posts
    4,981
    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

  8. #8
    Registered User Codeplug's Avatar
    Join Date
    Mar 2003
    Posts
    4,981
    >> 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

  9. #9
    Registered User
    Join Date
    Feb 2008
    Posts
    147
    Quote Originally Posted by Codeplug View Post
    >> 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

  10. #10
    Registered User
    Join Date
    Feb 2008
    Posts
    147
    Quote Originally Posted by Codeplug View Post
    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.

  11. #11
    Registered User Codeplug's Avatar
    Join Date
    Mar 2003
    Posts
    4,981
    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

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. MFC App Closing
    By UnclePunker in forum Windows Programming
    Replies: 2
    Last Post: 01-05-2006, 10:19 AM
  2. DLL version MFC app
    By Unregistered in forum Windows Programming
    Replies: 0
    Last Post: 07-30-2002, 07:22 PM
  3. WIndows programming?
    By hostensteffa in forum Windows Programming
    Replies: 7
    Last Post: 06-07-2002, 08:52 PM
  4. Release MFC Programs & Dynamic MFC DLL :: MFC
    By kuphryn in forum Windows Programming
    Replies: 2
    Last Post: 05-18-2002, 06:42 PM
  5. Dll question again. Reference to No-One
    By G'n'R in forum C Programming
    Replies: 0
    Last Post: 10-24-2001, 03:52 AM