--- In [email protected], "Sheri" <sheri...@...> wrote:
>
Sorry, are next paras up to "==============" superceded
by
> Seems to be working well now. If Bruce would add a few cl services
??
> ...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?
Yes.
> 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.
Too fancy.
And what happens if, in between, control's font is changed by pproconf?
