Jun 12, 2019 at 2:08pm UTC
HWND hWnd = CreateWindowW(szWindowClass, szTitle, WS_OVERLAPPEDWINDOW,
x_pos,y_pos,wWidth,wHeight, nullptr, nullptr, hInstance, nullptr);
// works fine
HWND status_hnd = CreateStatusWindowA(WS_CHILD | WS_VISIBLE, 0, hWnd, 9000);
LNK2019 Verweis auf nicht aufgelöstes externes Symbol "__imp__CreateStatusWindowA@16"
Jun 12, 2019 at 2:18pm UTC
It is most likely the mix of 'A' (ANSI) and 'W' (UNICODE) variant.
So change CreateStatusWindow A(...) to CreateStatusWindow W(...).
Jun 12, 2019 at 2:18pm UTC
This is for UNICODE builds.
This is for ASCII builds.
Decide which version you're going with.
You managed it with ShowWindow for example.
You can solve the whole problem by NOT trying to second-guess which version you're building, and just use the function names WITHOUT the A/W suffixes.
Jun 12, 2019 at 3:17pm UTC
No. It ain't that easy. I checked all three possibilities before. CreateStatusWindow A/W.
I have seen various questions on this problem in the net ... Didn't see any satisfying answer.
Forgot to mention ... Visual studio 1900.
btw. the linkerror is LNK1120.
Last edited on
Jun 12, 2019 at 3:31pm UTC
Jun 12, 2019 at 3:23pm UTC
Nonetheless You need to be consitent with the A/W variant.
Do you linke against the 'comctl32.lib' library?
Jun 12, 2019 at 4:27pm UTC
MS ... "This function is obsolete. Use CreateWindow instead".
Yes, this always means: "stable function because of compability".
The function is in commctrl.h.
Of course I could use CreateWindowEx instead, but would like to know what causes the problem
Jun 12, 2019 at 4:58pm UTC
"Do you link against the 'comctl32.lib' library? "
I do not know nothing on c++ ... What do you mean with this ?
Jun 12, 2019 at 4:59pm UTC
Your linker disagrees, otherwise it would have resolved the symbol.
Jun 12, 2019 at 6:00pm UTC
"Your linker disagrees, otherwise it would have resolved the symbol"
Beautyful, that's quite obvious. I am asking why ?
"On the command line? If so, what is the command?"
No, using Visual studio 1900 ...
Loading a filename.vcxproj and clicking create filename.
If I add comctl32.lib, no errormessage, but the linker creates: filename.dll instead of filename.exe
Jun 12, 2019 at 7:48pm UTC
> Beautyful, that's quite obvious. I am asking why ?
Why is because the symbol doesn't exist in any libraries any more.
That's what obsolete means.
Now go and edit your 1990's code and bring it up to date with a better function.
Jun 12, 2019 at 8:18pm UTC
Of course I am using Visual Studio 2019 (not 1990), because I installed it today (my mistake).
"Why is because the symbol doesn't exist in any libraries any more.
That's what obsolete means"
That's what it usually doesn't mean if MS uses this sentence.
Like I said:
This always means: "stable function because of compatibility".
I can use CreateStatusWindow in other languages.
Of course It might be different in Visual studio 2019, but I doubt it.
But ok. ... So I use CreateWindowEx.
Have a good one !
Jun 12, 2019 at 11:10pm UTC
statuswindow with CreateWindowEx.
char status_win_text = "Der Text in dem Status Window";
status_hnd = CreateWindowEx(0, STATUSCLASSNAME,0, WS_CHILD | WS_VISIBLE, 0, client.bottom, client.right, 26, hWnd, NULL, hInstance, NULL);
SendMessage(status_hnd,SB_SETTEXT, SBT_NOBORDERS, (LPARAM)status_win_text);
It works, but the text in the window seems to be chinese.
Visual studio is interesting.
Jun 12, 2019 at 11:16pm UTC
If you're building Unicode, but supplying a char based string, Windows is not able to "understand" what is actually an "ASCII" text. It's interpreting that as Unicode, sending out what it thinks is right.
Change the char to a unicode compatible declaration, and issue the string literal as a Unicode string, not an ASCII (8 bit) character array (which is what you have now).
Windows isn't the problem here, compatibility with the configuration of the compiler is.
We all must use string literal methods (and variable declarations) compatible with the configuration of the compiler. Use a version that mutates according to configuration automatically and you're good.