|
the code which i am using is
CWnd* p_Wnd;
CFont* pFont;
pFont = p_Wnd->GetFont();
LOGFONT m_lFontBold;
pFont->GetLogFont(&m_lFontBold);
I am getting error in getlogfont in debugging mode. As far my understanding the getfont() isn't returning the handle to the object that is why there is an assertion problem in getlogfont(). But the same code is working properly in different dialog boxes.
|
|
|
|
|
In the code you have shown you never initialize p_Wnd to anything...but i will assume that in the actual code segment you do. So what is the difference between this dialog and the others? How do you create it? When/Where do you ask for its font?
> 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!! <
|
|
|
|
|
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!! <
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
