--- In [email protected], "Sheri" <sheri...@...> wrote: > > > --- In [email protected], "entropyreduction" > > <alancampbelllists+yahoo@> wrote: > > > > Just uploaded dialogplugin1.19_081224.zip > > Fixed, I think. > > Not clear if you were aiming to fix by actually retrieving the correct > values or just to default to System Bold 12 when the target is a whole > bar or its PowerProChildToolbar?
I use GetStockObject(SYSTEM_FONT)if SendMessage(hwnd, WM_GETFONT, (WPARAM) 0, 0) returns 0. > I created and showed TempBar. Used new dialog version to get_value, > "font" and choose_font on the resulting whole bar and child > PowerProChildToolbar. > New version still doesn't see the Arial, returns System > New version returns Bold > New version returns size 12 instead of size 10. > > So new version is an improvement in that it doesn't crash or present > impossibly large size vaiues for whole bar or child toolbar handles, > but it doesn't retrieve the correct values. Perhaps document as a > limitation (unless there is a way to really fix it). Reading up on, WM_GETFONT, MSDN pages say "This message is sent by an application to a control to retrieve the font with which the control is currently drawing its text." and "The WM_GETFONT message does not return a font handle if the message is sent to a dialog box created by the DialogBoxParam, DialogBoxIndirectParam, CreateDialogParam, or CreateDialogIndirectParam function." which suggests SendMessage(hwnd, WM_GETFONT,... may have problems with anything that doesn;t behave as a control. In fact, since Bruce apparently hand rolled code for bars and buttons, and didn;t subclass a control class, he'd maybe have to have dealt with WM_GETFONT in his WndProc code. > > Re destroying a font resource: suppose I provide > > a variant of dialog.clear e.g. dialog.clear(hwnd, "font") > > which will destroy the HFONT used by a window, and set it's > > font to the system font. To be used with care, only on > > powerpro-owned windows. > > > If asking, yes, I think that would be useful. Also possibly a > destroy_font service that would take an actual font handle (so dll > plugin wouldn't be needed in order to do it, e.g., if no window is > still using some known font handle that previously got created with > set_font). Something like that should be doable.
