|
You can't use an OCX without registering it.
|
|
|
|
|
I'm learning how to build DLLs, and I've had some observations, and I was wondering if someone could provide me some insight. In Visual Studio 2005:
1) Created a new project
2) Using the project wizard created a MFC regular DLL using shared MFC DLL. (no other options selected)
3) Added a method to the default class generated by the wizard called "Execute"
void Execute();
4) Defined the method
void CTestApp::Execute()
{
return;
}
Added the method for export in the module definition file (.def)
LIBRARY "Test"
EXPORTS
Execute
When I compile I get a link warnings/error:
1>Test.def : warning LNK4022: cannot find unique match for symbol 'Execute'
1>Test.def : warning LNK4002: "public: void __thiscall CTestApp::Execute(void)" (?Execute@CTestApp@@QAEXXZ) defined in .\debug\Test.obj
1>Test.def : warning LNK4002: "public: void __thiscall CDaoDatabase::Execute(unsigned short const *,int)" (?Execute@CDaoDatabase@@QAEXPBGH@Z) defined in C:\Program Files\Microsoft Visual Studio 8\VC\atlmfc\lib\mfc80ud.lib
1>Test.def : warning LNK4002: "public: void __thiscall CDaoDatabase::Execute(wchar_t const *,int)" (?Execute@CDaoDatabase@@QAEXPB_WH@Z) defined in C:\Program Files\Microsoft Visual Studio 8\VC\atlmfc\lib\mfc80ud.lib
1>Test.def : warning LNK4002: "public: virtual void __thiscall CDaoQueryDef::Execute(int)" (?Execute@CDaoQueryDef@@UAEXH@Z) defined in C:\Program Files\Microsoft Visual Studio 8\VC\atlmfc\lib\mfc80ud.lib
1>Test.def : error LNK2001: unresolved external symbol Execute
1>C:\Documents and Settings\fi507c\My Documents\Visual Studio 2005\Projects\Test\Debug\Test.lib : fatal error LNK1120: 1 unresolved externals
So I've come across two solutions
Solution 1: Instead of using a .def file, use __declspec(dllexport) to export.
This solution makes sense, since it automatically creates the .def file for me. But I'm not sure what the issue with the .def file was. Was it due to name decoration?
Solution 2: Instead of calling my method Execute, call it something different, like Axecute.
This is somewhat odd to me, just by renaming the method to something else, the .def file works to export the function. Does it have to do with the some of the linker warning/error information? Wouldn't name decoration still cause an issue?
|
|
|
|
|
You'd need to fully qualify the name in the def file (like "CTestApp::Execute")
because no Execute function exists in your project.
That will get rid of all the warnings but then the name mangling will still prevent the link.
Using __declspec(dllexport) is recommended over using the EXPORTS section of the def file.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://codeproject.freetls.fastly.net/script/Forums/Images/coffee.gif)
|
|
|
|
|
HA did I get hooked! I'm flopping around all over this boat[^]
led mike
|
|
|
|
|
Nobody can give you wiser advice than yourself. - Cicero
.·´¯`·->Rajesh<-·´¯`·.
Codeproject.com: Visual C++ MVP
|
|
|
|
|
*snicker* 
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Hi,
I am working on a small game engine which is designed to work on multiple platforms when recompiled. At the moment I am targetting win32 and linux. Using Win32 with Visual C++ it is easily possible to create DLLs which export classes, objects, and functions. However I have some problems for which I would be really greatful if you guys advise me with.
The first problem is compatability with compilers:
I am told that DLL's compiled with Microsoft Visual C++ (without MFC) will not be compatible with other compilers such as Borland because of a technique called name decoration (or name mangling).
The second problem is compatability with platforms:
This is the first time I have attempted dynamic linking with linux/unix. I am fairly confident with dynamically accessing exported functions...but as far as classes and objects are conserned I think I am going to have a lot of problems with dynamic linking.
I have been searching extensively on the net, and I am gradually drowning in confusion  . The only solutions I can find are pretty extreme:
- Convert all of my C++ libraries to ANSI C libraries. (defies some of my design objectives and generally not a good solution, but on the bright side some things would execute more efficiently)
- Find another low-level OOP language which does meet my needs. (makes my target audience smaller)
- Extend my scripting engine into a full-blown language by translating into assembly code and then assembling using a third-party assembler such as FASC. (a very big and complex task which i would rather avoid, but would stoop to if absolutely 100% necessary).
The ideal solution for me would be a standard name mangling convention (without the use of an interface which would seriously damage performance) which works across a wide range of platforms including win32 and linux/unix.
I look forward to hearing your ideas. 
Lea Hayes
|
|
|
|
|
I've run into everything you're experiencing. Fun stuff....not!
lhayes00 wrote: I am told that DLL's compiled with Microsoft Visual C++ (without MFC) will not be compatible with other compilers such as Borland because of a technique called name decoration (or name mangling).
Absolutely correct. To use you C++ DLL, you need to match compiler vendor (and probably version as well), in addition to having the same linkage model (i.e. whether or not you're linking the CRT statically or dynamically). Alternately you can use COM and completely get around this.
You will not be able to use a binary object (i.e. a dll/shared obj, etc) compiled on one platform on another. In other words, you can't use a DLL compiled on Windows and hope to link to it dynamically on linux. For a whole bunch of reasons.
Like I said one option is COM. Alternately the Mozilla project produces XPCOM which works on linux/Win32/OSX, etc. However you still can't share the binaries between platforms (if that's something you're hoping to do).
¡El diablo está en mis pantalones! ¡Mire, mire!
Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)!
SELECT * FROM User WHERE Clue > 0
0 rows returned
Save an Orange - Use the VCF!
VCF Blog
|
|
|
|
|
I have just looked up XPCOM on the Mozilla website and it looks quite promising! My next task is definately to read through the PDF book provided on the XPCOM website.
Thank you very much! 
Lea Hayes
|
|
|
|
|
As ur requirement is simple and just require to export a Class from DLL, i think the complete COM framework is not needed, use the basic stuff, export single c funtion to create an instance of class,
CYourDLLClass *pObjOfDllClass = NULL;
CreateDLLClassInstance((void **)&pObjOfDllClass); //exported C function.
then use pObjOfDllClass as normal Class object.
|
|
|
|
|
Hi,
If an object of a class is created from an exported function, surely all functionality would need to be exported using C style functions (where the object pointer is treated as a handle). If exported classes are used, DLL's compiled with a different brand/version of C++ compiler will be unable to import class members due to the problems with name mangling.
Appologies if I have missunderstood what you have said.
Thanks for your reply,
Lea Hayes
|
|
|
|
|
i meant u don't need to export class, only one C function to create an instance of the class object, COM does this. COM uses DLLGetClassObject to create an instance of the factory method interfaces.
say,
BOOL CreateDLLClassInstance(void **ppClassObj); // exported C function to create an instance note type is void ** and no class declaration is visibly exported.
lhayes00 wrote: If an object of a class is created from an exported function, surely all functionality would need to be exported using C style functions
this exported function is not part of the class, the function is outside the namespace of the class.
lhayes00 wrote: where the object pointer is treated as a handle
just typecast the HANDLE to your object class type.
|
|
|
|
|
Ahh rite now I see what you mean!
Thank you for clarifying, I am sure that I can put this to use
Lea Hayes
|
|
|
|
|
Depending on the design of your library, a good solution would be to make C entry points into it, using a technigue called "flattening[^]", thus exposing the C interface while keeping the C++ internal implementation.
|
|
|
|
|
Cheers! this is an interesting solution, I have read through the page you linked me to and I think this is something which I can apply in areas of my application.
Thanks for your help!
Lea Hayes
|
|
|
|
|
hi, i have created three edit controls with that when i press tab for the first one the focus should go to the second and if the tab is pressed in the second edit control it should go to the thrid...
i can get the window on which the tab is pressed but i want to find the next control so that i can send the focus to that... i dont want to use more if's to get this... is there a function like getnextwindow or child window... ?
Today's Beautiful Moments are
Tomorrow's Beautiful Memories
|
|
|
|
|
What are you talking about? Can't you simply set the tab order at design time?
Nobody can give you wiser advice than yourself. - Cicero
.·´¯`·->Rajesh<-·´¯`·.
Codeproject.com: Visual C++ MVP
|
|
|
|
|
i am using Dev-C++ IDE... and using C style for the code... so is that what you need to know? anyway... as you have had your personal comment as no one can give a wiser advice than myself... let me try...
actually i wasn't in a mood to dig deeper... here i go... 
Today's Beautiful Moments are
Tomorrow's Beautiful Memories
|
|
|
|
|
Seriously though, I've never used Dev-C++ IDE. Here we assume the OP is using Visual Studio (for sure) and even MFC(sometimes), unless the OP specifies he's working on Win32.
Nobody can give you wiser advice than yourself. - Cicero
.·´¯`·->Rajesh<-·´¯`·.
Codeproject.com: Visual C++ MVP
|
|
|
|
|
thank you for your concern and for replying Mr. Rajesh R Subramanian, anyway i have to try that and will contact codeproject or you for further discussion if needed... do you have any idea about the dwContext parameter in the wininet ftp InternetConnect function or i will come up with the code of what has been done till now and by then it should be easy for discussion... thank you.
Today's Beautiful Moments are
Tomorrow's Beautiful Memories
|
|
|
|
|
It would be easier to just set the tab order when you build the window. For those designed with the IDE, press ctrl-d and set the order. For windows built by hand, the order you add the controls to the window is the tab order.
Judy
|
|
|
|
|
thank you for your consideration... i am using DEV C++ IDE... anyway let me try someother way...
i am using C style of coding which is not MFC or cpp. probably its just a silly question which shoudln't have been asked... fine...
Today's Beautiful Moments are
Tomorrow's Beautiful Memories
|
|
|
|
|
Jayapal Chandran wrote: probably its just a silly question which shoudln't have been asked.
No it's not. Given that you're not using a MS IDE, you can set tab order by the order in which you add controls to your window as you create the window. The order in which controls are added is the tab order. If you're building the window in your DEV C++ IDE, there's going to be some way to specify it - either through the IDE or just go in and manually edit the generated resource script file to order the controls.
Judy
|
|
|
|
|
hi, till now i have done everything only with the coding and i didnt use the ide features except adding the needed libraries like ws2.lib and wininet... thank you... and i will try your way...
Today's Beautiful Moments are
Tomorrow's Beautiful Memories
|
|
|
|
|
I just installed Dev C++, it seems it doesnot have resource editor, u might have coded rc files or used external editor or coded in C++ right to add ur ui controls?
I think in either way the WS_TABSTOP style is not set, if this style is set for the control, ur requirement is automatically handled.
modified on Saturday, February 16, 2008 4:47 AM
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
