--- In [email protected], "entropyreduction"
<alancampbelllists+ya...@...> wrote:
>
> --- In [email protected], "Sheri" <sherip99@> wrote:
> >
> > It still seems to work ok when the target is provided and no color
> > variable requested (e.g. CA).
...unless the target provided to choose_font doesn't support getting
its font, then the service gives an error (wrong number of arguments).
If the target provided to choose_font is the handle to a whole bar,
font dialog opens with Microsoft Sans Serif and an absurdly large font
size of 721788. Properties for the tested bar actually had:
TempBar.NewProperties(?"fontname = Arial\nfontinfo = Bold Size: 10")
Using get_value to get the font, the following crashes PowerPro:
local TestBarhandle=cl.getbarhandle("TestBar")
win.debug(dialog.get_value(TestBarHandle, "font"))
It also crashes PowerPro if you use get_value to try to get the font
for a window with class PowerProChildToolbar.
If an individual *control item has its own font (via cl.setfont),
dialog.get_value(controlhandle, "font") gets its fontspec accurately
without crashing. Ditto for choose_font.
> >
> > 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.
The non-control bar items. is PowerProChildToolBar. Crashes to do what
you said.
>
> > 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/
>
Seems to be working well now. If Bruce would add a few cl services to
get the items currently not accessible, we'd be all set.
Bruce, would you consider the following services?
cl.GetBarFontName, cl.GetBarFontInfo, cl.GetFontInfo
> > 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.
Probably best to use cl services for setting bar items. Unfortunately
for some items that means having to re-create the control with current
text just to keep the current label. Otherwise if the control's text
has been changed, e.g., with win.settext, cl.refresh (which is needed
to see a font change via cl.setfont for a *control item) restores the
text that was in the original *control's label.
If you use the same fontspec on multiple controls, do they each get
their own HFONT?
If so, another alternative would be to implement an event to check
once in awhile to see if the control still exists, and if not destroy
the HFONT that was set into it. Meanwhile if another font change
happens you destroy an old HFONT, you could also destroy the pending
event.
Regards,
Sheri
