Hi,
I've created the following tracker item for this issue:
http://sourceforge.net/tracker/index.php?func=detail&aid=1941264&group_id=16572&atid=116572
I think the solution is straightforward but don't want to commit the code yet.
As a side, I use the Win32::GUI::Coolbar module from Robs homep
Hi,
I've spent some more time on this. I've created a bug report on sourceforge so
this isn't lost:
http://sourceforge.net/tracker/index.php?func=detail&aid=1941241&group_id=16572&atid=116572
Ok - it's not a hook issue, it looks like its just the normal destruction
process which seems differe
Ok:
Found a simple way to reproduce the error:
Can't call method "STORE" on an undefined value during global destruction.
It doesn't seem related to the crash. The stripped down example below is odd as
most of the code doesn't make sense (!) but if you comment out any of the lines
it doesn
All,
I am getting a crash when using Perl 5.10 and Win32::GUI 1.6. The same
application doesn't crash under 5.8.7 or 5.8.8. I've tracked down the
"problem", but I'm not convinced it's the actual underlying issue. The crash
was occurring at:
GUI_Helpers.cpp line 757 proc WindowsHookMsgProc
W
>> Yep, should be. Once the fix is in I will have to do more testing
>> as the scintillia issue was blocking some functionality - but it looks good:)
>
> Fix is in CVS now. Thanks for your time.
> Rob.
Done some more testing - had an issue where I was manually removing the
linefeed characters a
> Typo. That should be SendMessage rather SendMessageNN.
>
> Fix on its way to CVS now.
>
> Many thanks for taking the time to investigate this. Is that all your
> issues dealt with?
Yep, should be. Once the fix is in I will have to do more testing as the
scintillia issue was blocking some func
> Still have the scintilla issues - I should be able to do some debugging this
> weekend.
>
Ok - found the problem:
http://perl-win32-gui.cvs.sourceforge.net/perl-win32-gui/Win32-GUI/Win32-GUI-Scintilla/Scintilla.PL?r1=1.5&r2=1.6
Scroll down to line 466:
print ' my $lenght = $self->GetText
> Please could those who reported problems with RC1 download again, and
> confirm that their problems are resolved.
>
> New reports, successful or otherwise, are welcome from anyone - please
> reply to this thread.
The following errors have been fixed:
Can't call method "FETCH" on an undefined
>> In my main development environment (Vista, 5.8.8 (822)) I did the same
>> (uninstalled and
>> used the binary) and am getting the same issues (undefined value during
>> destruction and
>> Scintillia) I mentioned a few days ago.
>
> Hmmm. I wonder what's causing that. I had really hoped that
> If you download it please feedback your experience (even if it is only
> 'OK so far') by replying to this thread (or directly to me) so that I
> can get a feel for whether there are any significant issues with the
> release.
Was unable to do any testing over the weekend. Sorry. I uninstalled t
> I need to work with Jeremy to find out where his problems are coming
> from (Vista?)
Don't let this delay releasing the build to the users list - it could just be
me:)
Cheers,
jez.
_
Free games, great prizes - get gaming at Ga
> On 31/01/2008, Jeremy White wrote:
>> Just testing the latest Win32-GUI code line and I'm getting a few odd errors
>> (mingw & 5.8.8)
>
> ActiveState Perl 5.8.8 build 822?
> What gcc version?
Vista, AS822, 3.4.5 (mingw special)
>> It could be my en
Just testing the latest Win32-GUI code line and I'm getting a few odd errors
(mingw & 5.8.8) It could be my environment and I haven't got time to dig
deeper, but thought I'd report them just in case it's something simple.
When I exit my app I get lots error messages:
Can't call method "FETCH"
>> As this looked so serious I downloaded 5.10.0 (1002) to test this and I can
>> see what you see.
>> This is a major problem in general, not just for Win32::GUI (my own XS
>> modules fail their
>> test suit due to this issue).
>
> Jan (ActiveState) confirmed and explained the problem (follow
> After further investigation I have submitted the following perlbug report:
>
> http://rt.perl.org/rt3/Public/Bug/Display.html?id=50386
>
> which is also tracked by ActiveState here:
>
> http://bugs.activestate.com/show_bug.cgi?id=74532
>
> I'd appreciate anyone with a working 5.10.0 installatio
The doc's say it it should return a hash, but it actually returns an array. Bug
or doco shortfall?
###
# (@)METHOD:GetItem(NODE)
# (@)METHOD:ItemInfo(NODE)
# Returns an associative array of information about
I can't seem to reproduce:
perl-5.8.8.822 on Vista
perl-5.8.7.813 on XP SP2
Running but the demos.pl and Editor.pl with Win32-GUI-1.05. Do you need to do
anything special?
> Date: Sun, 6 Jan 2008 21:21:59 -0600
> From: [EMAIL PROTECTED]
> To: perl-win32-gui-hackers@lists.sourceforge.net
> Su
Thanks for the update - once you've updated the source I'll do some testing.
Cheers,
jez.
> Subject: [perl-win32-gui-hackers] CVS repository re-organisation
>
> I have just submitted the following SF support request:
> https://sourceforge.net/tracker/index.php?func=detail&aid=1847204&group_id=1
Tracker 1417288
https://sourceforge.net/tracker/index.php?func=detail&aid=1417288&group_id=16572&atid=116572
This bug report claims that the following code leaks memory:
#!perl -w
I don't see any leak with Win32::GUI v1.05, perl 5.6.1, 5.8.7, 5.8.8,
Win98 or Win2K.
Can anyone reproduce thi
Hi,
Before I build one is there a Win32 Visual Editor available. One that works
somewhat like the Microsoft Visual Studio v5.0 or v6.0 C++ Resource Editor?
Somthing that allows me to select and position a GUI thing in a window,
specify
the GUI parameters, integrate event sub's and insert the st
All,
Jeff Glatt has just updated his article "Embed an HTML control in your own
window using plain C"
http://www.codeproject.com/com/cwebpage.asp
He has also released "COM in plain C, Part 7"
http://www.codeproject.com/useritems/com_in_c7.asp
Both links are excellent sources of "how to" inf
All,
In all likeyhood the crash is due to my own code - but there are couple of
things that make me wonder if it could be Win32-GUI. The crash happens
relatively rarely, and I've yet to produce a repeatable test case - so it's
not really worth me explaining what I'm doing - other than I'm bui
All,
When the code below is run, it leaks User objects in the task manager. This
is with the latest codeline running under XP.
Both -dropdown and -dropdownlist options highlight the leak. I've have a
quick glance through the code but can't seem to find anything that could
cause this - a wind
I have a small amount of documentation that I want to complete, then
I'll build a 1.03_XX beta PPM for testing purposes.
I'd appreciate confirmation that I haven't broken anything (especially
Scintilla).
She built fine, and basic testing showed no problems.
Will be doing more testing during
Hi,
I've got a box with VC6 on it and I'm trying to build Win32-GUI - I know I
need to download the latest headers etc, but for the life of me (I've spent
over an hour looking!) , I can't seem to find the correct place/right SDK?
The errors below. Any suggestions?
Cheers,
jez.
NOTE: WINVE
As Rob said, this is primarily going to impact on an application that opens
and closes many windows. At least the memory is more or less returned
instantly on exit.
Yeah - and as it looks like it's XP only we can assume that it's a windows
thing rather than being a perl/win32-gui issue.
Is
If appreciate it if you could give this a good thrashing, as, hopefully,
it'll become one of the first applications new users get to see. I've
given up on my grand designs to deal gracefully with the console windows
(at least for the next release), as although I have everything needed
workin
>Does it still leak if we only create a window (without the button)?
YES!
For me, I get no leak when just the window. I also played with a few other
controls, and they leak too (a listview seemed to leak more than a button).
Adding a child window to the parent window almost doesn't leak - a
Hi Chris,
Ran code below and watched memory in task manager diminish...
Running on Windows XP Professional SP2, Intel CPU (P4 2.4GHz), 1GB RAM...
When you run that script do you find that Perl only take about 50% of CPU
while some other process takes up the rest? Looks like this could be a
I've added support for the Win32 AnimateWindow() API, as requested by
tracker 1266930:
https://sourceforge.net/tracker/index.php?func=detail&aid=1266930&group_id=16572&atid=366572
Now, as well as $win->Show(), $win->Hide() you can use $win->Animate().
I had problems building under mingw - I h
But I can't duplicate the memory leak reported (perl 5.8.7 813,
Win32::GUI 1.03, win98 and win2k). Jez reports this as still happening
on WinXP - can anyone else duplicate a memory leak running this code:
She builds fine with all tests ok - I still see that leak:)
Cheers,
jez.
See the 'Changes' file in each subdirectory for highlights of any
significant changes.
She builds fine for me. Good job.
Cheers,
jez.
> Right :) I don't pretend to speak for everyone, of course. I was a
> little concerned, though, about Jeremy's comment of sharing stuff that
> isn't presently shared, betweeen sub-modules... I don't know how much
> that is, or if it can be done without making more dependencies or bigger
> hu
Here's how I stand:
Scintilla - no problems with this. I have the code ready to become Grid -
I'm ready to make this part of core too. As it relies on the DIBitmap -
Whilst this should technically be compilable (sp?) using AxWindow - relies
on the MS ATL framework, so I doubt it can ever be
http://www.codeproject.com/com/com_in__c4.asp
http://www.codeproject.com/useritems/com_in_c5.asp
Cheers,
jez.
The only thing that concerns me is that the distribution is growing in size
quite rapidly, and once things are in it's difficult to take them out. Is
anyone concerned if the binary distribution doubles in size? How about if
it trebles in size?
I guess the real question is how do we decide wh
Something like this:
- ability to close Console if there is one present and its not needed
- automatically re-create a console window if any reads/writes are done on
stdin/out/err
- ability to set the Console window title, Icon etc.
Eventually remove GetPerlWindow() from GUI.xs??
I suspect I'
I don't have access to XP, so have not looked into manifests. I can see
that distributing them (or otherwise making them available) would be a good
thing, but I'm not so sure about installing them in the perl bin directory
- is there any down side to doing that?
The manifest is a simple XML s
Jez, does the current CVS allow your scripts to run, albeit with lots of
warnings?
New odd issue - same scenario - use of constants in another package:
Can't locate auto/Win32/GUI/Grid/DT_CENTER.al in @INC (@INC contains:
C:/perl/li
b C:/perl/site/lib .) at ...
the offending line:
$Grid
Is this a good thing to pursue? Suggestions for changes or alternative
approaches welcome. A better name for the script would be good too!
Nice - with a good set of examples it would certainly show what Win32-GUI is
capable off.
One thing I did notice - and this is a minor issue and not rea
I'd appreciate it if people can build and what's in CVS and run their
current scripts against these changes to see what (if any) change in
behaviour you get. I hope none (except perhaps for a few warnings), but I
need help to ensure I've covered all the ways people were accessing the
constants
In the mean time, can anybody suggest why it might be a bad idea to remove
'Win32::GUI' from the @ISA of Win32::GUI::Class Win32::GUI::MenuButton or
Win32::GUI::MenuItem?
Not that I can think off.
Cheers,
jez.
I just added my code for the Win32::GUI::Constants module that we have
discussed here recently. The build process is internally a bit convoluted,
but should happen smoothly from the outside!
As always comments on success and/or failures in your build environment are
encouraged.
No cup final
http://www.codeproject.com/useritems/com_in_c2.asp
http://www.codeproject.com/useritems/com_in_c3.asp
Quality.
Cheers,
jez.
Hi,
I exported the cvs source and began to familiarize myself with it. Once
I feel comfortable with that, I will try and work on either some low
priority bugs or feature requests that no one has taken up yet. If
anyone has any suggestions, tips, unstated best practices, advice, or
whatever, I'
As always, any reports of success and/or failure are welcome.
All ok under XP. Nice work.
Cheers,
jez.
Ok,
Doing:
size = GetFileVersionInfoSize((char*)filename, &handle);
and:
if(GetFileVersionInfo((char*)filename, handle, size, data)) {
"Fixes" the errors, the resulting binary runs fine as does NotifyIcon.pl -
why the error - no idea - as a guess the mingw headers.
From:
With Vista just round the corner and native 64bit soon to be a
requirement...
Eggzactly! Poor planning on MS's part, isn't an emergency on my clients'
part. Or Rob's. In this case, the poor planning, is that people really
don't need all the new features in new operating systems... they'd re
GUI.xs: In function `void XS_Win32__GUI_GetDllVersion(PerlInterpreter*,
CV*)':
GUI.xs:5591: warning: converting of negative value `-0x1' to `DWORD'
GUI.xs:5592: warning: converting of negative value `-0x1' to `DWORD'
GUI.xs:5593: warning: converting of negative value `-0x1
How about something like this:
- The 'userdata' member of the (internal) stored data always holds a hash.
The UserData method stores the passed SV in the 'UserData' member of that
hash.
The 'Data' method stores the passed SV in the hash with a key equal to the
current classname (obtained from
(3) Drop support for Win95/98/ME - I don't want to do this yet.
I'd rather not drop support for Win9x yet either. Still have clients
using it...
I'm still using it, and I don't want to have to pay MS to upgrade yet
(althoug a new PC is on the horizon).
With Vista just round the corner and
I came across this great article - may be of interest to some people:
Introduction
There are numerous examples that demonstrate how to use/create
COM/OLE/ActiveX components. But these examples typically use Microsoft
Foundation Classes (MFC), .NET, C#, WTL, or at least ATL, because those
frame
Hi,
Brian Millham skin email on the users list has highlighted something that
I've been thinking about for a while - how to make creating Win32-GUI
classes easier/safer.
One of the problems creating a Win32-GUI class is were to store the instance
data for the object while allowing the events
NotifyIcon I certainly have on my list of candidates. I haven't thought
much beyond that, but I am hopeful that a restructuring like this might
reduce GUI.xs and GUI.pm to more manageable sizes. I also want to
experiment with moving a lot of the per-control methods from XS back into
perl. Th
The Custom Draw changes have been checked in.
Cheers,
jez.
It's very easy to make terrible mistakes in the XS part.
Devel::LeakTrace helps. I don't like leaks in MessageLoop events.
I'll have a look at that module.
No, more like:
-onDragDrop => sub {
my ($win, $drag) = @_; # dragged to win
print "Mouse: ", join(", ", $drag->MousePosition), "\n";
And I wonder if we should not support a higher level interface, by filling
the needed properties of this object on creation, with the files
and the mousepoint automatically.
Then none of the 4 DragDrop functions would be needed and the
event would be much simplier to use.
Yeah, I think that woul
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' undec
The primary issue is maintenance and ease of understanding. In this case,
speed
is increased and space is decreased.
[snip]
My motivation is to reduce maintainence, increase clarity, and if possible,
increase the speed of execution and decrease the memory footprint.
All worthwhile sentiment
I get the message. What should be used? Looked at all the documentation
that I
have (including my new jeb-doc) and can't find what the alternative is.
Sigh.
see:
http://perl-win32-gui.sourceforge.net/cgi-bin/docs.cgi?doc=reference-options
popstyle, pushstyle is what you want.
On another no
I think I've followed all the suggestions. I've tried to
put use scoping correctly, and I've found out that the
only thing that the exporter seems to export are subroutine
names. It's clear that I don't know what I'm doing. Any
more suggestions?
could you post an example?
Cheers,
jez.
our original discussions until now, I think it may be more worthwhile to
figure out how to make _all_ 18000 constants available to Win32::GUI
programs, without paying a huge price in memory. Those constants that
actually get used get cached in the stash anyway...
If speed isn't the issue t
Arthur I Schwarz wrote:
I'm have partitioned my program into modules:
::GUI
The program driver is in :
.anonymous subroutine (the nameless thing at the end)
&StartWindows # &::GUI::StartWindows
and ::GUI::StartWindows I do:
$window->show();
Win32::GUI::Dialog();
The window dis
Hi,
I've just committed some changes to Scintilla, the main ones being that
events now fire for perl 5.8.x. This fix also solves a few issues where
Scintilla was crashing, again with perl 5.8.x. This module should work with
any version of Win32::GUI from V1.00 upwards.
I've also updated Scin
[ I've added a note to myself to look for all the places that we use dTHX
and to ensure that they are necessary - I think they are used when we get a
win32 api callback such that we can't use the NOTXSPROC calling convention
]
I'm still not 100% sure how the context works within Win32-GUI but
At first glance these errors look like C++ vs. C syntax problems. I
haven't looked at the scintilla code, but it would be my guess that the XS
files is being compiled as C (this is the standard Makefile.PL behaviour)
whereas Win32::GUI (for reasons that escape me) is built using a C++
compiler
Hi,
I'm trying to fix Scintilla, with the aim of creating a new release of this
module. The problem is that Scintilla defines and uses it's own
PERLWIN32GUI_USERDATA structure. As this structure has changed over time in
Win32-GUI it creates all kinds of problems with this module (Scintilla
su
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
I am please to announce that v1.03 of Win32::GUI is available for
download from SourceForge.
I downloaded the 5.8 ppm and everything seems ok.
Good work.
Cheers,
jez.
I intend to make this the V1.03 release once I've had a few days to play
with it.
She builds fine under ming and basic testing hasn't shown anything odd. I'll
try and build under VC6 and test her hard over the next couple of days.
Good work,
Cheers,
jez,
Can anyone point me at modules/tools that let me look at how much memory
my module is using?
The only easy thing I can mention is the total process size as reported in
the "Mem Usage" column of the Processes tab in Windows Task Manager. It is
kind of a rough measure, but one could certainly d
Hi,
All these modules are now in the Win32-GUI source repository:
http://cvs.sourceforge.net/viewcvs.py/perl-win32-gui/
Cheers,
jez.
If the Win32::GUI::Constant package is a XS/C code we'll be able to come
up with various algorithms that compress the text strings meaning the
resulting dll could be relatively small.
But that imports the name into the current package, which is true namespace
clutter, and using bare-name const
We wouldn't _need_ to change the algorithm, but if we do generate from
(say) a flat file of constants (or something more sophisticated, like the
Windows header files), the potential for using more constants in a program
is larger, and a better algorithm, while it won't change the run time of
th
I assume you would end up with something like:
use Win32::GUI::Constant qw (ES_WANTRETURN with a big list of other
constants that you want);
With the Constant package creating the passed list of constants in the
callers namespace? You could also have:
use Win32::GUI::Constant qw (all); #all
My 2 cents.
SW_* constants are not defined in GUI_constants.cpp (nor exported in
GUI.pm). In general there are many constants missing.
Constant handling is, and will be a pain to get right. Personally, I don't
like the way Win32::GUI exports all it's constants by default - it's a huge
waste
There are two main reasons to use SetEvent:
1) To add NEM events to windows/controls after they have been created -
perhaps by a 3rd party tool (such as Loft) which isn't NEM aware.
2) To change the event handlers during runtime.
In both cases, the expectation should be that the control is now
Jeremy White wrote:
Just done some performance testing with this type map:
if(SvROK($arg)) {
SV** out=hv_fetch((HV*)SvRV($arg), \"-handle\", 7, 0);
if(out != NULL)
$var = ($type) SvIV(*out);
else
$var = NULL;
} else
$var = ($
I'll let you know.
Well, that fix appears to be the likeliest of the fixes that cured my
client's problem. She is delighted. And therefore, so am I. And this
confirms that the problem shows up more on XP than on Windows 2000, because
I could never reproduce it on Windows 2000, but she coul
Just done some performance testing with this type map:
if(SvROK($arg)) {
SV** out=hv_fetch((HV*)SvRV($arg), \"-handle\", 7, 0);
if(out != NULL)
$var = ($type) SvIV(*out);
else
$var = NULL;
} else
$var = ($type) SvIV($arg);
Benchmark: timing
Hi,
The typemap for T_HANDLE is as follows:
if(SvROK($arg)) {
if(hv_fetch((HV*)SvRV($arg), \"-handle\", 7, 0) != NULL)
$var = ($type) SvIV(*(hv_fetch((HV*)SvRV($arg), \"-handle\", 7,
0)));
else
$var = NULL;
} else
$var = ($type) SvIV($arg);
whi
So in my last analysis I missed the 3rd way not to get the OEM event fired:
returning 1 from the NEM handler.
I personally don't see anything wrong with this logic, so long as you
believe that returning 1 from an event handler means 'pass the event to the
next handler', regardless of whether t
Question: is this a bug? The only alternate behaviour I can come up with
is that SetEvent(), rather than setting the NEM flag, should check it and
bail out if it is not set (with a warning?). [The current behaviour is
useful if you are sub-classing a control, and do not know which method a
I haven't tried this yet, but it seems wrong. Can you raise a bug report
and I'll dig further into this one.
http://sourceforge.net/tracker/?func=detail&atid=116572&aid=1333060&group_id=16572
Ok - it seems this is only an issue when SetEvent is used (see example
below, also on tracker).
Wha
If you have some code that exhibits this, then I'd be interested to try to
reproduce it. I though I could explain it, but then couldn't get an
example together that validated my explanation.
Not really - as when you reduce the size of the application, the issue
disappears. I'll keep an eye on
This would lead to a more complex macro/function, but would, I think be
worth it.
[snip]
It would be a more complicated macro/function - but I agree with you, it
would be worth it.
This works nicely for the ANSI versions of the call, which return th ANSI
encoded string of bytes that is suit
Seems like that should suffice, assuming that MSDN's definition of
"character" is a 32-bit UCS-2 character. I have no clue if MS supports
UCS-2 characters that use multiple 32-bit numbers to represent a single
character, but I believe such are legal. And if they do support them, I
don't know
Hi,
perl.exe caused an Access Violation at location 7c910f29 in module
ntdll.dll Reading from location .
Apologies this issue was my error. My application was performing an buffer
overflow which ended up causing this error.
Cheers,
jez.
While tracking various crashes down I found myself in the DoEvent function
in GUI_Events.cpp, now I don't think there is a issue here - but I did
notice something surprising.
I would have through that if a control was using NEM events, the OEM logic
wouldn't be called for that control.
For e
perl.exe caused an Access Violation at location 7c910f29 in module ntdll.dll
Reading from location .
Registers:
eax=0a4fc680 ebx=0023 ecx= edx= esi=0a4fc678
edi=0a4f8210
eip=7c910f29 esp=0140e000 ebp=0140e00c iopl=0 nv up ei pl zr na po
nc
cs=001b ss=0023
I've just committed a fix for Combobox.xs (GetString) and Listbox.xs
(GetString) - both weren't allocating enough space for
Do you think this problem would have been more likely to show up on Windows
XP than on Windows 2000? I have an application that seems quite robust on
Windows 2000, but
I apologies for using this forum as a sounding board...
This is going to be a pain to track down. I've got a case where I'm almost
guaranteed to cause a crash on exit - it's not a simple case
Ok - think I've got it - just not sure what the fix should be - or even if a
fix is needed. In my ap
Not my day...Crash happens at 'random' times, but only on exit. I'm trying
to get a simple test case together...Any comments?
This is going to be a pain to track down. I've got a case where I'm almost
guaranteed to cause a crash on exit - it's not a simple case - and can't
include the code (as
Hi,
Not my day...Crash happens at 'random' times, but only on exit. I'm trying
to get a simple test case together...Any comments?
Cheers,
jez.
perl.exe caused an Access Violation at location 01fff42d Reading from
location 01fff42d.
Registers:
eax=7ffdf000 ebx= ecx= edx=000
Hi,
cbString = SendMessage(handle, CB_GETLBTEXTLEN, index, 0);
if(cbString != LB_ERR) {
szString = (char *) safemalloc(cbString);
I've just committed a fix for Combobox.xs (GetString) and Listbox.xs
(GetString) - both weren't allocating enough space for the string (I added
one
Hi,
perl.exe caused an Access Violation at location 7c93426d in module ntdll.dll
Reading from location .
Registers:
eax= ebx=01a4 ecx=00230ef0 edx= esi=002301a8
edi=002301c8
eip=7c93426d esp=0140efdc ebp=0140f1fc iopl=0 nv up ei pl zr na po
nc
cs=001b ss=
Hi,
I'm tracking down various problems with my app - while debugging I was able
to crash Win32-GUI (latest code line) on Perl 5.8.7:
perl.exe caused an Access Violation at location 23497414 in module GUI.dll
Reading from location 0004.
Registers:
eax= ebx=0004 ecx= e
- 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 b
Hi,
Had a problem with Imagelist.xs on Mingw - a couple of #ifdef __MINGW__
should be #ifdef __MINGW32__
Cheers,
jez.
Would anyone have an issue if I was to make a decision to only support 5.6
and 5.8 going forwards?
Makes sense as far as I'm concerned.
Cheers,
jez.
1 - 100 of 125 matches
Mail list logo
