perl-win32-gui-hackers — Hacking and developing the Win32::GUI Perl extension

Re: [perl-win32-gui-hackers] [win32-gui] Grid enhancements

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

Arthur Schwarz wrote:
> */Robert May <rm...@po...>/* wrote:
>     Arthur Schwarz wrote:
>      > Would it be possible to expand the Grid implementation to include
>      > Cell tips and allow a multiselect option on List Boxes?
> 
>     From what I can see from the documentation and code, tips are already
>     supported for cells, where the information is too long to display in
>     the available space, using the EnableTitleTips() method.
>      
>         I was thinking more in terms of tooltips. The Title
>         Tips are not the same, as you have noted.

OK.  That wasn't what I was saying, I was mis-understanding what you 
were asking.  I now think (although you have not said so) that you want 
to put your own tips up, containing something other than the cell's 
contents (e.g. some helpful information about what should be in the 
cell?), when the mouse hovers over a cell.

It should be possible to use a standard tooltip for this, but due to the 
way that Win32::GUI::Grid has been implemented it does not use the 
standard Win32::GUI subclassing model, and so the right events do not 
get sent to the right places for this to work.  I'm afraid that I don't 
have the bandwidth to look at how to fix this right now.

>     The GVIT_LIST style is actually a ComboBox, and Comboboxes don't
>     support multiple selection - besides, if you could have multiple
 >     selection, how would you represent the multiple values in the cell
 >     once the selection was made?
>      
>       If I understand your question correctly, allowing
>       multiple selections can cause the grid cell to be
>       populated with multiple values, each value separated
>       by some mark, e.g., '|'.

The representation issue was really secondary to my original statement. 
  Combo boxes do not allow multiple selections.

> 
>     To do this you'd need to create a new class, subclassing one of the
>     GridCtlCell* classes to implement what you wanted - not something that
>     I'm likely to look at, but feel free to raise an RFC. If you can
>     persuade someone else to add this functionality to the underlying grid
>     control, then I'd e happ to have a go at integrating with the perl side
>     of things.
>      
>       If I knew what an RFC was ....

I did of course mean RFE (Request for enhancement) - you can find the 
page from the perl-win32-gui page at sourceforge under 'Feature Requests'.

>       On the other hand, and
>       if you don't mind, I'll try to look at the XS file
>       and give a hand at implementation.

By all means.  I think you'll be needing to look at the source of the 
underlying grid control (MFC Grid by Chris Maulder), as the XS is only a 
thin wrapper around that.

>       For my purposes
>       the (potential) editor is a 'toy' without this type
>       of capability. It requires that a 'casual' user have
>       too much knowledge before the editor can be used. My
>       own approach is to try to provide all needed inform-
>       ation when needed if known, rather that to require
>       that a user have a thorough understanding of Windows
>       or Perl. I suspect that just to move the project
>       along I will forgo this capability, and then
>       implement it at a later stage.

There's always the possibility of a different representation:  A double 
click on such a cell bring up a dialog that allows you to select the 
options - it'd give you much more room for manoever.  If, as I suspect, 
you're looking for a way for users to select style, then I would 
question whether a dropdown is sufficiently easy, even if you can find a 
way to enable multi-select, as you'll (possibly) be want to cope with 
check all the illegal combinations of styles?

Just my 2 cents.

Rob.

[perl-win32-gui-hackers] ANNOUNCE: Win32::GUI v1.04

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

I am please to announce that v1.04 of Win32::GUI is available for
download from SourceForge and CPAN.

Win32::GUI is a Perl extension allowing creation of native Win32 GUI
applications.

MORE INFORMATION

   Project Homepage:
   http://perl-win32-gui.sourceforge.net/

   Project summary:
   http://sourceforge.net/projects/perl-win32-gui/

   Downloads:
   - Source and ActiveState Perl PPM distributions:
     http://sourceforge.net/project/showfiles.php?group_id=16572
   - Source only:
     http://search.cpan.org/~robertmay/Win32-GUI-1.04/

   Release notes:
   https://sourceforge.net/project/shownotes.php?release_id=455710

RELEASE NOTES AND CHANGES

Win32::GUI::ReleaseNotes::RN_1_04 - release notes for Version 1.04 of 
Win32::GUI

Release Date
     15th October, 2006.

IMPORTANT INFORMATION
     This section details issues that are essential to understand when
     upgrading from earlier versions of Win32::GUI.

   Exported Constants
     The way that Win32::GUI exports constants has changed. Ensure that you
     read the "Deprecated feature status" section of this document so that
     you understand the backwards compatibility issues.

   Dual-life modules
     This version of Win32::GUI includes the modules
     Win32::GUI::AxWindow, Win32::GUI::DIBitmap, Win32::GUI::Grid,
     and Win32::GUI::Scintilla (originally by Laurent Rocher:
     <http://rocherl.club.fr/Win32GUI.html>).

     Please uninstall any previous versions of these modules that you may
     have installed before installing this version of Win32::GUI.

Summary of Changes
     This is a summary of changes between V1.03 and V1.04 See the
     CHANGELOG file in the distribution for the full detail.

   New Features
    New Packages
     Win32::GUI::AxWindow
     Win32::GUI::Constants
     Win32::GUI::DIBitmap
     Win32::GUI::DropFiles
     Win32::GUI::Grid
     Win32::GUI::Scintilla
     Win32::GUI::ReleaseNotes

    New Methods
     Win32::GUI
         Acceptfiles (Tracker: 1323988), Animate (Tracker: 1266930),
         ClassData, GetKeyState, SetWindowPos (Tracker: 1469648).

     Win32::GUI::Region
         ExtCreateRegion (Tracker: 1469648), GetRegionData.

     Win32::GUI::Tooltip
         AdjustRect, GetBubbleSize, SetTitle.

    New Events
     For all Windows
         DropFiles (Tracker: 1323988).

    New Documentation
     Win32::GUI::ListBox
         Better documentation for the differences between SetCurSel and
         SetSel (Tracker: 1177898).

     Win32::GUI::Textfield
         Correct documentation for -autohscroll and -autovscroll.

     Win32::GUI::Tooltip
         Complete documentation for the Win32::GUI::Tooltip class

    Other Features
     Better dialog navigation for Textfields
         <TAB> can now be used to move out of a multi-line Textfield when
         using the -dialogui option on a Window.

         A -wantreturn option has been added to stop the <RETURN> key firing
         the default Click event for a multi-line Textfield when using the
         -dialogui option on a Window. This replaces the previous use of
         "-addstyle => ES_WANTRETURN".

     Ballon tooltips for NotifyIcon
         The Win32::GUI::NotifyIcon pakage has been re-worked. There is
         now no need to use the -id option, and balloon tooltips are
         supported on Win2k and above. (Tracker: 1065072)

     More options for Win32::GUI::DoEvents()
         It is now possible to select which messages you want to process
         with DoEvents.

     More ways to create cursors, icons and bitmaps
         The Cursor, Icon and Bitmap constructors have been enhanced to
         allow creation from resources, including the "standard" windows
         resources. See the standard_images.pl sample to browse the
         standard resources.

     Easier way to browse and run the demos
         A new script win32-gui-demos will be installed in your perl bin
         directory. You should be able to get a full list of the sample
         code distributed with Win32::GUI, view the source and run the
         demos by typing "win32-gui-demos" at your command prompt.

     Better Splitter implementation
         The Win32::GUI::Splitter implementation has been re-written to
         provide more robust operation. The splitter bar can no longer be
         moved outside the parent window, which used to result in drawing
         problems, and the bar itself is now more nicely drawn.
         (Tracker:1363141)

         The -background option now works for splitter windows.

     Better behaviour from LoadLibrary
         The Win32::GUI::LoadLibrary() function has been enhanced so that
         it converts any passed path to a Win32 representation before
         trying to use it. Specifically this means that slashes are
         canonicised to '"\"', and under Cygwin, cygwin style paths are
         converted to Win32 paths.

     Complete re-work of Tooltip class
         The Win32::GUI::Tooltip implementation has been re-worked to
         allow all the features to be used, and now there should be no
         crashes with many of the methods which had been incorrectly
         implemented. The new implementaiton should be backwards
         compatible with what was there before, but read the
         documentation to find out about all the new features you can
         use.

         The constructor has some new options "-nofade", "-noamimate"
         and the "-balloon" option is documented. "-balloon" option along
         with the new SetTitle method allows you to make use of balloon
         tooltips.

         The events (NeedText, Pop, Show) now have a second parameter
         allowing you to correctly determine if the first parameter is a
         window handle or a tool id.

   Bug Fixes
    Reported Bugs
     Fix some crashes (Trackers 1243378 and 1248578)
     Fix some memory leaks (Tracker: 1201190)
     Fix drawing problems with coloured backgrounds (Tracker:1363141)

    Other Bugs
     -background and -forground options now work for RichEdit windows
     The SendMessageTimout implementation now matches the documentation
     -truncate option now works correctly for Label windows
     SetTabStops() method now works for ListBox windows
     The demo code all works
     Fix memory leak in Win32::GUI::DIBitmap::AlphaCopyToDC method

Deprecated feature status
     This section documents features that have been deprecated in this
     release, or in recent releases, and feature that will be deprecated
     in up-coming releases.

   Win32::GUI::Constants
     The introduction of Win32::GUI::Constants means that we now have
     access to a very large number of constants, so the current
     behaviour of Win32::GUI to export all constants to the calling
    namespace by default is no longer appropriate. So, a bare

       use Win32::GUI;

     now generates a warning that the old default behaviour will be
     deprecated - although the export behaviour of Win32::GUI 1.03 is
     maintained except for this warning.

     To eliminate this warning and correct your script, do one of the
     following:

     If you don't need any constants, use the empty list:
           use Win32::GUI();

     If you need some constants, name them explicitly:
           use Win32::GUI qw(ES_WANTRETURN CW_USEDEFAULT); # Two 
constants exported
           use Win32::GUI qw(/^MB_/);   # Export all constants starting 
with MB_

     See the Win32::GUI::Constants documentation for the full allowable
     syntax.

     You are advised to fix your scripts now, as the next version will
     stop exporting any constants by default.

     Although not advised, you can supress the warnings by turning
     deprecated warnings off:

       no warnings 'deprecated';

     Additionally accessing constants from within the Win32::GUI
     namespace is deprecated. I.e.

        -addstyle => Win32::GUI::WS_BORDER,

     will generate a warning with this release, and will stop working
     with the next release. Use one of the following methods instead:

     use the Win32::GUI::Constants namespace instead
           -addstyle => Win32::GUI::Constants::WS_BORDER(),

     use any other namespace you fancy
           use Win32::GUI qw(-exportpkg => A::B -autoload);
           ...
           -addstyle => A::B::WS_BORDER(),

     maintain compatibility of exising scripts
           use Win32::GUI::Constants qw(-exportpkg => Win32::GUI 
:compatability_win32_gui);
           ...
           -addstyle => Win32::GUI::WS_BORDER,

   Win32::GUI::NotifyIcon
     It is no longer necessary to use the '-id' option to any of the
     Win32::GUI::NotifyIcon methods. The ID is now entirely handled
     internally. You will receive deprecated warnings if you use it.

     In particular, removing Icons from the system tray should be done
     using

       $NI->Remove();

     and not by the (now deprecated)

       $NI->Delete(-id => 1);

   Removal of GUI:: namespace
     For at least the last 6 years the Win32::GUI namespace has been
     aliased to the GUI namespace for backwards compatibility with very
     early scripts. This aliasing has been removed, and any remaining
     scripts will need updating.

Contributors to this release
     Robert May
     Reini Urban
     Jeremy White


-- 
Robert May
Win32::GUI, a perl extension for native Win32 applications
http://perl-win32-gui.sourceforge.net/

Re: [perl-win32-gui-hackers] [win32-gui] Grid enhancements

[Arthur S. <asc...@ve...>]

Robert May <rm...@po...> wrote: 
    Arthur Schwarz wrote:
> Robert;
> 
> Would it be possible to expand the Grid implementation to include Cell 
> tips and allow a multiselect option on List Boxes?

Arthur,

>From what I can see from the documentation and code, tips are already 
supported for cells, where the information is too long to display in the 
available space, using the EnableTitleTips() method.
   
      I was thinking more in terms of tooltips. The Title 
      Tips are not the same, as you have noted.

The GVIT_LIST style is actually a ComboBox, and Comboboxes don't support 
multiple selection - besides, if you could have multiple selection, how 
would you represent the multiple values in the cell once the selection 
was made?
   
    If I understand your question correctly, allowing
    multiple selections can cause the grid cell to be 
    populated with multiple values, each value separated 
    by some mark, e.g., '|'. The user selects all entries
    needed and either the event handler or the under-
    lying software populates the cell with the
    selected values. Grid TitleTips are then available
    for displaying the values. Note that this
    implementation probably means that tooltips are not
    available for cells with combo boxes. The inverse
    operation (populating the multiselect list) is done
    by investigation of the grid cell or by an underlying
    hidden mechanism.
      This facilitates the ability to select, e.g., styles
    associated with a GUI object during editing by 
    presenting all legal values to a user rather than
    having a user searching memory for needed, e.g., 
    styles.
  

To do this you'd need to create a new class, subclassing one of the 
GridCtlCell* classes to implement what you wanted - not something that 
I'm likely to look at, but feel free to raise an RFC. If you can 
persuade someone else to add this functionality to the underlying grid 
control, then I'd e happ to have a go at integrating with the perl side 
of things.
   
    If I knew what an RFC was .... On the other hand, and
    if you don't mind, I'll try to look at the XS file
    and give a hand at implementation. For my purposes
    the (potential) editor is a 'toy' without this type
    of capability. It requires that a 'casual' user have
    too much knowledge before the editor can be used. My
    own approach is to try to provide all needed inform-
    ation when needed if known, rather that to require
    that a user have a thorough understanding of Windows
    or Perl. I suspect that just to move the project
    along I will forgo this capability, and then 
    implement it at a later stage.

Regards,
Rob.

  
 
  Thanks
   
  art

[perl-win32-gui-hackers] Grid Questions

[Arthur S. <asc...@ve...>]

I can't seem to get movement in my grid. After creation, I attempt to resize and position the poor dear. $Grid->Resize works just fine, but I can't seem to set the X and/or Y location. Any ideas?
   
  From Common Methods I've tried:
    AbsLeft    Wrong location
    Left          Wrong location
    Move        Both X and Y are incorrect
   
  I looked at the Grid documentation and haven't been able to locate a move for the entire table (VirtualMove?).
   
  This isn't a big one for me. The location set up in 'new' seems to be just fine. But ...
   
  art
   

[perl-win32-gui-hackers] Grid enhancements

[Arthur S. <asc...@ve...>]

Robert;
   
  Would it be possible to expand the Grid implementation to include Cell tips and allow a multiselect option on List Boxes?
   
  art

Re: [perl-win32-gui-hackers] [win32-gui] Re: GUI progress

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

Glenn Linderman wrote:

[snip]

> 
> This seems to be a bug in the deprecation code for 
> Win32::GUI::NotifyIcon. It's Delete method is deprecated, and because of 
> my program redirecting the warning to a log file, I didn't notice that 
> right away. However, the attempt to AUTOLOAD Win32::GUI::_Delete reveals 
> that the last line in this delete method is missing a "::NotifyIcon". 
> Comparison to the new DESTROY method immediately following shows that 
> the referenced _Delete method really should be in the NotifyIcon package.
> 
> As it stands, this is a pretty forceful sort of deprecation cycle!


Thanks.  Just in time to sneak the fix into the 1.04 release.  Nice catch.

Regards,
Rob.

Re: [perl-win32-gui-hackers] [win32-gui] building GUI

[Reini U. <ru...@x-...>]

Robert May schrieb:
> Glenn Linderman wrote:
>> So I installed MS VC++ 6.0, the MSDN of the same era, and the XP SP2 
>> Platform SDK and (comes with it I guess) MS Visual C++ Toolkit 2003.

>> uuid.lib(servprov_i.obj) : fatal error LNK1103: debugging information 
>> corrupt; recompile module.
> 
> Vague memories.  Some time ago Microsoft made a non backwards compatible 
> change to the debug info format, meaning that they don't work with VC6.

They changed their lib format, and lib /? would help.
There's a switch in lib.exe to accept old libs.

lib /LINK50COMPAT

The first google hit describes it quite well:
   http://www.cubic.org/player/doc/node69.htm

Re: [perl-win32-gui-hackers] [win32-gui] 1.04 release

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

Robert May wrote:
> I just committed the removal of the legacy Win32::GUI to GUI namespace 
> aliasing.
> 
> I intend to release the current CVS HEAD code as v1.04.  Can I get a 
> quick vote of yes/no as to whether you agree that we're ready for this?
> 
> Assuming no objections, then I plan to make this release the week after 
> next (as I'm away next week).

So can I take no responses as a 'yes' vote?

Rob.

Re: [perl-win32-gui-hackers] [win32-gui] building GUI

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

Glenn Linderman wrote:

[snip]

>> There are a number of ways around this.

[snip]

>> (3) {This is how I currently build Win32::GUI with VC6 and the Win2003 
>> Server SP1 PSDK):
>>   - set the INCLUDE environment variable to point to the following 
>> directories: 
>> PSDK\Include;PSDK\Include\mfc;VC98\ATL\INCLUDE;VC98\INCLUDE;VC98\MFC\INCLUDE
>> - set the LIB environment variable to point to the following directories:
>> VC98\LIB;VC98\MFC\LIB;PSDK\Lib
>>
>> where PSDK is the root of your PSDK install, and VC98 is the root of 
>> your VC6 install.  The search order is important.
> 
> My pre-rebuild script called the batch file that VC sets up, and then 
> then batch file that PSDK sets up, and the results used to work... but 
> then again maybe I was using an earlier PSDK.
> 
> The results of the script produced the INCLUDE in the form you mention, 
> but the LIB was different.  So I changed LIB in my script, and now it 
> seems that things built successfully.

It's almost certainly a bit hairy using the latest headers, and then 
linking against older *.lib files, but as you say, it seems to work. I 
would look seriously at using the VC2003 compiler rather than VC6, but I 
want to keep to a build environment that will run on win98.

> Thanks for your help.  I haven't contributed very much lately, either to 
> GUI or PAR, but I need to get back to those projects, and see if I can 
> get PAR working with ImageMagick again somehow.

I've seen your post to the perl.par list :-)

> Some interesting and 
> maybe helpful discussions over there that may result in a "cure"... one 
> a user-code cure that fakes out PAR, the other a modification to the 
> run-time startup code for the PAR-built application.  And then, maybe, I 
> can get back to more fun things, like using more features of GUI in my 
> applications, and contributing, and maybe even fixing, the occasional 
> bug report for GUI itself.

As you know, any and all help gratefully received.  If I can find the 
tuits I have a couple of ideas that I'd like to try and get implemented 
to contribute to PAR myself.

Regards,
Rob.

Re: [perl-win32-gui-hackers] [win32-gui] building GUI

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

Glenn Linderman wrote:
> So I installed MS VC++ 6.0, the MSDN of the same era, and the XP SP2 
> Platform SDK and (comes with it I guess) MS Visual C++ Toolkit 2003.
> 
> I reinstalled Tortoise CVS, checked out a new Win32-GUI directory, and 
> tried a compile.  It failed to compile AxWindow.dll, proclaiming that:
> 
> uuid.lib(servprov_i.obj) : fatal error LNK1103: debugging information 
> corrupt; recompile module.

Vague memories.  Some time ago Microsoft made a non backwards compatible 
change to the debug info format, meaning that they don't work with VC6.

There are a number of ways around this.

(1) Install old PSDK (Feb 200? was the last one MS claimed compatibility 
with VC6, sorry but I don't remember the exact year).

(2) Use the VC2003 compiler.  There are reports that this can cause 
problems, as it links with a different version of the C-runtime, but I 
have made it work by copying msvcrt.lib from my VC6 lib directory, and 
putting it in the VC2003 lib directory.

(3) {This is how I currently build Win32::GUI with VC6 and the Win2003 
Server SP1 PSDK):
  - set the INCLUDE environment variable to point to the following 
directories: 
PSDK\Include;PSDK\Include\mfc;VC98\ATL\INCLUDE;VC98\INCLUDE;VC98\MFC\INCLUDE
- set the LIB environment variable to point to the following directories:
VC98\LIB;VC98\MFC\LIB;PSDK\Lib

where PSDK is the root of your PSDK install, and VC98 is the root of 
your VC6 install.  The search order is important.

(4) I suspect that you could set the search order for libs to be PSDK 
then VC98, and delete/rename any .lib files that give problems from the 
PSDK Lib directory.

(5) (Possibly easiest, but I never tried this): edit the makefile 
(CFLAGS, LDFLAGS, LDDLFLAGS, OPTIMIZE) to remove the -debug and -Zi 
options (maybe others?), so that you are not requesting the debug 
information.

Regards,
Rob.

Re: [perl-win32-gui-hackers] [win32-gui] Re: Cygwin install of Win32-GUI-1.03_04/

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

Reini Urban wrote:
> The rest is the same as with every other perl package installation:
> 
>    cpan Win32::GUI

1.03_04 source is not on CPAN.  Latest there is 1.03.

Regards,
Rob.

Re: [perl-win32-gui-hackers] Cygwin install of Win32-GUI-1.03_04/

[Reini U. <ru...@x-...>]

Arthur Schwarz schrieb:
> I installed Win32-GUI-1.03_04/ into Activestate Perl using the installation
> procedures. No problem. However, there doesn't seem to be anything available to
> install Win32-GUI-1.03_04/ into a cygwin environment other than a direct copy
> from folder to folder. This would be OK but the folder architecture is
> different and I don't know how to handle the differences.
> 
> In particular:
> 
> No: Makefile.PL
> No: ./perl-Win32-GUI-X.XX-X.sh  (1.03_XX)
> 
> and when the downloaded zip file is expanded, 
> No: /usr/src/perl-Win32-GUI-X.XX-X.tar.bz2      (1.03_04)
>     /usr/src/perl-Win32-GUI-X.XX-X-src.tar.bz2  (1.03_04)
> 
> Just a lot of "no, no's". <sigh>.
> 
> So, with some Gloom and Doom, what did I misunderstand? 

??
Obviously your Win32-GUI-1.03_04 package is a shrink-wrapped version.

The standard cygwin package is installed via setup.exe, src also.
Building from this src is reproducible as with every other cygwin package.

The rest is the same as with every other perl package installation:

   cpan Win32::GUI

or download the sources and:
   perl Makefile.PL && make && make test install

Building from cvs is also ok. There's only the minor reported problem 
with the demos target:
   cp samples/* blib/lib/Win32/GUI/demos
   cp: omitting directory `samples/CVS'

> Oh, the advantage of Cygwin is that this is the environment in which I prefer
> to work because of shell scripting and etc. Being Really, Really old it may be
> impossible to retrain me to work in the DOS Shell environment, and just simply
> changing the PATH variable to reference c/Perl/bin before '/' seems just too
> easy. <sigh>. Don't get Really, Really, old and dogmatic.

[perl-win32-gui-hackers] 1.04 release

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

I just committed the removal of the legacy Win32::GUI to GUI namespace 
aliasing.

I intend to release the current CVS HEAD code as v1.04.  Can I get a 
quick vote of yes/no as to whether you agree that we're ready for this?

Assuming no objections, then I plan to make this release the week after 
next (as I'm away next week).

Regards,
Rob.
-- 
Robert May
Win32::GUI, a perl extension for native Win32 applications
http://perl-win32-gui.sourceforge.net/

Re: [perl-win32-gui-hackers] [win32-gui] Cygwin install of Win32-GUI-1.03_04/

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

Arthur Schwarz wrote:
> I installed Win32-GUI-1.03_04/ into Activestate Perl using the installation
> procedures. No problem. However, there doesn't seem to be anything available to
> install Win32-GUI-1.03_04/ into a cygwin environment other than a direct copy
> from folder to folder.

The PPM from my site is for ActiveState Perl 5.8 only.  A 
folder-to-folder copy won't give you the cygwin version.

> In particular:
> 
> No: Makefile.PL
> No: ./perl-Win32-GUI-X.XX-X.sh  (1.03_XX)
> 
> and when the downloaded zip file is expanded, 
> No: /usr/src/perl-Win32-GUI-X.XX-X.tar.bz2      (1.03_04)
>     /usr/src/perl-Win32-GUI-X.XX-X-src.tar.bz2  (1.03_04)
> 
> Just a lot of "no, no's". <sigh>.

Those are the instructions for installing using a 'cygwin setup' 
binary/src distribution that Reini Urbn builds for official releases, 
and downloadable using the cygwin 'Setup' program. As far as I am aware 
the latest version available by this mechanism is 1.03.

> So, with some Gloom and Doom, what did I misunderstand? 

If you want a cygwin build of 1.03_04, then you'll need to build from 
source.  The source is available from the project CVS repository at 
Sourceforge, and the pre-requsites and instructions are listed in the 
README file.

Alternatively, if you can wait another week or two, then I'll be making 
an official 1.04 release, and I'm sure that Reini will follow this with 
a cygwin binary distribution.

Regards,
Rob.

[perl-win32-gui-hackers] Cygwin install of Win32-GUI-1.03_04/

[Arthur S. <asc...@ve...>]

I installed Win32-GUI-1.03_04/ into Activestate Perl using the installation
procedures. No problem. However, there doesn't seem to be anything available to
install Win32-GUI-1.03_04/ into a cygwin environment other than a direct copy
from folder to folder. This would be OK but the folder architecture is
different and I don't know how to handle the differences.

In particular:

No: Makefile.PL
No: ./perl-Win32-GUI-X.XX-X.sh  (1.03_XX)

and when the downloaded zip file is expanded, 
No: /usr/src/perl-Win32-GUI-X.XX-X.tar.bz2      (1.03_04)
    /usr/src/perl-Win32-GUI-X.XX-X-src.tar.bz2  (1.03_04)

Just a lot of "no, no's". <sigh>.

So, with some Gloom and Doom, what did I misunderstand? 

art

Oh, the advantage of Cygwin is that this is the environment in which I prefer
to work because of shell scripting and etc. Being Really, Really old it may be
impossible to retrain me to work in the DOS Shell environment, and just simply
changing the PATH variable to reference c/Perl/bin before '/' seems just too
easy. <sigh>. Don't get Really, Really, old and dogmatic.

art

Re: [perl-win32-gui-hackers] [perl-win32-gui-users] Keyboard navigation for win32-gui-demos script [Was: Beta release of 1.04 available fortesting]

[Jamal M. <Jam...@fc...>]

I appreciate those changes, Rob!
Jamal
.



-----Original Message-----
From: per...@li...
[mailto:per...@li...] On Behalf Of
Robert May
Sent: Wednesday, August 30, 2006 6:05 PM
To: per...@li...
Cc: Jamal Mazrui; per...@li...
Subject: [perl-win32-gui-users] Keyboard navigation for win32-gui-demos
script [Was: Beta release of 1.04 available fortesting]


Robert May wrote:
> Jamal Mazrui wrote:
[snip]

>> The batch file to run examples worked.  Unfortunately though, the
>> program is difficult to access by a screen reader and keyboard user.
I
>> could not figure out how to move focus to the tree view with keyboard
>> commands.  After clicking on a tree view item with a mouse simulation
>> command of my screen reader program (a circuitous route), I then
could
>> not get to the Run Demo button via the keyboard after selecting an
item.
>=20
> OK, I've made a note to add basic keyboard navigation.

I've just committed basic 'TAB' navigation to the CVS repository. It'll=20
be in the 1.04 release.

Regards,
Rob.

------------------------------------------------------------------------
-
Using Tomcat but need to do more? Need to support web services,
security?
Get stuff done quickly with pre-integrated technology to make your job
easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache
Geronimo
http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D=
121642
_______________________________________________
Perl-Win32-GUI-Users mailing list
Per...@li...
https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
http://perl-win32-gui.sourceforge.net/

Re: [perl-win32-gui-hackers] [win32-gui] Re: Exporter fails with 'use Win32::GUI'

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

Reini Urban wrote:
> Robert May schrieb:
>> I've looked at it a number of times and would like to remove it, but I 
>> don't know it's history.  I assume it's there for historic backwards 
>> compatibility reasons, and that the package was originally just called 
>> 'GUI' rather than 'Win32::GUI' - this line would have kept old code 
>> running - but I haven't been around long enough to be sure there isn't 
>> anything else that depends on this.
>>
>> Does anyone know for sure?  Should we remove it?
> 
> Better sooner than later.
> 
> I was here at that times when when it was called GUI.
> Dada's old examples used it, but I saw no code using it anymore for years.

I'll give it another few days for anyone to object, otherwise I'll 
remove it.

Regards,
Rob.

Re: [perl-win32-gui-hackers] [Beta release of 1.04 available for testing

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

Reini Urban wrote:
>> Did I say to make sure you read the release notes?  They're online at
>> http://www.robmay.me.uk/win32gui/RELEASENOTES.TXT
> 
> Minor notpick:
> "See the Win32::GUI::COnstants documentation for the full allowable
> syntax."
> => Constants

Thanks - I just committed this correction.

Rob.

[perl-win32-gui-hackers] Keyboard navigation for win32-gui-demos script [Was: Beta release of 1.04 available fortesting]

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

Robert May wrote:
> Jamal Mazrui wrote:
[snip]

>> The batch file to run examples worked.  Unfortunately though, the
>> program is difficult to access by a screen reader and keyboard user.  I
>> could not figure out how to move focus to the tree view with keyboard
>> commands.  After clicking on a tree view item with a mouse simulation
>> command of my screen reader program (a circuitous route), I then could
>> not get to the Run Demo button via the keyboard after selecting an item.
> 
> OK, I've made a note to add basic keyboard navigation.

I've just committed basic 'TAB' navigation to the CVS repository. It'll 
be in the 1.04 release.

Regards,
Rob.

[perl-win32-gui-hackers] Commit: Cygwin build error [Was: Beta release of 1.04 available for testing]

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

Reini Urban wrote:
> cvs up -C under cygwin:
> 
> gcc -c   -DPERL_USE_SAFE_PUTENV -fno-strict-aliasing -pipe 
> -I/usr/local/include -DUSEIMPORTLIB -O3   -DVERSION=\"1.03_04
> \" -DXS_VERSION=\"1.03_04\"  "-I/usr/lib/perl5/5.8/cygwin/CORE"  -UWIN32 
> GUI_Helpers.cpp
> GUI_Helpers.cpp: In function `void 
> CalcControlSize(tagPERLWIN32GUI_CREATESTRUCT*, int, int)':
> GUI_Helpers.cpp:363: error: invalid conversion from `void*' to `HFONT__*'
> make: *** [GUI_Helpers.o] Error 1

Thanks.  I've added a cast to the offending line (along with some
casting fixes in tooltip.xs, and a fix for mingw headers missing a
TTM_SETTITLE definition in GUI.h), and it seems to compile and test OK
in my cygwin environment.

Regards,
Rob.

Re: [perl-win32-gui-hackers] [win32-gui] General Comments

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

Arthur Schwarz wrote:
> I've had a bad time getting restarted with Win32::GUI. In the vernacular, I've
> had 'unresolved issues'. To wit.
> 
> 1. It appears that filenames of 'GUI.pl' and folder names of
>    'GUI' cause fits, and

I don't think so.  I think it's just using package GUI and GUI::* that's 
an issue.

> 2. All Win32::GUI event names go into global namespace. This
>    appears to mean that the main program (<main>.pl> and any
>    module containing window creations with any events can not
>    have a package specified. That is, 'package <name>' and
>    'package <module>' won't work. (I think that I've seen this
>    documented somewhere).

We could really do with an expansion to the "Events" section of 
Win32::GUI::UserGuide::Concepts to introduce the NEM.  I don't see any 
documentation about the NEM anywhere.

Volunteers?

> And so, I wonder if this could be put into a prominent place, or maybe,
> prominent places, within the available documentation with specific guidelines
> as to legal Perl or Windows constructs which are not allowed. Something like:
> 
>   "DO NOT USE A MODULE NAME OF GUI.PL", and
>   "DO NOT USE A FOLDER NAME OF GUI", and
>   "DO NOT PUT A PACKAGE SPECIFICATION IN FILES CONTAINING
>    Win32::GUI REFERENCES", and
>   "DO NOT PUT A PACKAGE SPECIFICATION IN THE MAIN
>    PROGRAM"
> 
> Any way I can really help in this?

I'd say:

(1) When using OEM, event handlers must be in package main;
(2) Don't use package GUI or package GUI::*, as these are (currently) 
reserved by Win32::GUI -  although I'd prefer to remove the offending 
code from GUI.pm - see my other post.
(3) We need to document the NEM and how to use it. (see above)

Regards,
Rob.

[perl-win32-gui-hackers] NEM vs. OEM [Was: Visual GUI Editor]

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

Arthur Schwarz wrote:
> I do have a question. It's simple (for you) and bugging (me). How do I trap
> events in my code? Example:
> 
> Control.pl calls Control::Package.
> 
> All windows are created in Control::Package.
> 
> All event sub's are located in Control::Package.
> 
> In particular, 
>  my $TopMenu = new Win32::GUI::Menu(        # Main Window Menu
>        'File'                 => 'TopMenuFile',
>        '>&Open'               => 'TopMenuOpen',
>        '>&New'                => 'TopMenuNew',
>   );
> 
> and 'TopMenu*_Click' are located in Control::Package.

And won't be found.  If using the event model that calls subs by name 
('Original' event model - OEM), then the named subs must be in package 
main.  To do what you're trying to do here you must use the 'New' event 
model, or NEM.

> Win32::GUI::Dialog(); # is located in Control::Package.
> 
> But, clicking on a menu item isn't captured by the *_Click (or *_click) sub.
> 
> I know, I know. I shouldn't ask dumb questions, but???

(all code here untested)
package Control::Package;

my $TopMenu = Win32::GUI::Menu->new(
     'File'    => 'TopMenuFile',
     '>&Open   => { -name => 'TopMenuOpen', -onClick => \&Open },
     ....
);

sub Open {
   ...
};

Regards,
Rob.

Re: [perl-win32-gui-hackers] Exporter fails with 'use Win32::GUI'

[Reini U. <ru...@x-...>]

Robert May schrieb:
> I've looked at it a number of times and would like to remove it, but I 
> don't know it's history.  I assume it's there for historic backwards 
> compatibility reasons, and that the package was originally just called 
> 'GUI' rather than 'Win32::GUI' - this line would have kept old code 
> running - but I haven't been around long enough to be sure there isn't 
> anything else that depends on this.
> 
> Does anyone know for sure?  Should we remove it?

Better sooner than later.

I was here at that times when when it was called GUI.
Dada's old examples used it, but I saw no code using it anymore for years.

Re: [perl-win32-gui-hackers] Exporter fails with 'use Win32::GUI'

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

Arthur Schwarz wrote:
> I can't get the 'Exporter' to work when I 'use Win32::GUI'. Example code
> included below. Any fix? Anything I misunderstand?
> 
> Cygwin Perl v5.8.7
> Win32::GUI  Win32-GUI-1.03 (12 Apr 2006)
> 
> 
> art
> 
> # GUI.pl
> package GUI;

Don't use package GUI.  The following code appears near the top of GUI.pm:

   # Reserves GUI in the main namespace for us (uhmmm...)
   *GUI:: = \%Win32::GUI::;

That will effectively move anything you define in the package GUI into 
the package Win32::GUI - which already has it's own exporter, so I'm not 
surprised you're seeing problems.

I've looked at it a number of times and would like to remove it, but I 
don't know it's history.  I assume it's there for historic backwards 
compatibility reasons, and that the package was originally just called 
'GUI' rather than 'Win32::GUI' - this line would have kept old code 
running - but I haven't been around long enough to be sure there isn't 
anything else that depends on this.

Does anyone know for sure?  Should we remove it?

Regards,
-- 
Robert May
Win32::GUI, a perl extension for native Win32 applications
http://perl-win32-gui.sourceforge.net/

[perl-win32-gui-hackers] General Comments

[Arthur S. <asc...@ve...>]

k, ok, ok. I know that if you don't contribute you don't get a say. Well, I
intended to contribute but things just happened. And so I wonder:

I've had a bad time getting restarted with Win32::GUI. In the vernacular, I've
had 'unresolved issues'. To wit.

1. It appears that filenames of 'GUI.pl' and folder names of
   'GUI' cause fits, and
2. All Win32::GUI event names go into global namespace. This
   appears to mean that the main program (<main>.pl> and any
   module containing window creations with any events can not
   have a package specified. That is, 'package <name>' and
   'package <module>' won't work. (I think that I've seen this
   documented somewhere).

And so, I wonder if this could be put into a prominent place, or maybe,
prominent places, within the available documentation with specific guidelines
as to legal Perl or Windows constructs which are not allowed. Something like:

  "DO NOT USE A MODULE NAME OF GUI.PL", and
  "DO NOT USE A FOLDER NAME OF GUI", and
  "DO NOT PUT A PACKAGE SPECIFICATION IN FILES CONTAINING
   Win32::GUI REFERENCES", and
  "DO NOT PUT A PACKAGE SPECIFICATION IN THE MAIN
   PROGRAM"

Any way I can really help in this?

art