|
Remove all include statements from the SerialClass.h header file and place them in the SerialClass.cpp file. When using pre-compiled headers in your project, replace the include statement for afxwin.h by stdafx.h which includes afxwin.h.
|
|
|
|
|
Hi Jochen,
Thanks for the reply. I can't seem to get it to work though. Sorry, I'm pretty lame at anything but basic coding.
The Arduino SerialClass comes as SerialClass.h and Serial.cpp You can see them here http://arduino.cc/playground/Interfacing/CPPWindows[^]
I have a seperate file Serial_Client.cpp that holds my main() and stdafx.h.
I moved the include statements to Serial.cpp but this no longer compiled (I've taken out the #include winsock2.h and afxwin.h, just as a test). So I created a SerialClass.cpp and put them in there, but I had the same problem.
Was I supposed to put the moved #includes in Serial.cpp file (the class source code) or somewhere else?
Thanks a lot.
|
|
|
|
|
Because you are using stdafx.h, I assume that you are using pre-compiled headers (which is the default for VS projects).
When using pre-compiled headers, every cpp file must include the stdafx.h file before any other header files. Doing so, the standard windows and MFC definitions are present when the compiler processes other header files and the code.
As a general rule, the project specific header files should only include other header files that are necessary to compile the header file (containing definitions that are used in the header file). When including stdafx.h as first file in every cpp file, the common windows header files are already included when processing the other header files.
But your original SerialClass.h file includes header files that are also included by stdafx.h.
Please include stdafx.h as first one in all cpp files, remove all include lines for afxwin.h and windows.h from all cpp and header files (except stdafx.h) and try to build the project. If there are still errors, post them here.
|
|
|
|
|
Thank you for that excellent explanation! I tried what you suggested and also moved all my #includes (from all the .cpp's and .h's) into stdafx.h. It compiled fine, even with winsock2.h included in stdafx.h.
I am having some problems now trying to use any of my existing sockets code but I think it's a linker error that should be resolvable (as Google seems to hint). I've been using a header defined class 'CIPMessage' (from Boby Thomas P's excellent article Chat Client Server[^]) to define an object that handles all the sockets communication. Creating this object gives the following errors:
Serial_Force_Client.obj : error LNK2028: unresolved token (0A0003A1) "public: __thiscall CIPMessage::CIPMessage(void)" (??0CIPMessage@@$$FQAE@XZ) referenced in function "void __clrcall `dynamic initializer for 'MyMessObj''(void)" (???__EMyMessObj@@YMXXZ@?A0x282c2107@@$$FYMXXZ)
1>
Serial_Force_Client.obj : error LNK2028: unresolved token (0A0003A2) "public: __thiscall CIPMessage::~CIPMessage(void)" (??1CIPMessage@@$$FQAE@XZ) referenced in function "void __clrcall `dynamic atexit destructor for 'MyMessObj''(void)" (???__FMyMessObj@@YMXXZ@?A0x282c2107@@$$FYMXXZ)
1>
Serial_Force_Client.obj : error LNK2019: unresolved external symbol "public: __thiscall CIPMessage::CIPMessage(void)" (??0CIPMessage@@$$FQAE@XZ) referenced in function "void __clrcall `dynamic initializer for 'MyMessObj''(void)" (???__EMyMessObj@@YMXXZ@?A0x282c2107@@$$FYMXXZ)
1>
Serial_Force_Client.obj : error LNK2019: unresolved external symbol "public: __thiscall CIPMessage::~CIPMessage(void)" (??1CIPMessage@@$$FQAE@XZ) referenced in function "void __clrcall `dynamic atexit destructor for 'MyMessObj''(void)" (???__FMyMessObj@@YMXXZ@?A0x282c2107@@$$FYMXXZ)
It's getting late now so I need to call it a night  , but I was going to try writing some simple code tomorrow that tests the winsock2 functionality in this case.
Thanks again for your help.
|
|
|
|
|
It's fine that the include problem is solved. Did you move all includes to stdfax.h? That is not the usual way but will be OK for small projects. Stdafx.h should only contain system includes like winsock2.h, not your project specific header files which should be included by the cpp files that need them.
The linker errors complain about the missing constructor and destructor of the CIPMessage class used as member or base class for the MyMessObjClass. To resolve this, you must add the source file with the implementation to your project (chat_client.cpp).
|
|
|
|
|
Excellent, it's all working  I was missing a portion of the source code for CIPMessage and also needed to add "ws2_32.lib" to Linker -> Additional Dependancies (at least I figured one thing out for myself  ).
Thank you very much for taking the time to help me with this and explain stdafx.h. Great stuff 
|
|
|
|
|
Fine that all is working. You are always welcome.
Just one more note:
You may replace the include of winsock2.h by afxsock.h in stdafx.h. Then you did not have to add the library to your project. That is done by import statements in afxsock.h and atlsocket.h:
#pragma comment(lib, "wsock32.lib")
#pragma comment(lib, "ws2_32.lib")
#pragma comment(lib, "mswsock.lib")
When creating a new MFC project and selecting "Windows Sockets" on the "Extended Features" tab, this will be already present in stdafx.h.
|
|
|
|
|
I have an extension dll. when I am building the dll in release mode, and call from the client mfc application it's launching, but when I am bulding the dll in debug mode and loading from client mfc application it's not launching giving error
//////////////////////////////////////////
debug assertion failed.
program:
file: f:\dd\cvtools\vc7libs\ship\atlmfc\src\mfc\appcore.cpp
line: 451
For more information on how your program can cause assertion failure, see visual c++ documentation on asserts
(Please retry to debug the application)
//////////////////////////////////////////
Please help me why this error is coming I am trying to launch the dll like this
[code]
hinstLib = LoadLibrary(L"C:\\Users\\sujan.dasmahapatra\\Documents\\Projects\\Bhagavan_SurfaceRevolution\\View inside a Dialog\\package\\RevolutionDLL\\debug\\dlltest.dll");
[/code]
when there is 'release' instead of debug it's working fine. Please help.
|
|
|
|
|
sujandasmahapatra wrote: when there is 'release' instead of debug it's working fine
probably not. but debug assertions don't happen in release mode. they're there to tell programmers that something seriously wrong has happened.
your best bet is to duplicate the problem in a debugger then see why that assertion is happening. then fix the problem.
|
|
|
|
|
sujandasmahapatra wrote: file: f:\dd\cvtools\vc7libs\ship\atlmfc\src\mfc\appcore.cpp
line: 451
Debug your code (single step), go to that line number and see what's asserting.
Read this excellent essay: Surviving the release build[^]
"Real men drive manual transmission" - Rajesh.
|
|
|
|
|
"Break" execution when the assertion is hit, then look at what the assertion is telling you. You can see what has been asserted (example):
ASSERT( pWnd );
ASSERT( pWnd!=NULL );
Then you can look at the call stack and trace back to your code (instead of looking at the mfc portion that triggered the assertion). You probably forgot to initialize something or did something incorrectly within the framework.
|
|
|
|
|
file: f:\dd\cvtools\vc7libs\ship\atlmfc\src\mfc\appcore.cpp
line: 451
You can debug the code at specified location or post that code here. 
|
|
|
|
|
The assertion is telling you the file name and the line number in the file. Have a look there and read the comment which no doubt accompanies the assertion.
Steve
|
|
|
|
|
|
By studying the vCard format[^] or Googling for vCard parsing[^] to learn how to do it (or at least find a useful tool already written for this purpose). Even CodeProject[^] has some answers, you just have to listen.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> If it doesn't matter, it's antimatter.<
|
|
|
|
|
Hi!
I am going to create a shared dll n(C++, VS .NET 2003 or VS 2008) that acts as an intermediate data source. The dll will be loaded by one application (not mine) that extracts data from the dll.
My application (C++ VS .NET 2003) is on separate PC. I want to load the shared dll and then send data to the dll.
Can I use LoadLibrary()? What commands do I use to do this over tcp/ip?
Thank you, Pia
|
|
|
|
|
Your question isn't too clear. Yes, you can use LoadLibrary to load a DLL and yes, you can use TCP/IP to send data between two computers. But it isn't clear what the connection between these two is in your context.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> If it doesn't matter, it's antimatter.<
|
|
|
|
|
More details:
I own an application running on one computer. There I can add code to access the remote dll methods. I will write the remote dll.
I do not own the other application that will access my dll locally.
The functions in the dll and my application will be simple. I will send data repetitively to the dll using a function call.
Are more details needed and what details?
The two computers will be in the same room or close, probably in the same local network. I had an idea to mount the remote folder on my PC but it does not seem possible.
|
|
|
|
|
Why do you need to load the DLL in your local application? The remote application loads your DLL, your DLL then listens on some (TCP) port and you can connect to it from your local application and send data as needed. Wouldn't this work?
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> If it doesn't matter, it's antimatter.<
|
|
|
|
|
Is this a simpler way? Do you have a code example?
I need to inform the dll that I have started sending data so that the dll can change state from Unknown to Running. However the dll can have logic enough to know that if data arrives then the sending has started  .
I may have to send 3-4 parameters of data simultaneously.
|
|
|
|
|
I don't see the need to load the very same DLL into both applications based on what you said, so i'd say, yeah, it's probably simpler. Not sure what kind of example you mean, there are loads of tutorials and examples around the web for creating DLLs and communicating over the network, just google for things like Windows Sockets[^] and Writing DLLs[^]. What else would you need?
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> If it doesn't matter, it's antimatter.<
|
|
|
|
|
|
You cannot use LoadLibrary to load a remote DLL.
You must call LoadLibrary on the local machine wherein the DLL is.
For instance, COM allows you to call methods of remote components hosted in DLLs because it creates a stub process in the machine wherein the DLLs are.
Veni, vidi, vici.
|
|
|
|
|
So I accept I have to use DCOM instead of the "simple" LoadLibrary
Can you please point me to a code example/tutorial on how I call methods in my remote DLL (not .exe)using DCOM?
Alternatively add a code example?
More details:
I own an application running on one computer. There I can add code to access the dll methods. I will also write the dll.
I do not own the other application that will access my dll locally using LoadLibrary.
The functions will be simple. I will send data repetitively to the dll.
Thank you!
Pia
|
|
|
|
|
Actually you don't need DCOM (you may use it if you like), you may use RPCs or implement you own TCP mechanism to communicate with the remote executable that loads the DLL.
CodeProject has some articles[^] about DCOM.
Veni, vidi, vici.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif)
