OpenEuphoria

Re: IDE and copyBlt

• Posted by Derek Parnell <derekp at solace.com.au> Nov 27, 2000
• 376 views

Hi Judith,

> But we don't have a pen color corresponding to button color. Can we
> make one for win32lib? Is there a better way to do what I'm trying
> to do?

try this

   setPenColor( id, getSysColor( COLOR_BTNFACE ) )

this function translates the symbolic color, COLOR_BTNFACE in this example,
to the correct RGB value for it.

There is a whole set of symbolic colors to use ...

    COLOR_SCROLLBAR
    COLOR_BACKGROUND
    COLOR_DESKTOP  alias for COLOR_BACKGROUND
    COLOR_ACTIVECAPTION
    COLOR_INACTIVECAPTION
    COLOR_MENU
    COLOR_WINDOW
    COLOR_WINDOWFRAME
    COLOR_MENUTEXT
    COLOR_WINDOWTEXT
    COLOR_CAPTIONTEXT
    COLOR_ACTIVEBORDER
    COLOR_INACTIVEBORDER
    COLOR_APPWORKSPACE
    COLOR_HIGHLIGHT
    COLOR_HIGHLIGHTTEXT
    COLOR_BTNFACE
    COLOR_3DFACE alias for COLOR_BTNFACE
    COLOR_BTNSHADOW
    COLOR_3DSHADOW alias for COLOR_BTNSHADOW
    COLOR_GRAYTEXT
    COLOR_BTNTEXT
    COLOR_INACTIVECAPTIONTEXT
    COLOR_BTNHIGHLIGHT
    COLOR_3DHILIGHT alias for COLOR_BTNHIGHLIGHT
    COLOR_3DDKSHADOW
    COLOR_3DLIGHT
    COLOR_INFOBK  (tooltips)
    COLOR_INFOTEXT


On another topic, Ralf's suggestion that win32lib take on board the
responsibility for generating code is a partial solution to the "what
version of win32lib are you using" problem. Firstly though, I have no
compulsion to make win32lib backward compatible at his stage. The library is
still being developed and MAJOR internal changes are still likely. I would
really rather wait for two things to happen first, (a) The library gets to
v1.0 release and (b) Euphoria supports namespaces.

Until we get to v1.0, the library will change in ways that can break code.
This is because it is "feeling" its way to a quality piece of work and is
not industrial strength yet. I would not like people to rely on win32lib for
serious ("money changing hands") type of applications yet. In my endeavours
to find shortcomings in the package, I am writing a potential commercial
application, and this process is helping me weed out quality and useability
problems. I expect that version 1.0 won't be available until February/March
2001. This is not set in stone and we can get a Win-Win (no pun intended)
solution.

The namespace issue is there because the library is huge and needs all the
help it can get to make it as maintainable as possible, without costing too
much to do so. With multiple namespaces, we can modularise the library
without causing integrity issues within itself or other 3rd party libraries.
Once it is more modular (along the lines that the IDE has gone, for example)
it will be easier to keep quality standards while performing maintenance or
enhancements. It should also be easier to distribute changes and enable
users more flexibility to use only parts of the library. These are longer
term goals and they depend very much on RDS enhancing Euphoria. If RDS can't
meet our timeline, we might have to find a sub-optimal workaround.

In the meantime, I will endeavour to maintain as much backward compatibility
as possible, but if existing code must be broken for the sake of a better
library, that is our preference for now. David, you might like to confirm
this or help me understand your thinking about this too.

Back to Ralf's suggestion. I had been thinking of something similar, but
rather than win32lib generating code, I thought that an IDE could call a
function to get infomation about the global routines and constants that
win32lib supports (a.k.a. metadata). Maybe along the lines of ....

    sequence funcInfo
    funcInfo = getFuncInfo("getSysColor", {w32FI_signature,
w32FI_description, w32FI_requirements})

    ?funcInfo --> { -- Signature info
                    {{{"atom", "SymbolicColorName"}}, -- parameters: type
and suggested name
                     {"atom"} -- return value type
                    },
                    -- Description
                    "Function that returns the RGB color value for a Windows
symbolc color name",
                    -- Requirements info
                    {{0,50,0}, -- Earliest win32lib version
                     {"Win95","WinNT3"} -- earliest Windows versions
                    }
                   }

this sort of info I'd keep in an EDS database that is generated by a tool
and distributed with the library.

If we do go this way, what metadata would you like about the routines and
constants?

On the documentation front, Travis Beaty is working hard to improve this. We
should see some fruits of his labour before too long.

-----
cheers,
Derek Parnell