This one has been bugging me all day. I'm trying to fill a consoles screen with null characters using FillConsoleOutputCharacter() passing '\0' as the character. This works flawlessly in a non-unicode build, but after switching to unicode it just doesn't work.
After reading the buffer it becomes apparant that the screen was filled with spaces 0x0020. Thinking it was a problem with the null character I then tried '0x0A' and '0x000A' both of which fill the buffer with '0x25D9'.
Do I need to do anything special before trying to fill with a unicode null character, or does the function just not work in a unicode build?
I have installed Visual Studio 2005 8 in D:\Program Files\ and WM SDK 5.0 in C:\Program Files\.
The WM5 SDK comes with a few samples, and I've chosen the bluetooth one, named BTSeach (I've seen it between codeproject's articles, too). I've launched it from the default directory: C:\Program Files\Windows CE Tools\wce500\Windows Mobile 5.0 Pocket PC SDK\Samples\CPP\Win32\Bluetooth
When I compile it i get 2 errors, and I didn`t modify anything (anyway it's an linking error, so I guess the filepaths aren't correctly set). The output is:
------ Build started: Project: btsearch, Configuration: Debug Windows Mobile 5.0 Pocket PC SDK (ARMV4I) ------
btsearch.obj : error LNK2001: unresolved external symbol __GSHandlerCheck
Windows Mobile 5.0 Pocket PC SDK (ARMV4I)\Debug/btsearch.exe : fatal error LNK1120: 1 unresolved externals
Build log was saved at "file://c:\Program Files\Windows CE Tools\wce500\Windows Mobile 5.0 Pocket PC SDK\Samples\CPP\Win32\Bluetooth\btsearch\Windows Mobile 5.0 Pocket PC SDK (ARMV4I)\Debug\BuildLog.htm"
btsearch - 2 error(s), 0 warning(s)
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
Does any of you know where I should write the paths for files which should resolve this linking issues?
Thank you a lot!
I`re solved this problem, and I`d like to post here, to help one who gets stuck in the same spot.
The problem seems to be the Service Pack 1 update. This is a known issue, and on microsoft site ( http://support.microsoft.com/kb/928957/ ) it`s posted this:
Error LNK2019: unresolved external symbol __GSHandlerCheck
Samples in both the Windows Mobile 5.0 SDK for Pocket PC and the Windows Mobile 5.0 SDK for Smartphone are affected by this issue.
Visual Studio 2005 SP1 updates the Visual Studio compilers with the /GS support that is already available in Windows CE 6.0 compilers. Link errors will occur in native C++ Smart Device projects that do not explicitly link to “libcmt.lib” or that have turned off /GS, and that are running on pre-Windows Embedded CE 6.0 platforms.
To resolve this issue:
1. Explicitly include "libcmt.lib" in the list of additional libraries to link against.
2. Turn off the linker warning (/nowarn:4099)
I didn`t actually manage to do this, but I've done something else. I`ve basically searched my WM5 SDK for 'libcmt.lib' (found around 7 results) and picked the one addressing the platform I was writing code for (that is AVRM4I). And simply added it to my project (add file to project > existing file). The warn doesn`t bother me.
It is been quite a while. I have a task to identify a calling Windows' batch script's name and its location. Basically, the batch script calls/spawns my C++ executable as a parent process and I failed to identify the parent. I can identify a number of different calling processes using NtQueryInformationProcess(), but failed to do so to the batch script. The main reason is that the batch process is shown as cmd.exe not a real script name.
The idea that I can be presented with a problem, set out to logically solve it with the tools at hand, and wind up with a program that could not be legally used because someone else followed the same logical steps some years ago and filed for a patent on it is horrifying.
- John Carmack
When it's window handle is "valid" or IsWindow(...) which of course happens after CreateWindow and before DestroyWindow. Also you must be accessing the object from the same thread it was created in since MFC uses TLS to maintain CWnd/HWND data (there are technotes on this). There are ways to create temporary valid CWnd objects in worker threads but you need to know what you are doing when using that technique.
sigh Mike, let me be more specific. Given I need to create a window that is parented by another window. I actually need to do this with an activeX control, but I think the point is valid. And, thankfully, we're single threaded for this question.
I create my object that contains my first window. The constructor fires, and messages begin to be delivered. Eventually, a WM_PAINT arrives and some basic drawing code fills in the visual portion of the window. Things quiet down after the initial burst of events. Somewhere in that initial burst of events, the window for the object is actually valid, and IsWindow goes true.
Is it after WM_CREATE? WM_PAINT? Something in win32 or mfc sets that field....
Will program for food...
Whoever said children were cheaper by the dozen... lied.
Overheard in a cubicle: "A project is just a bug under development."
Seeking to rise above the intelligence of a one eared rabbit...