User forums > Using Code::Blocks
Problems building C++ code using a Serial library
PaulUK:
--- Quote from: BlueHazzard on June 16, 2020, 08:57:57 pm ---
--- Quote ---Yes, I cleared previous build data and rebuilt.
--- End quote ---
There is no sign of the serial.cpp in your build log, so you have not added it to the project properly...
Check if there are ticks in Project->Properties->Build targets->Select your target on the left->Check if all source files are ticked in "Build target files"
Edit: Have you included Serial.h?
--- End quote ---
I double checked this and the serial.h and serial.cpp files are checked in the "Build Target Files" window.
However when I check the files in the Headers tree in the Workspace, they are in grey not black. When I right click on a file then select properties, the check boxes for Compile file and Link file are unchecked. Could this be a problem? It doesn't seem to match the previous check when checking the Build Targets from Project->Properties.
BlueHazzard:
Interestingly this is some bulls***** with the microsoft types...
what LPCTSTR is not clear for me and probably also the linker/compiler...
it is a (long) pointer to constant TCHAR string
and TCHAR is wchar_t if UNICODE is defined and char otherwise....
Somehow during compiling TCHAR seems to be wchar_t and during linking it seems to be char
If i modify your serial open function signature to
--- Code: ---virtual LONG Open(const char* lpszDevice, DWORD dwInQueue = 0, DWORD dwOutQueue = 0, bool fOverlapped = SERIAL_DEFAULT_OVERLAPPED);
--- End code ---
it links and compiles fine for me.
Ultimately this is not a codeblocks problem....
[EDIT:] i did not tested it, and i do not know what type or encoding (probably utf-16) LPCTSTR has during runtime. So you still can get some crash compiling it that way...
[EDIT2:] Probably some windows guru can help you better or bring light in the dark API
BlueHazzard:
The right way to do this is probably add
--- Code: ---UNICODE
--- End code ---
in Project->Build options->Select your project name on the left->Compiler settings->#defines
i was thinking
--- Quote ---wxUSE_UNICODE
--- End quote ---
expands to this on windows, but i was wrong....
PaulUK:
--- Quote from: BlueHazzard on June 17, 2020, 10:36:06 am ---Interestingly this is some bulls***** with the microsoft types...
what LPCTSTR is not clear for me and probably also the linker/compiler...
it is a (long) pointer to constant TCHAR string
and TCHAR is wchar_t if UNICODE is defined and char otherwise....
Somehow during compiling TCHAR seems to be wchar_t and during linking it seems to be char
If i modify your serial open function signature to
--- Code: ---virtual LONG Open(const char* lpszDevice, DWORD dwInQueue = 0, DWORD dwOutQueue = 0, bool fOverlapped = SERIAL_DEFAULT_OVERLAPPED);
--- End code ---
it links and compiles fine for me.
Ultimately this is not a codeblocks problem....
[EDIT:] i did not tested it, and i do not know what type or encoding (probably utf-16) LPCTSTR has during runtime. So you still can get some crash compiling it that way...
[EDIT2:] Probably some windows guru can help you better or bring light in the dark API
--- End quote ---
Ah I see. I just made the change to both the serial.h and .cpp files and it compiles without error. Well, your help has got me one step further and I will replace all occurrences of "LPCTSTR" with "const char*" in the library. I didn't know it was a Microsoft related type.
I'm hoping that I can use CodeBlocks as my main IDE instead of Microsoft and in the last few months I have been trying it out. I'm no expert and still run into brick walls with issues such as this, but as you point out its a MS issue not CB. Thank you for looking into it, I really appreciate it.
BlueHazzard:
--- Quote ---Ah I see. I just made the change to both the serial.h and .cpp files and it compiles without error. Well, your help has got me one step further and I will replace all occurrences of "LPCTSTR" with "const char*" in the library. I didn't know it was a Microsoft related type.
--- End quote ---
See my second answer. It is probably better!!!
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version