Re: Bug in TXBrowse?
![Post Post](./styles/prosilver/imageset/icon_post_target.gif)
TXBrowse when created, calls ::GetFont() method for the purpose of assigning itself the same font as the containing window. Calling GetFont() is the standard method for this.
GetFont() method is in TWindow class. If the container window does not have a font already assigned, this in turn executes that window's GetFont() method. In case of a dialog created from resource, it tries to create and assign a font object to it on the basis of font metrics of the dialog. Theoretically this assigned font object should be identical to the hFont of the dialog when created from resource.
The relevant part of the code is this:
I do not know for what reason the oDlg:oFont is different from the hFont queried with WM_GETFONT.
This problem is the same as the selfont() or choosefont() function's problem. Even there the oFont created from the fontmetrics differ from the selected font.
I could not yet find a solution for this. Greatly appreciate any help from you.
So the real issue is here to fix.
Meanwhile the one workaround is to assign a font object to the Dialog() as close to the font definition of the Dialog in resources.
GetFont() method is in TWindow class. If the container window does not have a font already assigned, this in turn executes that window's GetFont() method. In case of a dialog created from resource, it tries to create and assign a font object to it on the basis of font metrics of the dialog. Theoretically this assigned font object should be identical to the hFont of the dialog when created from resource.
The relevant part of the code is this:
- Code: Select all Expand view
- if ::oFont == nil
if ( hFont := ::SendMsg( WM_GETFONT ) ) != 0
aInfo = GetFontInfo( hFont )
oFont = TFont()
oFont:hFont = hFont
oFont:nCount = 1
oFont:nHeight = aInfo[ 1 ]
oFont:nWeight = aInfo[ 2 ]
oFont:lBold = aInfo[ 3 ]
oFont:cFaceName = aInfo[ 4 ]
oFont:lDestroy = .f.
::oFont = oFont
I do not know for what reason the oDlg:oFont is different from the hFont queried with WM_GETFONT.
This problem is the same as the selfont() or choosefont() function's problem. Even there the oFont created from the fontmetrics differ from the selected font.
I could not yet find a solution for this. Greatly appreciate any help from you.
So the real issue is here to fix.
Meanwhile the one workaround is to assign a font object to the Dialog() as close to the font definition of the Dialog in resources.