[perl-win32-gui-hackers] Commit: Cygwin build error [Was: Beta release of 1.04 available for testing]
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] Commit ExtCreateRegion and GetRegionData
Robert May schrieb: Robert May wrote: Reini Urban wrote: why not Win32::GUI::Region-ExtCreateRegion() and Win32::GUI::Region-GetRegionData() ? Rgn != Region You're quite correct. I thought I was being consistent with all other region functions, but we should be being consistent with the Win32 API. I'll change it. Committed. Thanks -- Reini
Re: [perl-win32-gui-hackers] Commit ExtCreateRgn and GetRgnData function (Tracker: 1469648)
why not Win32::GUI::Region-ExtCreateRegion() and Win32::GUI::Region-GetRegionData() ? Rgn != Region 2006/6/24, Robert May [EMAIL PROTECTED]: I just committed 2 new functions for handling windows regions: New region method: my $data = $rgn-GetRgnData(); wraps the win32 API GetRegionData() function New region constructor: my $newrgn = Win32::GUI::Region-ExtCreateRgn($data); wraps the win32 API ExtCreateRegion() function Tracker 1469648: https://sourceforge.net/tracker/index.php?func=detailaid=1469648group_id=16572atid=366572 As a quick test I did the following: #!perl -w use strict; use warnings; use Win32::GUI(); my $mw = Win32::GUI::Window-new( -title = Region test, -size = [400,300], ); $mw-Show(); my $DC = $mw-GetDC(); my $rgn = Win32::GUI::Region-CreateRoundRectRgn(0,0,100,100,50,50); $DC-InvertRgn($rgn); my $rgndata = $rgn-GetRgnData(); my $newrgn = Win32::GUI::Region-ExtCreateRgn($rgndata); $newrgn-OffsetRgn(150,150); $DC-InvertRgn($newrgn); Win32::GUI::Dialog(); $mw-Hide(); exit(0); __END__ Regards, Rob. -- Reini Urban http://phpwiki.org/ http://murbreak.at/ http://spacemovie.mur.at/ http://helsinki.at/
Re: [perl-win32-gui-hackers] Commit ExtCreateRegion and GetRegionData
Robert May wrote: Reini Urban wrote: why not Win32::GUI::Region-ExtCreateRegion() and Win32::GUI::Region-GetRegionData() ? Rgn != Region You're quite correct. I thought I was being consistent with all other region functions, but we should be being consistent with the Win32 API. I'll change it. Committed. Rob.
Re: [perl-win32-gui-hackers] Commit: -wantreturn and $win-Animate()
I've added support for the Win32 AnimateWindow() API, as requested by tracker 1266930: https://sourceforge.net/tracker/index.php?func=detailaid=1266930group_id=16572atid=366572 Now, as well as $win-Show(), $win-Hide() you can use $win-Animate(). I had problems building under mingw - I had to set: #define WINVER 0x0501 in windef.h for it to build - after that, all tests pass, and the example runs (nice BTW!). Cheers, jez.
[perl-win32-gui-hackers] Commit ExtCreateRgn and GetRgnData function (Tracker: 1469648)
I just committed 2 new functions for handling windows regions: New region method: my $data = $rgn-GetRgnData(); wraps the win32 API GetRegionData() function New region constructor: my $newrgn = Win32::GUI::Region-ExtCreateRgn($data); wraps the win32 API ExtCreateRegion() function Tracker 1469648: https://sourceforge.net/tracker/index.php?func=detailaid=1469648group_id=16572atid=366572 As a quick test I did the following: #!perl -w use strict; use warnings; use Win32::GUI(); my $mw = Win32::GUI::Window-new( -title = Region test, -size = [400,300], ); $mw-Show(); my $DC = $mw-GetDC(); my $rgn = Win32::GUI::Region-CreateRoundRectRgn(0,0,100,100,50,50); $DC-InvertRgn($rgn); my $rgndata = $rgn-GetRgnData(); my $newrgn = Win32::GUI::Region-ExtCreateRgn($rgndata); $newrgn-OffsetRgn(150,150); $DC-InvertRgn($newrgn); Win32::GUI::Dialog(); $mw-Hide(); exit(0); __END__ Regards, Rob. -- Robert May Win32::GUI, a perl extension for native Win32 applications http://perl-win32-gui.sourceforge.net/
[perl-win32-gui-hackers] Commit - enhanced resource loading
Earlier this-evening I committed a change to they way the internal LoadImage() functions searches for Bitmaps, Icons and Cursors, prompted by a patch Reini Urban submitted to me. I've updated the docs for Win32::GUI::Icon-new to read: # (@)METHOD:new Win32::GUI::Icon(FILENAME) # Creates a new Icon object reading from FILENAME. # # If FILENAME is a string, then it is first tried as a resource # name, then a filename. If FILENAME is a number it is tried # as a resource identifier. # # Resources are searched for in the current exe (perl.exe unless # you have packed your application using perl2exe, PAR or similar), # then in the Win32::GUI GUI.dll, and finally as an OEM resource # identifier And similar wording for the bitmap and cursor constructors. The result is that now, as well as loading these object from files, you now have better access to embedded resources: for example: my $icon = Win32::GUI::Icon-new(IDI_DEFAULTCON); gives you the Win32::GUI camel icon my $icon = Win32::GUI::Icon-new(PERLEXE); gives you the ActiveState 'lizard' icon (assuming you're using AS perl) There's a new application in the samples directory that allows you to browse all the win32 built-in resources (standard icons, bitmaps and cursors), and Win32::GUI::Constants has been updated to include the required identifiers. Regards, Rop. -- Robert May Win32::GUI, a perl extension for native Win32 applications http://perl-win32-gui.sourceforge.net/
RE: [perl-win32-gui-hackers] Commit Win32::GUI::DropFiles
As always, any reports of success and/or failure are welcome. All ok under XP. Nice work. Cheers, jez.
[perl-win32-gui-hackers] Commit Frenzy
All, It's been a busy day on the commit front. Let me explain ... This morning Jeremy committed a set of patches that Reini Urban submitted to the users list. I then backed these changes out. I had a couple of motivations: (1) I wanted the commits in smaller chunks, to reflect the (fairly major) bits of functionality Reini had provided. There's a set of minor enhancements that I have already committed again, changes relating to shell DropDrop integration and changes related to Custom Draw support. (2) Some of what Reini has done overlaps with work I already had in progress, and I want a chance to get the 2 bits of work merged before committing. so, expect more activity over the next week or so. I'm working towards a V1.04 release, which needs the following completing: - completion and integration of my Win32::GUI::Constants work - integration of my thread-safe support work (Win32::GUI::ThreaUtils) - integration of Reini and my DragDrop support - integration of Reini's CustomDraw support Regards, Rob.
Re: [win32gui] RE: [perl-win32-gui-hackers] Commit
Jeremy White wrote: Just tested under ming, and I had the following errors: NotifyIcon.xs: In function `void XS_Win32__GUI__NotifyIcon__Add(PerlInterpreter* , CV*)': NotifyIcon.xs:27: error: `NOTIFYICONDATA_V1_SIZE' undeclared (first use this function) Thanks - I just committed an addition to GUI.h to rectify this. Builds and test fine under MinGW for me now. I changed: nid.cbSize = NOTIFYICONDATA_V1_SIZE; to: nid.cbSize = sizeof(NOTIFYICONDATA); and it compiled - I'm not sure what the implications would be of this change? It'd probably break if you run it on a system with shell.dll version less than 5, as that shell.dll is expecting cbSize to be NOTIFY_ICONDATA_V1_SIZE (88 bytes), whereas we are compiling with macros defined such that sizeof(NOTIFYICONDATA) is 488 bytes. What this code does is set cbSize to the smallest possible (all shell.dll versions should honour this), and then in GUI_Options.cpp I set it bigger if the shell.dll version allows it. The tests all pass, and your example works fine (nice example BTW!). Thanks. Rob.
[perl-win32-gui-hackers] Commit
I've just committed a couple of fixes: + [Robert May] : - Label.xs: Tracker 1164780: fix to -bitmap option for labels + Fixed test for icon/bitmap in Label_onPostCreate - Richedit.xs: + Minor documentation changes - docs/dohtml.pl: + change to CSS path for correct install location .../html/site/lib/Win32/GUI Regards, Rob.
[perl-win32-gui-hackers] Commit
+ Added SetWindowRgn method - DC.xs + Added CombineRgn method Cheers, jez.
[perl-win32-gui-hackers] Commit
+ [Jeremy White] : - GUI_Events.cpp: + Hooked events now report errors, also moved a strncmp function in ProcessEventError to be only performed when there is an error.
[perl-win32-gui-hackers] Commit
+ [Jeremy White] : - Combobox.xs: + Added CloseUp and DropDown events.
[perl-win32-gui-hackers] Commit
+ [Jeremy White Chris Wearn] : - ListView.xs + Added the BeginDrag event - GUI.xs + Added the ClientToScreen method + [Jeremy White] : - UpDown.xs, GUI.pm : + Fixed the crash when using the SetBuddy, Buddy and GetBuddy methods Improvements still needed. Cheers, jez.
[perl-win32-gui-hackers] Commit
Hi, I've just committed a minor bug fix for DoModal (the fix stops the flicker which sometimes occurred when the modal window returns). Cheers, jez.
[perl-win32-gui-hackers] COMMIT: [perl-win32-gui-users] Shipping resources with your exe
Goody Gumdrops. Just committed a change to CVS so that icons, bitmaps and cursors created in the standard way are first checked for in the EXE file that loaded Win32::GUI. Now there are some little points of note: 1. Doesnt work with PAR (unless you're a sneaky bugger). The reason it doesnt work with PAR is because PAR is just a self-extracting archive that auto-runs a perl interpreter on extraction. If you want to compile-in resources with PAR you'll need to add the resources to whatever interpreter executable it puts inside it's archive (looks like it's par.exe) rather than the exe file actually generated by PAR. 2. If I play around with perl2exe-generated executables in ResHacker, they either crash or fail to even start. This might be some sort of don't you hack me! protection inside the evaluation version of perl2exe, but it seems odd. 3. Not tried it with perlapp, I hope it works with this. 4. When adding resources with ResHacker, give the resource the same name as you passed for the filename of new Win32::GUI::Bitmap/Icon/Cursor. For instance, if you're doing new Win32::GUI::Bitmap(two.bmp) then your resource should have the name TWO.BMP. I had to test this by ResHackering my perl executable. Hopefully someone out there has shelled out for perl2exe full version or perlapp, and if that's the case then please test this on those two tools to see if it works. Feedback please. Steve -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jez White Sent: 19 February 2004 09:46 To: Steve Pick; Win32-GUI Subject: Re: [perl-win32-gui-users] Shipping resources with your exe I agree with your analysis - I especially like the idea of bitmaps, Icons and cursors to check for resources first, and then to look at the file system (would solve the problem of running in dev mode with the perl command line, or running the exe direct). How easy would it to be load other binary objects in from the exe? For example, having other image formats or storable created objects. As for adding resources - I can see the benefits of having a native solution, but it would create massive scope to mess around with the perl exe:) Perhaps the first step is to point to ResHacker, with a step by step guide on how to use it? jez. - Original Message - From: Steve Pick mailto:[EMAIL PROTECTED] To: Jez White mailto:[EMAIL PROTECTED] ; Win32-GUI mailto:[EMAIL PROTECTED] Sent: Wednesday, February 18, 2004 10:40 PM Subject: Re: [perl-win32-gui-users] Shipping resources with your exe I'd find this functionality kinda handy. Loading resources from the exe is very simple, and it would not be too difficult to extend the Win32::GUI::Bitmap, Icon, etc. objects to accept an additional argument that indicates that the resource should be loaded from the exe rather than from a real file on disk (in fact, it would actually be a trivial matter to do this). What is less trivial is getting the resources in there in the first place. While ResHacker lets you do it, it'd be nice to see a Win32::GUI native way of doing it. Microsoft provides functions for adding, deleting and replacing resources in executable files and I propose we either: 1. Add this update/add/delete functionality into Win32::GUI so that applications can fiddle with their own resources. This may be an exceptionally bad idea (what exe file will it think it's using when running straight from Perl? We dont want it messing with perl.exe's resources) 2. Create a small tool that is distributed with Win32::GUI to pack resources into the exe. I doubt we can re-dist ResHacker with win32::gui and it'd be nice if there was this functionality provided. The Win32::GUI::Bitmap, Icon and Cursor objects could then be modified to first check for a resource identified by the given filename in the current running exe, and if it's not found attempt to use the given filename to load an external file. This seems the best mode of operation to me. Steve - Original Message - From: Jez White mailto:[EMAIL PROTECTED] To: Win32-GUI mailto:[EMAIL PROTECTED] Sent: Wednesday, February 18, 2004 6:34 PM Subject: [perl-win32-gui-users] Shipping resources with your exe Hi, One the problems I have when I ship my exe is ensuring that all the resources (bitmaps, cursors and config files) are valid when my app starts up. Typically, just including them in a sub directory can cause problems since the user could delete or alter them. The ideal solution would be to package the resources into the exe and extract them at runtime. See: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/WinUI/WindowsUserInterface/Resources.asp Adding the resources to the exe is quite straightforward (with reshacker) but I'm not sure how easy it would be to implement these function calls (or even it is possible), would anyone find this kind of functionality useful? Cheers, jez.
