|
I am using this code in oninitdialog function to set up the bold font on initialization of dialog. There is no difference in other dialog boxes and this one for setting up the fonts. I havent initialized the pWnd in this code and in any other initdialog functions but still that works.
|
|
|
|
|
I have attached the control of dialog box to the cwnd object using getdlgitem()..
|
|
|
|
|
So you say you call GetFont thorough an uninitialized pointer and it works???? That doesn't sound normal...
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Computers are evil, EVIL i tell you!! <
|
|
|
|
|
hey i have initialized the cwnd object by passing the control of the dialog box static text using getdlgitem() function
|
|
|
|
|
And you did the same thing in all your dialogs, retrieve the handle of a static on the dialog in OnInitDialog, attach a CWnd to it, call GetFont on it, and it gave you a valid CFont pointer except for this one, identically implemented dialog? Can't think of anything smart, sorry...maybe someone else has a better response then.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Computers are evil, EVIL i tell you!! <
|
|
|
|
|
hey after doing some research work .. This problem is changed to the static text only.. The problem seems to work on the button controls but when i use static text for the cwnd object initialization to get the font then it crashes in the getlogfont function... so give me some insight for this....
|
|
|
|
|
My guesses are as follows:
-since the documentation for WM_GETFONT says that a NULL return value means the control is using the system font, a NULL from the static control must mean it is using the system font.
-possible that the static control will use the font of its parent window to draw text unless it gets a different font explicitly set to it via WM_SETFONT, and that is why you get the NULL back, meaning that the static doesn't have its own font set, it will use its parent's.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Computers are evil, EVIL i tell you!! <
|
|
|
|
|
so why is it working for the button control and not for the static text control... and also this static text control thing do work in different dialog classes.. and I havent explicitly called the WM_getfont for those classes....
|
|
|
|
|
decoder_85 wrote: so why is it working for the button control and not for the static text control
-because of their different implementation i supose
decoder_85 wrote: and also this static text control thing do work in different dialog classes
-i can't tell you that without seeing the whole picture
decoder_85 wrote: and I havent explicitly called the WM_getfont for those classes
-CWnd::GetFont(), which is inherited by the CDialog, is just a wrapper around WM_GETFONT, if you call it, WM_GETFONT is sent to the control, and on the handle it returns CFont::FromHandle is called, you can check that yourself if you take a peek at CWnd::SetFont's implementation (try right-clicking it in visual studio and select "Go to definition" or somesuch)
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Computers are evil, EVIL i tell you!! <
|
|
|
|
|
Hi All
How to Convert character to other character like german,dutch etc. which user can change a language during run-time, for example, selecting it from menu.Can any one help me
modified on Monday, May 31, 2010 1:18 AM
|
|
|
|
|
I think there is no easy method to do this. You have to store each language strings separately and use them based on the language selection from menu.
prvn
|
|
|
|
|
There is no nay dll for this work.
|
|
|
|
|
Sorry. No
prvn
|
|
|
|
|
|
It's not clear exactly what you mean. I sounds like you might want to add the ability to change the language of you application dynamically at runtime, but this is only a guess.
Steve
|
|
|
|
|
|
Hey fellas!
Just a quick question, does CB_FINDSTRINGEXACT expect a unicode string, an ansii string or what? The documentation[^] doesn't specify this. As far as i know I can use CString (TCHAR's...) in both Unicode and non-unicode builds with this message, with some messages there is a unicode and a non-unicode version of it, usually postfixed by W and A to indicate the difference, however, CB_FINDSTRINGEXACT is hardwired to be 0x0158 in winuser.h, there seems to be no CB_FINDSTRINGEXACTA and CB_FINDSTRINGEXACTW. So does the control somehow detect if it is getting a unicode or a non-unicode string when handling this message? Or if it was created with the unicode version of CreateWindow (CreateWindowW) then it will expect a unicode string while if it was created with CreateWindowA then a non-unicode string?
Thanks for any answers in advance.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Computers are evil, EVIL i tell you!! <
|
|
|
|
|
Windows are either unicode or ansi depending on how they're created. If you send a message to a window from a window of a different type it marshalls the parameters.
Cheers,
Ash
|
|
|
|
|
Thanks for your answer.
So you mean if the combo box was created with the wide version of CreateWindow then it expects a wide character string, if it was created with the ansi then an ansi string?
Aescleal wrote: If you send a message to a window from a window of a different type it marshalls the parameters.
-i don't quite understand what you mean by this. If i send a message either with SendMessage or PostMessage there's no "from window" specified, how do you mean that?
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Computers are evil, EVIL i tell you!! <
|
|
|
|
|
Slight confusion there sorry about that - it's the version of SendMessage or PostMessage that determines how the parameters are marshalled. If you stick to one character type consistently in your app you shouldn't have a problem.
Cheers,
Ash
|
|
|
|
|
Ah, makes sense this way, thank you for enlightening me.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Computers are evil, EVIL i tell you!! <
|
|
|
|
|
It's actually the window class of the window that determines whether it's unicode or ansi - so it's RegisterWindowEX and not CreateWindowEx that determines the type of window.
One day I'll be competent at answering questions, until then I hope I haven't confused the issue too much.
Ash
|
|
|
|
|
No, it is clear now, or i am too confused to notice that i am confused. Thanks again for the info.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Computers are evil, EVIL i tell you!! <
|
|
|
|
|
Why is it usually can output "main thread is running" one more, because if I don't use "/MT" option?
#include <windows.h>
#include <iostream.h>
DWORD WINAPI Fun1Proc(LPVOID lpParameter);
void main()
{
HANDLE hThread1;
hThread1=CreateThread(NULL,0,Fun1Proc,NULL,0,NULL);
CloseHandle(hThread1);
cout<<"main thread is running"<<endl;
}
DWORD WINAPI Fun1Proc(LPVOID lpParameter)
{
cout<<"thread1 is running"<<endl;
return 0;
}
this is the output result:
D:\Test>cl Thread.cpp
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8804 for 80x86
Copyright (C) Microsoft Corp 1984-1998. All rights reserved.
Thread.cpp
Microsoft (R) Incremental Linker Version 6.00.8447
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.
/out:Thread.exe
Thread.obj
D:\Test>Thread
main thread is running
main thread is running
thread1 is running
D:\Test>cl Thread.cpp /MT
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8804 for 80x86
Copyright (C) Microsoft Corp 1984-1998. All rights reserved.
Thread.cpp
Microsoft (R) Incremental Linker Version 6.00.8447
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.
/out:Thread.exe
Thread.obj
D:\Test>Thread
main thread is running
thread1 is running
D:\Test>
Why should that be?
|
|
|
|
|
/MT means that the standard runtime library code is properly interlocked so if you use a global object like cout you won't confuse it's internal state. Now quite what happened in your case I can't say not having used the compiler you're using for 8 years but it looks like it got confused when flushing the stream in one of the threads. Basically if you use multiple threads and the standard library without /MT (or the DLL equivalent) don't expect it to work!
Cheers,
Ash
|
|
|
|