Re: [perl-win32-gui-users] Hyperlink.pm [Was: Wrappers for listviews/comboboxes etc...]

2005-02-17 Thread Jez White
Quoting Glenn Linderman [EMAIL PROTECTED]:

 On approximately 2/16/2005 1:43 PM, came the
 following characters from 
 the keyboard of Robert May:
  
  Glenn Linderman wrote:
  
 
  Would it not be possible to just use
 
 system qq{start whatever_command};
 
  instead of ShellExecute?  What is the
 advantage of ShellExecute?
  
  
  That seems to work fine on my Win98 system. 
 It takes a bit longer to 
  return control to the GUI (but only just
 noticable), and the return 
  values are less well defined (I can't find any
 info in the quick search 

 And are you launching the default browser?  Or
 the .html file via an 
 assumed association?  Or???  The syntax for
 launching the default 
 browser can be tricky to get right for all
 browsers, although it is 
 possible.  Anyway, you should test on at least a
 couple non-IE browsers 
 too, for completeness.

I've added ShellExecute directly to Win32::GUI - it 
has several advantages over using the perl system 
command. It is much more flexible and powerful in 
terms win32 functionality - it is also much faster (in 
returning to the calling script). It also has the 
benefit (in this example) that it is browser 
independent - it uses the registry to determine the 
which browser to use.

Cheers,

jez.



[perl-win32-gui-users] Hyperlink.pm [Was: Wrappers for listviews/comboboxes etc...]

2005-02-16 Thread Robert May

[EMAIL PROTECTED] wrote:


Quoting Robert May [EMAIL PROTECTED]:

[snip]


I though this might be a good moment to introduce
HyperLink.pm - a sub-classing of Win32::GUI::Label that acts as a
clickable hyperlink:
   


This is a great start - a nice object.


Thanks.

Although I had 
a problem with the constants (I'm on5.6) and got the 
following error:


D:\Developmentperl HyperLinkDemo.pl
Constant name 'HASH(0x1a4306c)' has invalid characters 
at HyperLink.pm line 88
BEGIN failed--compilation aborted at HyperLink.pm line 
91.
Compilation failed in require at HyperLinkDemo.pl line 
15.
BEGIN failed--compilation aborted at HyperLinkDemo.pl 
line 15.


Once fixed, it worked great.
 

Can you let me have the fix so that I can put it back in the source.  Im 
on 5.8.6 and don't have any other environment to test at the moment.


As a suggestion, it would be a good idea to get rid of 
the dependency on Win32::API - SetCapture and 
ReleaseCapture are already in Win32::GUI. If you are 
keen on this idea, I'll add GetCapture, LoadCursor 
into GUI.xs. The issue would then be ShellExecute - 
perhaps that should be added too?
 

I'd love to get rid of the Win32::API dependency - you'll see it listed 
as one of the TODO items in the comments at the start of Hyperlink.pm.  
I had missed that SetCapture and ReleaseCapture were already there - I 
guess I searched the source for GetCapture, and didn't find that.  It'd 
be great if you could add GetCapture - should I raise a tracker?
LoadCursor() is superseded (according to microsoft) by LoadImage but the 
API to LoadCursor is much more straightforward ... I did try using the 
existing Win32::GUI::LoadImage API, but never made it work (it's really 
only designed to get an image from a file.  If we could modify the 
Win32::GUI::Cursor package to be able to do something like 
LoadImage(IDC_HAND,IMAGE_CURSOR, 0,0,LR_DEFAULT_SIZE) I think that would 
be better.  It would be great if we could apply the same change to 
Win32::GUI::Icon to allow us access to default Icon resources too.  Am I 
making any sense?


Adding ShellExecute (or ShellExecuteEx) is a bit more tenuous, but it 
does take a window handle as it's first parameter, so perhaps we can 
justify it?


Rob.



[perl-win32-gui-users] Hyperlink.pm [Was: Wrappers for listviews/comboboxes etc...]

2005-02-16 Thread Robert May

Glenn Linderman wrote:



Would it not be possible to just use

   system qq{start whatever_command};

instead of ShellExecute?  What is the advantage of ShellExecute?


That seems to work fine on my Win98 system.  It takes a bit longer to 
return control to the GUI (but only just noticable), and the return 
values are less well defined (I can't find any info in the quick search 
I've done).  I'll put that in, and remove the dependancy on 
ShellExecute, unless anyone know why ShellExecute might be preferable.


I've only tried this on W98 - does the fact that start in w2k onwards is 
implelented as a shell builtin command cause any problems?   The only 
other problem I can think of is if the user has any other program called 
start.exe/bat/etc. in their path in front of the windows one.


Thanks Glenn.

Rob.