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

[Robert M. <rm...@po...>]

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.

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
   use Win32::GUI::Constants qw( ...list of symbols... );

>> (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?
> 
> 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 ( '/^TPM_*/' );
> than
>         use Win32::GUI::Constants ( '/^TPM*/' );
> or
>         use Win32::GUI::Constants ( '/TPM*/' );

I think you mean to have '.*' on the end of each of these, although it 
is not necessary.

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

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

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:

^BTNS_
^TBSTATE_
^TBSTYLE_
^I_

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

> 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__*/

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?

Regards,
Rob.