|
Ok. In VC++.Net 05, I've compiled a dll containing a namespace from one project in the solution. I'm now trying to use that namespace in another project but it is throwing up linking errors for the object it's compiled for the 2nd project. I have added the dll to the References in the Project Properties but nothing. If I say
> using namespace DllData
the compiler says that DllClass (in the dll) is not a member of DllNamespace. This makes sense as Intellisense is not picking up DllNamespace in the first place. I've tried including the headers for the dll source from the 1st project (which seems a bit counterproductive to me), which helps compiling the object code but then crashes the linker when it can't find the object code for the dll!
I know I'm doing something stupid or not doing something obvious. Please help!
|
|
|
|
|
Klempie wrote: I've tried including the headers for the dll source from the 1st project (which seems a bit counterproductive to me),
I don't know if I understood you weel, but you always have to include header files in which your classes are declared. Without that, you will not be able to use the class.
Klempie wrote: then crashes the linker when it can't find the object code for the dll
Crash ?? You mean really crash or you get linker errors ? Did you link the project to the library associated with your dll ? If you are linking implicitely to the dll (so, not using LoadLibrary and GetProcAddress), you need to link to the library containing the information about your dll.
|
|
|
|
|
Thanks.
On the header note, I mean for example that there is no include statement for framework dll's if they are referenced in the project properties. For example, there is no include statement for System::Data. It's just there if System.Data is in the references. Surely the same should apply to user-compiled dlls?
What do you mean by "link[ing] the project to the library associated with you dll". Perhaps this is the problem. How would I do this in VS?
|
|
|
|
|
Klempie wrote: System::Data
Errr... That looks like managed C++  . I am right ? If yes, you are in the wrong forum.
Klempie wrote: What do you mean by "link[ing] the project to the library associated with you dll". Perhaps this is the problem. How would I do this in VS?
If it is in C++, when you create a dll, there is always a lib file that is created with it. In your project that uses the dll, you need to link to this library (it contains the link symbols necessary for your linker to 'load' the dll). But in managed, I don't know if it is working the same way.
|
|
|
|
|
You are right. I am doing it in .Net. Wouldn't have thought referencing would change between them though. I will scoot over the other forum. Thanks for your help.
|
|
|
|
|
I have just ran over this Problem. I tried to pass a vector type as parameter in an RPC-Interface. But this does not seem to be possible. The reason i found was, that these classes have an internal memory managment that makes them impossible to marshal, since the use stuff like the "new"-operator to allocate memory, wich bypasses the client/server-provided memory allocation methods. Since i wanted to write a wrapper class for my RPC-Calls anyway, its not that big a problem, but i just wanted to ask if someone knows a more elegant solution.
MfG Mr.Brainley
|
|
|
|
|
another question:
when I create a window, I use function CALLBACK WndProc(), if another dialog box will be triggered by clicking a certain button in this window, I may use another function CALLBACK DlgProc(). if there is other more, I may use another CALLBACK DlgProc()....
could I integrate all those DlgProc() or ToolDlgProc() or other functions in WndProc()? then it may looks more simple.
I mean, all those functions looked the same:
like
LRESULT CALLBACK WndProc(....)
{
switch(msg)
{
case WM_COMMAND:....
case .....
}
}
BOOL CALLBACK DlgProc(....)
{
switch(Message)
{
case WM_INITDIALOG:
case ...
}
}
|
|
|
|
|
Typically, CALLBACK and WINAPI will determine the calling convention (__stdcall, __thiscall, __cdecl etc).
The functions do look similar, and they are performing similar tasks. A WndProc (window procedure) is designed to process specific messages passed to the window. If there are messages it does not wish to handle, then it can/should pass them on to the system default handler.
Similarly, a DlgProc will process messages passed to the dialog box. Again, if there are messages it does not wish to handle, it can/should pass them on to the default dialog box message handler.
That's one of the differences between them, and is why you can't really combine them into a single function.
In any event, having separate functions allows you to put behaviour specific to one window class into that procedure.
Steve S
Developer for hire
|
|
|
|
|
bloodwinner wrote: I mean, all those functions looked the same:
The return value of WndProc() is the result of the message processing and depends on the message sent. The return value of DlgProc() indicates whether the message was handled or not.
"Talent without discipline is like an octopus on roller skates. There's plenty of movement, but you never know if it's going to be forward, backwards, or sideways." - H. Jackson Brown, Jr.
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
Hi,
I have created an application using mfc and I got the exe in debug folder.
I took the exe file and placed in another system in which there is no visual studio software.when I tried to run the exe file I got the error saying that there is no MFC42D.DLL , c:\WINNT\system32;..........
How can I rectify this problem and run the exe file.
Can u Plz help me.
Thanks in advance.
|
|
|
|
|
First, you have to tell us which IDE you used to compile (VC6, VC2005, ...). Things are different dependending on the IDE you used.
To find which dll needs to be distributed with your app, open the dependency walker (the program is normally supplied with the IDE but you can find it easily on the web also). It will show you all the dll that your app requires.
Also, do not distribute debug version of your program (and dll). This is not legal (particularly for distributing the debug version of the microsoft dll's).
|
|
|
|
|
Thank you.
I have used visual studio 6.0 IDE
|
|
|
|
|
In additional I remember that we have an example in MSDN that it shows all files that your program use of their.
|
|
|
|
|
tejaswini.g wrote: when I tried to run the exe file I got the error saying that there is no MFC42D.DLL , c:\WINNT\system32;..........
As it says, you need to ship all required dlls on target machine. For detecting required dlls, you can use MS visual studio tool depends.
|
|
|
|
|
Thank you.
Can u plz say is there any method to create an installation file with all the required files to run an application successfully.
|
|
|
|
|
you need to create set up. One of method is using InstallShield.
If you are using VC 7.0 +.Then you can use wizardv to create set up.
|
|
|
|
|
Thnak you prasad.
I am using vc++ 6.0 . Can u plz say how to create setup .
Thanks in advance.
|
|
|
|
|
|
Thank you prasad, it's very much useful for me.
|
|
|
|
|
tejaswini.g wrote: I took the exe file and placed in another system in which there is no visual studio software.when I tried to run the exe file I got the error saying that there is no MFC42D.DLL , c:\WINNT\system32;..........
This means your exe is dependent on these modules. You exe will need these dlls to run. So you will have to ship the corresponding dlls with your exe.
You can use dependency walker to find out what all dlls your exe is dependent on.
|
|
|
|
|
Thank you.
Sorry ,I don't know how to use dependency walker.
Can u say how to use dependency walker.
|
|
|
|
|
tejaswini.g wrote: Sorry ,I don't know how to use dependency walker.
Can u say how to use dependency walker.
Goto Start->Run
Type "depends" without quotes. This will open dependency walker. Now open your exe and see the listing of dlls on which your exe is dependent.
Or
Right click on your exe and select "View dependencies". You will see this if you have dependency walker installed.
|
|
|
|
|
Thanks alot.
I got it.
Thanks all of you once again.
|
|
|
|
|
|
the other guys already answered. but i see one important thing though.
don't distribute a program compiled in debug mode ! compile in release mode to deliver it...
then, for each DLL missing, find them on your computer and provide them with your exe.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
