Re: [win32gui] Re: [perl-win32-gui-hackers] Missing SW_* constants

[Robert May]

Glenn Linderman wrote:

from the keyboard of Robert May:

Glenn Linderman wrote:

An alternate would be Win32::Constant

I think I'll stick with the Win32::GUI namespace for now. But I agree there is room for expanding the scope.

My current prototype has about 1500 constants (and I think that's about a third of them from the main header files), and weighs in at 32KB. I've not made much effort at compression yet, but do have it down from the 75kb that it was at this morning. It's nearly all constant names and values, there's less than 100 lines of code.

Find attached a second version (v0.00_02).  I've split it into 3 modules:

Win32::GUI::Constants - the main code

Win32::GUI::C - a helper package that sets up the hash with the constants, autogenerated during the build process from Constants.pl Win32::GUI::Tags - a helper package where we can define the :tag import symbols. This package only gets loaded if you use a :tag symbol, removing the size overhead, although the way I'm currently specifying the tags it may be that the overhead is not large.

(1) Are there too many pragma, and will anyone understand them?

(2) Does in intuitively do what you want? I.e. can you quickly and easily get access to the constants in a style that you like.

Looks like you've supported my preferences, as well as others.

  use Win32::GUI::Constants qw( ...list of symbols... );

Excellent. I guess my real question was do we think the default usage is easy enough for the average user? I don't see anything difficult or unexpected with

(3) What constants should be in the default set? I've put one in currently (CW_USEDEFAULT - which I find myself using in virtually every script I write).

One school of thought would probably claim that for backwards compatibility, all the constants currently defined in Win32::GUI should be in the default set... but actually, that should be Win32::GUI's responsibility to define and import that set (unless we choose to break backwards compatibility, which I wouldn't mind, and Jez probably wouldn't mind, given the size issue that results from all those constants--but if we do, we should document it loudly, and provide an easy way to include that original set of constants (or a slight superset)).

My intention is:
- Win32::GUI::Constants will export nothing by default.

- there will be a tag for the current set of symbols. Any suggestions for a name? - When we move Win32::GUI to use this, for the first release it will continue to export the current set of symbols, but will raise a 'deprecated' warning. Future releases will export nothing. Release notes will document the changes.

(4) What other groups of constants should we have?

        use Win32::GUI::Constants ( '/^TPM_*/' );
than
        use Win32::GUI::Constants ( '/^TPM*/' );
or
        use Win32::GUI::Constants ( '/TPM*/' );

Because of the regularity MS has used to name their groups of constants with fixed prefixes, the pattern matching may suffice. One should probably point out that it is better to

  use Win32::GUI::Constants qw( /^TPM_ );

is sufficient.  I've put something about this in the docs.



^BTNS_
^TBSTATE_
^TBSTYLE_
^I_

See Tags.pm for how I've done this specific example

I think you mean to have '.*' on the end of each of these, although it is not necessary. I think there is a need for some tags, as it's not always possible to do simple regexs for all the constants related to a topic. For example all toolbar related constants requires:

Do %C and %EXPORT_TAGS each need to be "our" for some reason, or would "my" work, to help hide them?

%EXPORT_TAGS no longer exists. %C has become $C (a hash ref now), and I have made it a my variable. It had been our, as I hadn't determined if it was needed by an inheriting module.

Constants.pm lines 149 and 150, and similar lines that would be needed to define any other tag classe, result in another (potentially) large array of names being generated. These particular lines at least share the ASCII names of the keys, but still have the overhead of a second array pointing at those names. This could possibly be avoided, by expanding the block at lines 65-67 to be larger, and contain module-specific explicit code for initializing @names for each particular :tagname supported. [Such couldn't be done in the more general Exporter.] This would even eliminate the need for %EXPORT_TAGS altogether... unless it just turns out to be the best way to define some of the tags. [Line 76 could be rewritten as keys(%C).]

Nice ideas - led me to the separate module approach, that only gets loaded if a :tag symbol is found.

Constants.pl could contain, or could read in, Constants.pm, and then emit the "minimum space constant list" directly at the end of the code, rather than requiring a manual paste.

Yes, that wasn't complete. Constants.pl now generates Win32::GUI::Constants::C module as a part of the build process.

In Constants.pm line 46 (at least, maybe also line 45) might should be moved to right after line 42, so that the sequence -exportpkg => -inline => 'Win32::GUI' isn't improperly interpreted vs -exportpkg => -autoload => 'Win32::GUI'

It had been my intention that the namespace had to immediately follow the -exportpkg pragma. I've moved the logic around to enforce this, and documented it. So -exportpkg => -autoload => 'Win32::GUI' is not legal, and would try to export to the '-autoload' namespace, except that 'Win32::GUI' is not a defined symbol, so will throw an error.

I guess because the module is named Win32::GUI::Constants rather than Win32::Constants, that it is not inappropriate to find within the module the constants that match /^WIN32__GUI__*/

Regards,
Rob.

These are there because they are in the current GUI_Constants.cpp, and we will need then in GUI.pm once that is removed. Perhaps they shouldn't be exportable?

Win32-GUI-Constants-0.00_02.tar.gz
Description: GNU Zip compressed data