From: Jez W. <je...@je...> - 2004-04-26 15:30:22
|
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. |
From: Jez W. <je...@je...> - 2004-05-25 10:00:18
|
Hi, I've just committed a couple of items: samples\BitmapScroll.pl The bitmap scroller, contains a fix for the bug reported by Glenn, as = well as his suggestions on making the event handlers more generic. GUI.xs Added LoadString Method Cheers, jez. |
From: Jez W. <je...@je...> - 2005-02-01 11:26:10
|
+ [Jeremy White & Chris Wearn] : - ListView.xs + Added the BeginDrag event - GUI.xs=20 + Added the ClientToScreen method=20 =20 + [Jeremy White] : - UpDown.xs, GUI.pm : + Fixed the crash when using the SetBuddy, Buddy and GetBuddy = methods Improvements still needed. Cheers, jez. |
From: Jez W. <je...@je...> - 2005-02-02 11:11:19
|
+ [Jeremy White] : - Combobox.xs: + Added CloseUp and DropDown events. |
From: Jez W. <je...@je...> - 2005-02-08 09:10:07
|
+ [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. |
From: Jez W. <je...@je...> - 2005-04-30 12:53:04
|
+ Added SetWindowRgn method - DC.xs=20 + Added CombineRgn method Cheers, jez. |
From: Robert M. <rm...@po...> - 2005-06-13 17:42:37
|
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. |
From: Jeremy W. <jez...@ho...> - 2005-08-06 10:56:51
|
Hi, I've just committed a change that added two new methods, GetParent and UserData - both of which can be called on controls or windows. GetParent simply returns the parent window of the control or child window (if there was one). UserData allows you to associate an SV to a control or window, allowing you to save instance data to that object. When used together, these methods should allow the creation of an window object that encapsulates all events, methods and instance data without the use of closures and other 'tricks'. I've created a test script for both of these functions but I am unsure of the naming scheme? I also assume that going forward we should be adding test scripts for any changes? I would be grateful for any comments/suggestions - and once this functionality has bedded down I'll add a couple of samples before the next release. In the meantime, the script below will show this functionality in action. Cheers, jez. ------------------- use strict; use warnings; use Win32::GUI; # Create the main window my $mainwindow = new Win32::GUI::Window( -name => "Window", -title => "Objects and Windows", -pos => [100,100], -size => [400,400], ); #We now create several employee selector 'controls'. my $search1=EmployeeSelector->new($mainwindow,20,20); my $search2=EmployeeSelector->new($mainwindow,20,50); my $search3=EmployeeSelector->new($mainwindow,20,80); my $search4=EmployeeSelector->new($mainwindow,20,110); my $search5=EmployeeSelector->new($mainwindow,20,140); #Show all our controls $search2->Move(200,200); # Child windows don't show until their parent shows, so by # showing the main window last we can create the child # windows with WS_VISIBLE, and not see them drawing $mainwindow->Show(); #Enter the message processing loop Win32::GUI::Dialog(); exit(0); # package to encapsulate the search window. # one static (class) function that diaplays the # search window and returns the selected item # or undef if ESC/Cancel preseed package SearchWindow; use strict; use warnings; use Win32::GUI; our $searchwindow; our $ok; # there has to be a better way to determine # which button was pressed perhaps buttons with -ok/-cancel # should exit the DoModal loop, returning some # well defined values? sub DoSearch { unless ($searchwindow) { # create it first time we're called # depending how much this gets called it's questionable # whether it's worth keeping it hanging around $searchwindow = Win32::GUI::DialogBox->new( -title => "Search for Employee", -size => [300,270], -onTerminate => sub { $ok = 0; return -1;}, ); $searchwindow->AddListView( -name => "ListView", -pos => [8,8], -size => [280,189], -singlesel => 1, -fullrowselect => 1, -tabstop => 1, ); $searchwindow->AddButton ( -text => 'OK', -pos => [164,208], -size => [60,21], -tabstop => 1, -default => 1, # draw button in 'default' style -ok => 1, # respond to 'return' key -onClick => sub{ $ok = 1; return -1;}, ); $searchwindow->AddButton ( -text => 'Cancel', -pos => [228,208], -size => [60,21], -tabstop => 1, -cancel => 1, # respond to ESC key -onClick => sub{ $ok = 0; return -1;}, ); #populate the list view $searchwindow->ListView->InsertColumn(-width => 55,-text => 'Emp ID'); $searchwindow->ListView->InsertColumn(-width => 205,-text => 'Employee Name'); $searchwindow->ListView->InsertItem(-text => [1234, 'Bob Smith']); $searchwindow->ListView->InsertItem(-text => [4321, 'Peter Jones']); $searchwindow->ListView->InsertItem(-text => [7890, 'John Brown']); } # show the search window and return the searched out value $searchwindow->Center(); $searchwindow->ListView->SetFocus(); $searchwindow->DoModal(1); return undef unless $ok; # pressed cancel or ESC (or X in titlebar) my $item=$searchwindow->ListView->SelectedItems(); return undef unless defined $item; # no selection (undef gets treated as zero by ItemInfo) my %hItem=$searchwindow->ListView->ItemInfo($item,0); return $hItem{-text}; } # I don't really understand why this end block is necessary to avoid warnings END { undef $searchwindow; } #package to encapsulate the 'Employee Selector' control # subclass of Window, so that I don't have to implement # Move()/Show() etc. package EmployeeSelector; use strict; use warnings; use Win32::GUI; use base qw(Win32::GUI::Window); #The constructor sub new { my ($class, $parent, $xcor, $ycor)=@_; #Create window my $self = $class->SUPER::new( -parent => $parent, -pos => [$xcor,$ycor], -size => [150, 24], -popstyle => WS_CAPTION | WS_SIZEBOX, -pushstyle => WS_CHILD | WS_CLIPCHILDREN | WS_VISIBLE, ); $self->UserData(0); #Create other controls $self->AddLabel( -text => 'ID#', -pos => [0,6], -size => [20,20], ); $self->AddTextfield( -name => "EMPID", -pos => [20,2], -size => [35,20], -tip => 'Employee ID', ); $self->AddButton ( -text => 'Search', -pos => [60,2], -size => [60,20], -tip => 'Search for a Employee ID', -onClick => sub{my $self=shift;Search($self->GetParent)}, ); #Set the user data for the window to be an empty string $self->UserData(''); return $self; } sub Search { my $self = shift; my $result = SearchWindow::DoSearch(); if ($result) { $self->SetEmpID($result); print 'Previous ID for this window was '.$self->UserData()."\n"; $self->UserData($result); } return 1; } sub SetEmpID { my $self=shift; $self->EMPID->Text(shift); } |
From: Robert M. <rm...@po...> - 2005-08-08 18:41:02
|
Jeremy White wrote: > I've just committed a change that added two new methods, GetParent and > UserData - both of which can be called on controls or windows. > > GetParent simply returns the parent window of the control or child > window (if there was one). Just one comment here - if the parent doesn't have valid userdata, should GetParent() return the hwnd, like most other calls do? Should we be looking at extending/changing other api calls to return objects, where such objects exist? > UserData allows you to associate an SV to a control or window, allowing > you to save instance data to that object. Nice. I hadn't thought of holding a separate reference to the userdata, and so avoiding the circular references. I think we may still see problems with the reference causing 'late destruction' in some cases, but I could be wrong (I still can't really get my head round the way objects are tied, resulting in more than one call to the classes DESTROY method). > I've created a test script for both of these functions but I am unsure > of the naming scheme? I also assume that going forward we should be > adding test scripts for any changes? It would be nice to have tests for everything we add, and we should certainly try going forward. There are some things I just don't know how to test yet. I'd like to encourage everyone to put tests into the test directory - I've not really got a naming scheme yet, but think something will become obvious once we see some more contributions. For methods, I started numbering at 50, with test names XX_Classname_Methodname.t, but don't know if this will hold up or not. Regards, Rob. |
From: Jeremy W. <jez...@ho...> - 2005-08-09 22:19:18
|
>Just one comment here - if the parent doesn't have valid userdata, should >GetParent() return the hwnd, like most other calls do? Should we be >looking at extending/changing other api calls to return objects, where such >objects exist? Both good questions and the honest answer is that I don't know:) Personally I prefer using objects, but if we have methods that could return either then it would mean that the user would have to test the return value before each use. >Nice. I hadn't thought of holding a separate reference to the userdata, >and so avoiding the circular references. I think we may still see problems >with the reference causing 'late destruction' in some cases, but I could be >wrong (I still can't really get my head round the way objects are tied, >resulting in more than one call to the classes DESTROY method). It does need more testing, and no doubt issues will crop up. In theory you should be able to create a sell referencing window, which has no global reference, with the window controlling when it's destroyed. Something like this: {#window constructor my $win=create window; #the window is stored within itself, and the ref count is increased and wont be destroyed when #the block is finished $win->UserData($win); } onTerminateHandler { my $self=shift; #Setting the userdata to a blank string causes the ref count to be dropped on the window #and therefore should kick in the destruction logic $self->UserData(''); } >It would be nice to have tests for everything we add, and we should >certainly try going forward. There are some things I just don't know how >to test yet. I'd like to encourage everyone to put tests into the test >directory - I've not really got a naming scheme yet, but think something >will become obvious once we see some more contributions. For methods, I >started numbering at 50, with test names XX_Classname_Methodname.t, but >don't know if this will hold up or not. Ok - I'll add these scripts later. Does anyone know a way to test for memory leaks? Cheers, jez. |
From: Robert M. <rm...@po...> - 2005-08-09 18:23:32
|
Jeremy White wrote: >> Just one comment here - if the parent doesn't have valid userdata, >> should GetParent() return the hwnd, like most other calls do? Should >> we be looking at extending/changing other api calls to return objects, >> where such objects exist? > Both good questions and the honest answer is that I don't know:) > Personally I prefer using objects, but if we have methods that could > return either then it would mean that the user would have to test the > return value before each use. I think that's good logic to use to say that a method should return either object/undef or handle/undef, but never object/handle/undef. > In theory > you should be able to create a sell referencing window, which has no > global reference, with the window controlling when it's destroyed. > Something like this: > > {#window constructor > my $win=create window; > #the window is stored within itself, and the ref count is increased and > wont be destroyed when > #the block is finished > $win->UserData($win); > } > > onTerminateHandler > { > my $self=shift; > #Setting the userdata to a blank string causes the ref count to be > dropped on the window > #and therefore should kick in the destruction logic > $self->UserData(''); > } Have you tried this? It's sort of equivalent to } my $mw; $mw = Win32::GUI::Window->new( ... -onTerminate => sub { undef $mw }, ); } Which uses a closure to stop $mw's ref count going to zero at the end of the enclosing block, but forces it to zero in the onTerminate handler. > Ok - I'll add these scripts later. Does anyone know a way to test for > memory leaks? No idea how to test for memory leaks - it's such a hard problem that there's a whole industry around making tools to do just that. You'll find developer CVS is down for anything up to the next 36 hours for maintenance. Regards, Rob. |
From: Jeremy W. <jez...@ho...> - 2005-08-10 09:12:25
|
>Have you tried this? It's sort of equivalent to > >} > my $mw; > $mw = Win32::GUI::Window->new( > ... > -onTerminate => sub { undef $mw }, > ); >} > >Which uses a closure to stop $mw's ref count going to zero at the end of >the enclosing block, but forces it to zero in the onTerminate handler. Humm - I've just had a bit of a play, and I am not convinced the window destruction logic is correct. Under the hood a window is both an object and a tied hash ref right? Could it be the case that we're destroying one and not the other? Anyways, have a play with the example below. Cheers, jez. ----------------- use strict; use warnings; use Win32::GUI; # Create the main window my $mainwindow = new Win32::GUI::Window( -name => "Window", -title => "Objects and Windows", -pos => [100,100], -size => [400,400], ); #We now create several employee windows EmployeeSelector->new($mainwindow,20,20); EmployeeSelector->new($mainwindow,20,50); EmployeeSelector->new($mainwindow,20,80); EmployeeSelector->new($mainwindow,20,110); EmployeeSelector->new($mainwindow,20,140); $mainwindow->Show(); #Enter the message processing loop Win32::GUI::Dialog(); exit(0); package EmployeeSelector; use strict; use warnings; use Win32::GUI; use base qw(Win32::GUI::Window); #The constructor sub new { my ($class, $parent, $xcor, $ycor)=@_; #Create window my $self = $class->SUPER::new( #my $self = new Win32::GUI::Window( #-parent => $parent, -pos => [$xcor,$ycor], -size => [150, 60], #-onTerminate => sub {return 1}, #When we terminate, the ref counter of the UserData is dropped, which should kick off the destruction -onTerminate => sub {my $self=shift;print "in terminate self is $self\n"}, ); $self->AddButton ( -text => 'Click Me!', -pos => [60,2], -size => [60,20], -onClick => sub {print 'Button Clicked';}, ); print "Created $self\n"; $self->Show(); #Save the window in the window user data, once the sub finishes, there is no reference to the #window other than itself. The destiny of the window is in it's own hands. $self->UserData($self); } sub DESTROY { my $self=shift; print "In destroy $self \n"; $self->SUPER::DESTROY(); } |
From: Robert M. <rm...@po...> - 2005-08-10 22:24:03
|
Jeremy White wrote: >> Have you tried this? It's sort of equivalent to >> >> } >> my $mw; >> $mw = Win32::GUI::Window->new( >> ... >> -onTerminate => sub { undef $mw }, >> ); >> } >> >> Which uses a closure to stop $mw's ref count going to zero at the end >> of the enclosing block, but forces it to zero in the onTerminate handler. > > > Humm - I've just had a bit of a play, and I am not convinced the window > destruction logic is correct. Under the hood a window is both an object > and a tied hash ref right? Could it be the case that we're destroying > one and not the other? Ah. I've come across this problem too when trying to add my own DESTROY method to a subclass of a Win32::GUI window/control object. There's definitely some nastiness lurking in the way that the object is tied to Win32::GUI::WindowProps. I couldn't quite get my head round it when I last looked there, but the DESTROY method gets called twice, with different objects (try print $self; within the DESTROY method). I *think* there are actually 2 perl objects created for each window; but as I said I never got to the bottom of the logic to my satisfaction. When I last looked at this I thought that the best solution would be to remove the tied mechanism altogether - there's not much functionality added; besides we should not be encouraging people to access the object hashes directly - it's not very 00. But I haven't found the time to look at exactly how much functionality would be lost, and how hard it would be to add that functionality back using a more traditional approach (if indeed it is possible at all). Rob. |
From: Jeremy W. <jez...@ho...> - 2005-08-11 09:33:44
|
>When I last looked at this I thought that the best solution would be to >remove the tied mechanism altogether - there's not much functionality >added; besides we should not be encouraging people to access the object >hashes directly - it's not very 00. But I haven't found the time to look >at exactly how much functionality would be lost, and how hard it would be >to add that functionality back using a more traditional approach (if indeed >it is possible at all). If it turns out that the source of the various crashes is the tied mechanism, and it can't be fixed across all perl versions (which could be the case), then we should remove it. I agree, providing the hash is questionable. If we remove it, we will break code. One way to limit the 'pain' could be to provide a method that returns the hash, which can then be accessed (this would also be quicker than using tie). Other than adding items to the hash, I can't think of a reason why you would need to use hash access (ok, to return items from the hash - but these should be methods if they don't exits). Cheers, jez. |
From: Robert M. <rm...@po...> - 2005-08-25 19:41:46
|
I just committed a couple of fixes: - Tracker: 1273134 - fixed tooltip creation styles (see discussion on users list) - Added Win32::GUI::StretchBlt - Fix to Win32::GUI::DC::new with no parameter to return an object, rather than a handle Regards, Rob. |
From: Robert M. <rm...@po...> - 2005-10-02 22:15:42
|
I just committed a couple of small changes: - GUI.h added GET_X_LPARAM and GET_Y_LPARAM macros (from windowsX.h) - GUI_MessageLoops.cpp change WM_MOUSEMOVE handler to use GET_X_LPARAM and GET_Y_LPARAM rather than HIWORD and LOWORD (Tracker: 1262098) - GUI.xs fixed UnHook() to resolve perl 5.6/5.8 differences in av_delete, causing a warning in perl 5.8 (Tracker: 1164766) I may revisit the fix to UnHook() depending on responses to my earlier post on support for perl versions prior to 5.6. I haven't tried building under mingw yet, but they seem fine with VC++. I am also going to look at creating a new mailing list (send only), whose sole purpose will be to send out messages automatically when a commit is made. Regards, Rob. |
From: Jeremy W. <jez...@ho...> - 2005-10-03 09:11:55
|
Hi, Had a problem with Imagelist.xs on Mingw - a couple of #ifdef __MINGW__ should be #ifdef __MINGW32__ Cheers, jez. |
From: Robert M. <rm...@po...> - 2005-10-03 19:49:11
|
Jeremy White wrote: > Had a problem with Imagelist.xs on Mingw - a couple of #ifdef __MINGW__ > should be #ifdef __MINGW32__ OK - I corrected this and committed. I think we need a better way of testing for these functions, as they are present in my MinGW headers, and I was compiling fine :-) Any suggestions? Rob. |
From: Robert M. <rm...@po...> - 2005-10-05 18:22:41
|
Robert May wrote: > Jeremy White wrote: > >> Had a problem with Imagelist.xs on Mingw - a couple of #ifdef >> __MINGW__ should be #ifdef __MINGW32__ > > OK - I corrected this and committed. I think we need a better way of > testing for these functions, as they are present in my MinGW headers, > and I was compiling fine :-) > > Any suggestions? I've investigated this further. These functions are supported correctly in MinGW's w32api package V3.2 and onwards. This issue also applies to cygwin (which distributes the same w32api package) The w32api package version is available in the w32api.h file, so I'm code up a change that: - only excludes the functions if the w32api version is not high enough. - copes with MinGW and Cygwin - spews a warning if you use these functions and they are not available. Regards, Rob. |
From: Robert M. <rm...@po...> - 2005-10-05 22:32:28
|
Hi all, I've just committed a fairly significant set of changes. Mostly bug fixes and documentation updates. I would appreciate confirmation that it still compiles in everyone's environment, and comments on the updated tutorial and samples to go with it. - Makefile.PL added 'demos' target as dependency for 'all', so that samples get included in ActiveState PPM I've noticed that the demos directory was not getting added to the ppm distributions created by others. This change should make that happen. - GUI_Constants.cpp: correct TMP_NONOTIFY to TPM_NONOTIFY (aschwarz1309) - GUI.pm, RichEdit.xs: added documentation for SetEventMask method (Tracker: 1242808) - GUI.pm upped version to 1.02_02 - GUI.h, ImageList.xs allowed missing ImageList_* functions to be compiled in under MinGW and Cygwin, if w32api package has high enough version Jez, I'd be particularly interested to know that this compiles for you, where you have a pre-3.2 w32api package from MinGW Reini, if you watching, then confirmation that we still build under Cgywin would be great. - GUI.xs: Changed DoModal's use of GetParent to GetWindow(hwnd, GW_OWNER). See http://support.microsoft.com/default.aspx?scid=kb;en-us;84190 for more information (Tracker: 1165626) See my separate email on this one - Updated all the Tutorial documentation and added tutorial examples to the samples directory Regards, Rob. |
From: Jeremy W. <jez...@ho...> - 2005-10-06 07:58:23
|
>- GUI.h, ImageList.xs allowed missing ImageList_* functions to be > compiled in under MinGW and Cygwin, if w32api package has high > enough version > >Jez, I'd be particularly interested to know that this compiles for you, >where you have a pre-3.2 w32api package from MinGW Doing a normal mingw build I get the following errors: ImageList.o(.text+0xd2a):ImageList.cpp: undefined reference to `ImageList_Copy@2 0' ImageList.o(.text+0x21c4):ImageList.cpp: undefined reference to `ImageList_DrawI ndirect@4' ImageList.o(.text+0x25e9):ImageList.cpp: undefined reference to `_Z19ImageList_D uplicateP10_IMAGELIST@4' NMAKE : fatal error U1077: 'C:\WINDOWS\system32\cmd.exe' : return code '0x1' Stop. Playing around, I have the following (in w32api.h): #define __W32API_VERSION 2.5 #define __W32API_MAJOR_VERSION 2 #define __W32API_MINOR_VERSION 5 If I then change the logic in GUI.h to include these version numbers things compile fine. Cheers, jez. |
From: Jeremy W. <jez...@ho...> - 2005-12-03 10:58:48
|
Hi, I've just committed a change to the typemap. It now uses one hash lookup, rather than two, and as a result is faster. As this typemap is used for almost all objects and method calls, there might be some gains for some calls (depending on what the method actually does). The benchmark below is for a dummy method that doesn't do anything: Benchmark: timing 1000000 iterations of NewTypeMap, OldTypeMap... NewTypeMap: 29 wallclock secs (29.64 usr + 0.06 sys = 29.70 CPU) @ 33666.63/s ( n=1000000) OldTypeMap: 38 wallclock secs (38.22 usr + 0.02 sys = 38.23 CPU) @ 26154.05/s (n=1000000) I've tested this change under mingw and vc, and it seems to work fine. If there are any issues, drop me a mail. Cheers, jez. |
From: Robert M. <rm...@po...> - 2006-01-11 21:52:29
|
Hi all, I've just committed my Christmas set of changes. There's quite a bit here: - Label.xs correct -truncate option processing, as SS_.*ELLIPSIS.* styles are not single bits Using the Win32::GUI::Label -truncate option was broken - fixed it. Note that this option can only be used with WinNT and higher (i.e. it is ignored by Win98). - NotifyIcon.xs, GUI_Options.cpp, GUI.pm re-work NofifyIcon class. Add balloon tooltips. Add support for message behaviour. Add support for setfocus. Add documentation. (Tracker: 1065072) - t\05_NotifyIcon*.t, MANIFEST Notify Icon Tests added - samples\NotifyIcon.pl, MANIFEST add demo app Re-worked the NotifyIcon class, added Balloon tips (for Shell.dll version 5 and higher only - IIRC that's Win2K and higher only). Deprecated (with warning) nasty old way of calling Delete(-id => ... ) to remove an icon; deprecated need to set -id option in constructor; Added documentation, sample and tests New options -ballooon_tip, -balloon_title, -balloon_icon and -balloon_timeout; New methods ShowBalloon(), HideBalloon(), SetFocus(), SetBehaviour(); See documentation for details. - GUI.pm Changed initial value of $Win32::GUI::MenuIdCounter to avoid ID clash with predefined WM_COMMAND values (IDOK, IDCANCEL, etc.) Discovered that a Window with -dialogui => 1 and no default button fired the first menu item when ENTER pressed. Fixed. - GUI.xs Fix SendMessageTimeout to match documentation and return undef on failure. (XSRETURN_UNDEF rather than XSRETURN_NO). - GUI.pm corrected documentation of default values for autohscroll and autovscroll in Textfield documentation - GUI_MessageLoops.cpp added processing of WM_NEXTDLGCTL to CommonMessageLoop to allow for tabbing out of multiline Textfields when using -dialogui - GUI_MessageLoops.cpp fixed WM_ERASEBKGND (Tracker:1363141) WM_ERASEBKGND was not doing its stuff when called from BeginPaint by DefWindowProc, and we had a -background option. This due to BeginPaint Validating the update region before calling WM_ERASEBKGND - Splitter.xs, GUI_Helpers.cpp, GUI.h re-worked splitter class. (Tracker:1363141) Re-wrote the splitter class, in an attempt to fix the problems reported in Tracker 133141 (drawing problems). Fixed several potential problems (related to losing mouse capture without getting a mouse-up), but not this one. It looks like it is a RichEdit re-draw problem, and nothing to do with the splitter class. I'll deal with this in a seperate mail. - RichEdit.xs made -background and -foreground work - GUI_MessageLoops.cpp made -background work for Splitter windows - GUI_Helpers.cpp removed an unnecessary dTHX, replacing it with PERLUD_FETCH - Upped version to 1.03_02 As my NotifyIcon.pl sample has a dependancy on these code changes, allowing use Win32::GUI 1.03_02; Compiles and tests OK on Win98, VC++ 6. I haven't tried MinGW or Cygwin environments. The NotifyIcon changes have been tried on Win2K, but I haven't run the new NotifyIcon tests there. Regards, Rob. Regard |
From: Jeremy W. <jez...@ho...> - 2006-01-12 09:58:44
|
>I've just committed my Christmas set of changes. There's quite a bit here: Nice changes:) 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 fun ction) NotifyIcon.xs:27: error: (Each undeclared identifier is reported only once for e ach function it appears in.) NotifyIcon.xs: In function `void XS_Win32__GUI__NotifyIcon__Modify(PerlInterpret er*, CV*)': NotifyIcon.xs:50: error: `NOTIFYICONDATA_V1_SIZE' undeclared (first use this fun ction) NotifyIcon.xs: In function `void XS_Win32__GUI__NotifyIcon__Delete(PerlInterpret er*, CV*)': NotifyIcon.xs:70: error: `NOTIFYICONDATA_V1_SIZE' undeclared (first use this fun ction) NotifyIcon.xs: In function `void XS_Win32__GUI__NotifyIcon__SetFocus(PerlInterpr eter*, CV*)': NotifyIcon.xs:88: error: `NOTIFYICONDATA_V1_SIZE' undeclared (first use this fun ction) NotifyIcon.xs: In function `void XS_Win32__GUI__NotifyIcon__SetVersion(PerlInter preter*, CV*)': NotifyIcon.xs:106: error: `NOTIFYICONDATA_V1_SIZE' undeclared (first use this fu nction) NMAKE : fatal error U1077: 'C:\WINDOWS\system32\cmd.exe' : return code '0x1' Stop. Looking at: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/shell/reference/structures/notifyicondata.asp 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? The tests all pass, and your example works fine (nice example BTW!). Cheers, jez. |
From: Robert M. <rm...@po...> - 2006-01-12 22:26:22
|
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. |