|
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
|
|
|
|
|
Firstly, as mentioned by others, if you're using C runtime library functions (cout in your case) from a thread you've created then you should be using the multithreaded version (use the /MT option). A second but related issue is how you're starting the other thread. If you're creating a thread from which you're going to use CRT functions then you should use the one of the CRT's thread creation functions: _beginthread, _beginthreadex[^]. If you read the documentation for CreateThread[^] (the thread creation function you're using) it has the following warning:
A thread in an executable that calls the C run-time library (CRT) should use the _beginthreadex and _endthreadex functions for thread management rather than CreateThread and ExitThread; this requires the use of the multi-threaded version of the CRT.
Doing things the way you are results in calling CRT functions on a thread for which per-thread state has not been initialised. As a side note, if you had used _beginthread or _beginthreadex your application would have failed to compile when /MT was not used.
Steve
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
