How to prevent "fatal error C1189:" in a single -threaded app

Hello everybody. My problem is this:
I get the following common error:

fatal error C1189: #error : Please use the /MD switch for _AFXDLL builds

and I know that one common solution is to set 'Multithreaded DLL' in the 'Use run-time library' field.
But I should really try to set this field to Single-threaded, because multithreading conflicts with some specific API functions I'm using.
Does anybody know how I could do to solve my problem?
Annalisa

Well..not using MFC would be one option... ;)

The /MD switch just supports multithreading. If your program only uses one thread then it's single threaded. I know that someone will tell me that's not necessarily true (shadow GDI threads and other API code that may start a second thread but these areas will be thread safe anyway).

So I don't think it would be a problem.

Not usign MFC would be too hard at this point of development...
The problem is that this way I can't have some function working from the external APIs.
There's no way to set it single-threaded?Why does it force me to set it multi-threaded? I just can'y understand.. Is there some other setting that influences that?

It is due to the internals of the MFC...the support for multithreading is deeply implemented (e.g. CWinApp is derived from CWinThread etc.), thus, I would not see any (easy) way to get around it.

What API functions conflict with this setting?

The APIs that conflicts are developed by a private company who works for my company, for OCR textual recognition.
So I get that I only have not to use MFC.. :(
Thank you very much for your answer
Annalisa

Okay....how do they conflict? Compile error? Link error? What errors?

No errors. They just don't do what they should while executing the application.
But, if I try the same code in another project, setting 'Not using MFC' and single-threaded, they work perfectly.. These are the only things different.
That 's why I simply gathered there were something wrong in my project.. :)

Quote:

---

Originally Posted by annalisa1976

No errors. They just don't do what they should while executing the application.
But, if I try the same code in another project, setting 'Not using MFC' and single-threaded, they work perfectly.. These are the only things different.
That 's why I simply gathered there were something wrong in my project.. :)

---

Well...I have my doubts that this is related to the MFC itself...it would be the first time I hear about such things. Could you probably post your code? And state what is not working?

Thank you very much for your attention. Unfortunately I can't post any code on the Internet, cause my company wouldn' t release any permission of this kind. And, most of all, it would need many additional libraries and DLLs that it wouldn't even compile.
Now the settings of the two projects are the same, except for one thing:
1.the project that compiles and works is a console application;
2.the project that doesn't compile (after setting Single-threaded and MFC options) is a win32 application.
Would you be so kind to think of anything that could collide? I know it's difficult to say without any code, but unfortunately I have not the power to decide about it...
I'm wondering what I could modify in the project settings that could produce the compile error

#error Please use the /MD switch for _AFXDLL builds
when I set the Single-threaded application.

Thank you.
Annalisa

I think I found a solution to get around the problem.
Reading through the answers you formerly gave me, I get that the problem is concerned with having a win32 application that implements a CWinApp class that derives from CWinThread. As my app has to be a dialog based and single threaded application, I think I could do a dialog based and multithreaded application that launches another application. This last application wil be a console and single-threaded application and will do all the things that now my app does.
Thank you very much for your support..
Regards,
Annalisa

I still don't see the need for creating just another application which starts the other one etc. however, it is pretty hard to tell what goes wrong at run-time without seeing the code.

I would rather assume, that this is a threading problem (such as missing or wrong synchronization etc.) which cause the differences in the run-time behaviour...

Ok. I will consider this and try to find the solution searching this way.
Thank you again. This is really the most helpful forum I've find so far.
Regards,
Annalisa

Unfortunately this is a common problem with third party APIs.

The 'mutlthread DLL' and 'multithread' at least should be available. there's no good reason not to use them as the default. They don't introduce any meaningful overhead, even if you're writing a library or application that doesn't create mutlitple threads.

A vendor should also provide debug version of their libraries, so that developers aren't locked out of doing meaningful debugging work in their applications. When compiling for debug version to ship, you can simply turn off the debugging info for the code modules and still link the debug libraries.

I know of a couple of vendors that refuse to ship their libraries to developers with the debug libraries linked in, simply because they don't understand the difference and would rather shift the burden and headaches to their customers, rather than learn something simple and new to them.

Finally, the easy answer in making libraries as compatible as possible is to not use the DLL option. If the DLL option is not used, then they can be linked in either way with no hoops for the developer to jump through. This can increase the size of the library some, but it maximises compatibility.

AnnaLisa1976, it sounds like you found a solution to this problem. Unfortunately, incompatabilities between libraries can lead to some real ugly solutions.

Another possibility is to wrap some of your single threaded libraries into DLLs, so that they can be linked into a multithreaded application.

Quote:

---

Originally Posted by annalisa1976

Thank you again. This is really the most helpful forum I've find so far.

---

You are welcome....have fun with the forums...