Hi Graeme, Thanks for the tips.
Console apps with the Laz GUI linked in (i.e., linked against a widgetset via inclusion of interfaces unit) work fine on Windows and Carbon and even with GTK on OS X if run in an X termimal. However, I would like to be able to have a truer console app (and a much smaller one too). ColorToRGB is widgetset-dependent so I can't use that if I want a true console app. Another problem I've run into is trying to decide what RGB value to use for color constants. For example, ColorToRGB(clBtnFace) returns different RGB values on Windows, OS X Carbon and OS X GTK, as implemented by the widgetsets' GetSysColor. Probably different values would also be returned on the same platform depending on user preferences too. So I guess my problem is how to map color constants for use, say, in other programs or in a Web browser. Maybe just use a default Windows set of RGB values or something would make sense. Thanks. -Phil -----Original Message----- From: Graeme Geldenhuys [mailto:[EMAIL PROTECTED] Sent: Monday, February 11, 2008 2:09 AM To: lazarus@miraclec.com Subject: Re: [lazarus] ColorToRGB in console app On 10/02/2008, Hess, Philip J <[EMAIL PROTECTED]> wrote: > > Of course, now the app has the same issues as any Mac GUI app compiled with > GTK, in that even though it's a console app (sort of), it will only run under X11. And > no way to compile for Carbon with lazbuild unless the framework carbon stuff already > set in the .lpi. That's correct. You can't include the 'interfaces' unit in a console application because it requires (pulls in) GUI code. You will not notice anything under Windows, because Windows always has a GUI installed. Under Linux it's easily noticed when you don't run a X Server and try an execute a console application that uses 'interfaces' unit. I had this same issue in the tiOPF project and console unit tests on my Linux server which doesn't run a X Window server installed. Some unit tests required the clipboard, which is a GUI feature in LCL or VCL. I had to rework the unit tests to exclude those tests when run as a true console application. > RGB value _or_ a color constant like clBtnFace (value of 15). If someone passes a > color constant to one of these functions, they'll get an unexpected result. So it > seems as though RedGreenBlue, etc. should either call ColorToRGB first or else the > param type should be Again correct and what I forgot to mention in my previous post. If you pass in a clXXXX color alias (like clBtnFace etc) you first need to lookup the RGB equivalent color value via ColorToRGB. In fpGUI it's possible to do without requiring a true GUI installed, but I'm not sure what would happen under Windows etc... Regards, - Graeme - _______________________________________________ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ _________________________________________________________________ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives _________________________________________________________________ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
