|
Also in that order of libs myfunction() from 2) is called.
#pragma comment(lib, "wrapper2")
#pragma comment(lib, "wrapper1")
It seems once the myfunction code is found it is no longer added again.
Чесноков
|
|
|
|
|
Chesnokov Yuriy wrote:
There should be some linker switches I presume?
i don't think so, but you can check the linker documentation.
http://msdn.microsoft.com/en-us/library/aa270751%28VS.60%29.aspx[^]
i know you can force the linker to pick the first match that it finds, and to ignore subsequent matches. but i don't think there's a way to tell the linker to pick specific symbols from specific libs.
(also, duplicate postings here are frowned upon.)
modified on Monday, January 11, 2010 10:43 AM
|
|
|
|
|
I found /FORCE:MULTIPLE switch to include in the exe both myfunction() from 1) and 2)
But I do not know how to be able to call them both from exe. Only myfunction() from 1) or 2) is called depending on the order of 3) and 4) libs
(that is the duplicate topic but contents are a bit different)
Чесноков
|
|
|
|
|
Chesnokov Yuriy wrote: But I do not know how to be able to call them both from exe.
i don't think you can.
|
|
|
|
|
If you can use namespaces, then you can put the functions in the .LIB files into different namespaces.
This way you can use differentiate between the functions using namespaces.
|
|
|
|
|
I have been meeting the following in some c/c++ codes but I don't understand the theory behind it:
#ifdef __cplusplus
extern "C" {
#endif
I want to understand how it works. I know about the preprocessing but I don't know what that extern "C" in the code does. Someone teach me please!
|
|
|
|
|
The C++ compiler does something called name mangling which facilitates function overloading.
The extern "C" syntax tell the C++ compiler not to perform function overloading.
The code snippet that you posted first checks if the code being compiled is using a C++ compiler and if so starts a block in which name mangling will not be done.
|
|
|
|
|
That typically encloses DLL 's exported functions.
You should know, C Language and C++ one use different approach to function's name mangling (i.e. altering the name of the funtion in object -or library- files), more specifically, C++ includes in the mangled (or decorated) name info about the function argument types (this allows, function overloads, a C++ feature, not available in C language).
The mechanism allows the same header to be used by both the C and C++ compiler ( __cpluspls macro is defined only by the C++ one) and works this way:
The C compiler, ignores the extern "C" (__cplusplus is not defined) directive both when building the DLL and when including the DLL header inside an application.
The C++ compiler, according with the extern "C" (__cplusplus is defined) directive:
- Produces a standard
C DLL (i.e. the function use the C language mangling scheme) when building th DLL . - consider the library as a
C DLL when the header is included in a application (you know C++ compiler is able to link with C libraries).
Hope it helps.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
I created a modless dialog box using Createdialog Function.but it is returning null value.what might be the reason.Please let me know
kir_MFC
|
|
|
|
|
Check the error value using GetLastError .
Also, it would help if you post the line of code that fails.
|
|
|
|
|
CreateDialog((HINSTANCE)hinst, _S("ABORT"), hDlg, (DLGPROC)lpAbortDlg)
kir_MFC
|
|
|
|
|
From the error code and code that you posted, it looks like ABORT is not a dialog template defined in your resource.
|
|
|
|
|
I see 3 things that I would question...
1/ Why the cast to HINSTANCE? If hinst is not already good enough, what it is?
2/ Same question with lpAbortDlg. If it's not the right type already, maybe there's a problem there.
3/ _S("ABORT"). I know _T, but not _S. Maybe ABORT is a constant, and what you really need is:
MAKEINTRESOURCE(ABORT) ?
Another thing that has caused my dialogs to fail in the past is when they contain a control that cannot be created - ie, a custom window class that you have not registered. To check this, go to resource editor, and check the "do not fail" checkbox.
Good luck,
Iain.
I have now moved to Sweden for love (awwww).
|
|
|
|
|
GetLastError returning 1814
kir_MFC
|
|
|
|
|
kir_MFC wrote: GetLastError returning 1814
The specified resource name cannot be found in the image file.
Not too difficult really ...
|
|
|
|
|
using errlook tool which will give you information about the error code!
Beyond myself!
|
|
|
|
|
I want to use the FlexGrid control in a VC6++ project. When the project was created several weeks ago I unchecked ActiveX support because I didn't think I was going to need that. Now it turns out it has been requested.
I added the ActiveX FlexGrid control using the normal Project -> Add to Project -> Components and Controls. The code compiles with no errors and runs as long as I don't actually add the FlexGrid control to the Dialog form.
When I drop a FlexGrid control onto the Dialog form it compiles when no error. However, when I click on Run, nothing happens. My dialog form doesn't start up. If I delete the FlexGrid control from the Dialog form and recompile the application starts up and my dialog form is displayed.
I think this is being caused by the fact that I unchecked the ActiveX support when I started project. How can I now add ActiveX support to the project?
|
|
|
|
|
Call the function AfxEnableControlContainer in the InitInstance method of your CWinApp derived class.
|
|
|
|
|
I added the AfxEnableControlContainer function. But my dialog still doesn't come up. Also, the function call is looking for an argument. What would that argument be?
Thank.
|
|
|
|
|
Never mind. I found that I had to place the function call ahead of initializing my application instance. By doing that my dialog form now comes up. Thanks for the help.
|
|
|
|
|
Hi,
I have been programming for 10 years using Borland Builder C++, but now I want to migrate to VS 2005 (or maybe later 2009). I am strugelling with UI and MFC stuff. Could you please recommend a good book to learn (for C++ programmers)?
Most of my applications are stand alone exe with graphic editors (2D at the moment).
Thank you for your help,
Denny
|
|
|
|
|
|
Rewriting your application from C++ Builder to MFC will be a pain for you, since the elegance of C++ Builder GUI designer is no where to be found in MFC. MFC feels like coding with one arm twisted behind your back.
I would recommend you take the leap to .NET and Winforms, you can still integrate your existing C++ code with the .NET code.
If you really don't want to use .NET, then consider looking at the GUI library Qt.
|
|
|
|
|
Snakefoot wrote: the elegance of C++ Builder GUI designer is no where to be found in MFC. MFC feels like coding with one arm twisted behind your back.
Yes, the elegance of Builder. Build apps that are several times the size of a similar MFC app. Use a class library design that inevitably frustrates any attempt to do anything unique; key methods not declared virtual, etc. The elegance of Builder - build your own BloatWare.
MFC seems to be getting a bad rep in this thread. Let me see if I can set the record straight. MFC offers a highly developed class library that is properly designed; it can be customized in ways Builder can't even dream of. You build native C++ apps - no .NET runtime, no .NET dependencies, etc. The idea that .NET replaces native C++ as a platform for high-performance apps is delusional.
L u n a t i c F r i n g e
|
|
|
|
|
Very seldom you need a high-performance CButton og CEdit. Use the right tool for the job, and C++/MFC is not the best tool for building GUI applications.
If there are parts of the application that are performance critical, then one can implement these parts in unmanaged C++, and interop with them from .NET.
Btw. MFC has also become quite bloated after including the BCG library, so unless you want to go WTL then it is difficult to deploy a standard GUI application without dependencies.
|
|
|
|