--- In [email protected], "Sheri" <sheri...@...> wrote:
Now, this is weird. New dialog plugion trioal (dialogplugin1.19_090102.zip) in usual folder http://tech.groups.yahoo.com/group/power-pro/files/0_TEMP_/AlansPluginProvisional/ I bunch of messages ago everyone agreed WM_GETFONT probably didn't work across process boundaries, cause it required passing a point to a LOGFONT struct. But try this: local sTitle = "Untitled - Notepad" local sApp = "notepad.exe" local sctrlClass = "c=Edit" do(sApp) wait.for(500) local hHan = win.childhandlelist(sTitle, sctrlClass) win.debug(hHan) win.debug("Font of notepad edit control: " ++ dialog.get_value(hHan, "font")) For me returns Lucida Sans. Which seems to suggest it's correctly picking up font of edit box. How? Don't ask me. Not working in current version for richedit boxes; current code assumed target control was non-unicode, using richedit 2.0, which is true for controls generated by plugin; but if I'm dealing with an arbitrary ricedit control, can be wide-character, which means CHARFORMAT or CHARFORMAT2 is probably assumed to be tjhe WCHAR version. Working on that. > > All I can do is send a WM_GETFONT to a window. It can return > > NULL, which means either the window doesn't handle WM_GETFONT, or > > that it's using the system font; I can't tell which. > > > > In such a case I can either have dialg.get_value(hwnd, "font") > > return a null string or something like "NO FONT". Your preference? > I guess null string is fine. If dialog.choose_font runs on a target > like that I think I would prefer that it open with no font > pre-selected. If one needs to be selected, probably the stock gui font > would be preferable to system font. Should be returning null string when can't get a sensible answer.
