--- In [email protected], "Sheri" <sheri...@...> wrote: > > It still seems to work ok when the target is provided and no color > variable requested (e.g. CA). > > I tested the new format using values retrieved from non-control bar > items. Existing cl commands let us set, but not get, most font > information. For getting, we have only cl.getFontName.
try dialog.get_value(hWin, "font")). Probably won't work on any window belonging to another process. > Choose_font does currently work ok for initializing if given a > fontface only when the size and other attributes are omitted, and the > provided fontface has no spaces in it. > If the retrieved fontname has any space in it, it doesn't work with > name only. I constructed what I think should be a complete valid font > spec by surrounding the fontname with double quotes and tacking three > spaces and 10.0 on the end. But that doesn't work either. > The form I was using was: > > dialog.choose_font(<font_spec>, <var_for_colour>) Okay, try latest version dialogplugin1.19_081219.zip in http://tech.groups.yahoo.com/group/power-pro/files/0_TEMP_/AlansPluginProvisional/ > Question on dialog font service vs. *controls in bars. > dialog can get and set fonts as well as background color for *controls > on bars control that supports such things. Not sure what's up with > foreground color. > > I know that at least with fonts there are resource implications, that > a font is created that needs to be destroyed. What if anything does > the dialog plugin do to ensure that the created font is destroyed when > no longer needed? Can I repeated use dialog's font services on a given > control without worrying about it? Taken care of for dialog-plugin owned controls. Not possible for now for controls/windows belonging to other processes. For other controls/windows belonging to Powerpro: At the moment, I don't attempt to delete an existing font after using WM_SETFONT to set a new one. I could use WM_GETFONT to get current font for a PowerPro control/window, and I could DeleteObject on it after WM_SETFONT. I'll try that and see if it causes any problems. But: I don't know what Bruce's code does when his bars/buttons die. If he also uses DeleteObject, he'll be using it on an already-delete HFONT, but docs say "If the specified handle is not valid or is currently selected into a device context, the return value is zero." implying that nothing terrible will happen. When bar/button given a new font by WM_SETFONT is destroyed, there's no way the correct HFONT associated with bar/button will be destroyed, so they'll be a memory leak: bruce's code will probably delete the HFONT it thinks belongs to the bar/button.
