Re: [perl-win32-gui-users] Hyperlink.pm [Was: Wrappers for listviews/comboboxes etc...]
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...]
[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...]
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.