--- In [email protected], "entropyreduction" <alancampbelllists+ya...@...> wrote: > > --- In [email protected], "Sheri" <sherip99@> wrote: > > > > --- In [email protected], "brucexs" <bswitzer@> wrote: > > > > > > --- In [email protected], "Sheri" <sherip99@> wrote: > > > > > > > > Would it be feasible to retrieve the color that is set inside the > > > > font dialog? From what I've read "the rgbColors member of the > > > > CHOOSEFONT data structure contains the selected color." I'm > > > > thinking of some special variable that could be requested after > > > > the dialog is closed, e.g, dialog_font_color. > > Yeah, doable. But it means changing dialog plugin font_spec and > set_font, since best way to do it is return a string like > > "Arial IB 14 c:255"
Not worth it if font spec changes. How about a special variable, e.g., dialog_font_color which user would need to define if wanted? local dialog_font_color local new_font_spec=dialog.choose_font(font_spec_w_no_color) win.debug(dialog_font_color, new_font_spec) > >I was also interested in trying to change the style of a bar so > >that it has a caption (remove toolwindow style and add > >ws_caption, sysmenu and minbox or reverse at will). Dialog's > >change_style service is documented to work on non-dialog > >controls, but I guess not on main windows (I gave it a bar's > >window handle and got an error message: "dialog handle isn't"). > >Since dialog is in the same process space as powerpro and its > >bars, it seems like it could potentially change the style of a > >bar window. But if the facility could be easily added as a cl > >service, that would be better. Main reason for wanting it is to > >be able to see a certain floating bar's footprint on the taskbar > >and in active buttons when it is not on top. > > I'll check that out. So you;re passing the windows handle of a bar > to change_style? > > Not sure what style changes work and what don't. Some styles > appaear to only make a difference on window creation. Others seem > to work on-the-fly, on an existing window. Not sure of the rhyme > or reason. Can you think of a case where a window gains/loses > e.g. minbox once already created? I can;t, but I haven;t really > looked. OK, I did this in diverpp: I removed the extended style for WS_EX_TOOLWINDOW, then set the extended style. Then I toggled on and off win.ontop for the window's handle (could have done in diverpp, but used PowerPro). After that, the bar's footprint was visible on the taskbar and clicking it on the taskbar brought it to the front when it was behind other windows. I couldn't find a combination of other style changes that caused it to "minimize" if I clicked the taskbar item again. And the window does not appear in Active Buttons. PowerPro Bars are probably being excluded from the population of Active Buttons. Don't know if the diverpp part could be replicated by the dialog plugin, but it seems more likely this time since unlike pproconf, dialog is in the same process as powerpro. Regards, Sheri
