On 28/07/07, Reini Urban <[EMAIL PROTECTED]> wrote:
> Attached is simple patch which fixes two issues:
>
> * GUI.rc is readonly in the downloaded archive, and therefore
>build_tools/updateRC.pl fails to write it.
Thanks. Applied with additional tweaks to updateRC.pl and Makefile,
so that GUI.
On 30/07/07, Robert May <[EMAIL PROTECTED]> wrote:
>
> Changes are in my local copy, and will make it to CVS shortly.
Quicker than I expected! In CVS now.
Regards,
Rob.
-
This SF.net email is sponsored by
All,
Jez White has kindly committed a set of changes that have been
accumulating in my workspace. Details below: I will post a further
message (to the users list only) about the Coolmenu changes mentioned below.
+ [Robert May] : Fixes for Toolbars:
- Toolbar.xs:
+ Fixed message
Jez,
I was going to mail you off-list, as I was playing with the MinGW build
last week to try to get the size down, and I succeeded in reducing the
size of my GUI.dll for the current head build from 3104 KB down to 979
KB (which is only 100k or so bigger than the VC build of the 1.0 source).
To create the HTML docs, I run:
perl dodoc.pl
perl dohtml.pl
in Win32-GUI\docs directory - although I've no idea how these files
would be included in the PPM:)
Thanks - I was a bit confused by the fact that dodoc.pl seems to have
options for building html too.
I've got a PPM built from my
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 co
OK. I've stuck up a PPM for ActiveState Perl 5.8 at
http://www.robmay.me.uk/win32gui/
It's a build from today's CVS head revision, after I checked in the last
few fixes I had in my local repository.
I made the following changes before building:
- GUI.pm - changed $VERSION to be '1.01_01' (i.
Robert May wrote:
OK. I've stuck up a PPM for ActiveState Perl 5.8 at
http://www.robmay.me.uk/win32gui/
Thanks to Jez White there's now a PPM for ActiveState Perl 5.6 at the
same location.
Regards,
Rob.
Glenn Linderman wrote:
Sorry, I was gone for a week or so. I have MS VC++ 6.0 and know how
to build the package, but not the whole process for release. Would
that still be helpful? (especially regarding the PAR issue?) I only
have Perl 5.8 installed though, and have never played with having
Reini Urban wrote:
Jeremy White sagte:
[summary] MinGW build of Win32::GUI with ActiveState perl works with no
binary compatibility issues.
Just a PAR from the PAR ppm does not work for Win32::GUI.
You'd need to compile your own PAR from CPAN, esp. with the latest fixes.
Cygwin Win32::
All,
As part of building the recent release candidates I have had to have a
look at the documentation, and it's a bit of a mess. I propose to tidy
it up.
So that the source distribution results in good PPMs with all the
documentation enclosed it is important that it is possible to run
pod2
Glenn Linderman wrote:
On approximately 6/19/2005 11:29 AM, came the following characters
from the keyboard of Robert May:
Glenn Linderman wrote:
Sorry, I was gone for a week or so. I have MS VC++ 6.0 and know how
to build the package, but not the whole process for release. Would
that
Glenn Linderman wrote:
[snipped conversation on the merits of MinGW, VC++ 6.0 and VC++ 7.0 (aka
.net)
I believe there are some library changes and such that cause VC++ 6.0
and 7.0 and .net to require different versions of the libraries... and
since ActiveState is compiled with 6.0 that it is
make ppm - does a make all, make htmldocs and make ppd, wrapping the
whole lot up in a PPM.zip ready for distribution.
CHANGELOG:
+ [Robert May] : Documentation re-work
- new documentation structure
- new build_tools directory with scripts for building the documentation
- additions to ma
Glenn Linderman wrote:
On approximately 6/20/2005 11:29 AM, came the following characters
from the keyboard of Robert May:
Do we have anyone with VC++ and perl 5.6 who can do the 5.6 build for
us? If not we might have to go with MinGW for this?
Again, if someone can step in and point me
Glenn Linderman wrote:
On approximately 6/20/2005 11:29 AM, came the following characters
from the keyboard of Robert May:
Glenn Linderman wrote:
[snipped conversation on the merits of MinGW, VC++ 6.0 and VC++ 7.0
(aka .net)
I believe there are some library changes and such that cause VC
All,
I have a small number of items that I wish to conclude before a v1.01
release:
(1) Merging Reini's cygwin fixes - the changes are small, and really
shouldn't bother anyone. I have most of them merged in my local
workspace, and no problems with either the MinGW or VC++ builds yet.
(2
Jeremy White wrote:
Assuming the I get responses from Reini regarding the small number of
questions I have about his patches quickly, then I think that we'll
be ready for a V1.01 release in about a week's time. I'll solicit
further feedback from the users group, but given the current level of
Johan Lindström wrote:
At 23:15 2005-06-28, Robert May wrote:
I'm waiting for feedback from Reini before I check the changes into
CVS. If you'd like a heads up, there's a snapshot of my working copy
source at http://robmay.me.uk/win32gui/. If you do download and
compile it
When building Win32::GUI with MinGW under ActiveState ActivePerl 5.8.6
and 5.8.7 I get a warning from the compiler about "fileno" redefined.
This warning can be eliminated by applying the patch described at
http://aspn.activestate.com/ASPN/Mail/Message/perl5-porters/2722680
It needs applying to
Robert May wrote:
I have a small number of items that I wish to conclude before a v1.01
release:
(1) Merging Reini's cygwin fixes
(2) reverting to a single Makefile.
I just checked in a somewhat larger set of changes than I was
anticipating. Most of the changes are in GUI.
There has been some talk about improving the test suite recently. I was
thinking that we should have a discussion and try to come to a consensus
about the test tools/frameworks that w should be using before anyone
really starts coding in earnest.
I think it goes without saying that we want to
Glenn Linderman wrote:
H. Having problems with compiling math.h, I tried this, but got
cl -c-nologo -Gf -W3 -MD -Zi -DNDEBUG -O1 -DWIN32 -D_CONSOLE
-DNO_STRICT -DHAVE_DES_FCRYPT -DNO_HASH_SEED -DPERL_IMPLICIT_CONTEXT
-DPERL_IMPLICIT_SYS -DUSE_PERLIO -DPERL_MSVCRT_READFIX -MD -Z
Robert May wrote:
Glenn Linderman wrote:
[errors snipped]
I think that is an improvement, in the sense that the compilation
proceeded further than before.
I'm working on it. I think I understand all the changes that Reini
gave me as parts of the cygwi and his MSVC6 patches.
Glenn Linderman wrote:
On approximately 7/1/2005 4:51 PM, came the following characters from
the keyboard of Robert May:
I just checked in an updated GUI.h (along with backing out a few
other changes that Reini and I made in the last few days that turned
out to be unnecessary). I hope this
In several places in Win32::GUI XS code there are warnings printed.
When this happens, there is (as far as I have checked) always test 'if
(PL_dowarn)' around the warning. Now, I'm sure there is some Perl
history here, as the documentation (perlintern) clearly states that
PL_dowarn is the XS
Glenn Linderman wrote:
On approximately 7/2/2005 4:56 PM, came the following characters from
the keyboard of Robert May:
In several places in Win32::GUI XS code there are warnings printed.
When this happens, there is (as far as I have checked) always test
'if (PL_dowarn)'
Reini,
OK, I've not had a chance to keep up with your tests this week, and
trying to catch up now find myself mightily confused. Some of the
patches seem to be against the source that I called 1.01_03, some seem
to be incremental (probably on the previous set of patches?). To add to
my con
All,
I just did a final quick tidy-up and tagged the HEAD revisions as
'Win32-GUI-1_02'.
I hope we'll have a release on SourceForge very soon.
Regards,
Rob.
Robert May wrote:
Reini,
OK, I've not had a chance to keep up with your tests this week, and
trying to catc
I am please to announce that v1.02 of Win32::GUI is available for
download from SourceForge.
Win32::GUI is a Perl extension allowing creation of native Win32 GUI
applications.
Project summary and download:
http://sourceforge.net/projects/perl-win32-gui/
Release notes:
http://sourceforge.net/p
FYI, I have posted announcements for the new release to:
perl-win32-gui-hackers@lists.sourceforge.net (this list!)
[EMAIL PROTECTED]
as a perl-win32-gui news item at SourceForge
[EMAIL PROTECTED]
comp.lang.perl.announce usenet group
Regards,
Rob.
Reini Urban wrote:
Robert May schrieb:
OK, I've not had a chance to keep up with your tests this week, and
trying to catch up now find myself mightily confused. Some of the
patches seem to be against the source that I called 1.01_03, some
seem to be incremental (probably on the pre
Following the new release I have closed the following tracker items:
Bugs - resolution 'fixed':
1202695 Documentation is missing from PPM's
1164783 EnumMyWindows() does not work
1164780 Label does not show bitmap on creation
1153899 Crash on exit with two RichEdits
1092732 Slider no longer suppor
All,
I've spent the last week or so struggling to come to terms with CSS and
its non-standard implementations accros browsers. I have the outline of
a site that I'd appreciate feedback on:
http://www.robmay.me.uk/win32gui/website/
Particularly I'd like to know:
(1) Whether it lays out nicel
Reini Urban wrote:
(1) Whether it lays out nicely in your browser, or whether it screws up.
looks fine for firefox and MSIE6.
Great - thanks.
(4) Your Technical comments
http://www.robmay.me.uk/win32gui/website/docs/Win32/GUI.html TOC
Typo:
* Introdction
Got it. That was in the pod docum
I've been looking at a few of the bug reports regarding background
colours of windows/controls.
(1) It appears that the '-background' option was never intended to work
with windows (Win32::GUI::Window, Win32::GUI::Dialog) and that the only
way to change the background colour of a window is us
Jeremy White wrote:
(1) It appears that the '-background' option was never intended to
work with windows (Win32::GUI::Window, Win32::GUI::Dialog) and that
the only way to change the background colour of a window is using the
-class option with a coloured brush. It might be possible to extend
It doesn't crash for me: Win98 (and IE 6 fully patched), perl 5.8.7,
Win32::GUI 1.02
Here's an alternative. Does this crash for you?
#!perl -w
use strict;
use warnings;
use Win32::GUI;
# Create the main window
my $mainwindow = new Win32::GUI::Window(
-name => "Window",
-title => "Ob
I am pleased to announce that Win32::GUI has a new home on the web at:
http://perl-win32-gui.sourceforge.net/
There you'll find links to all things Win32::GUI including the latest
documentation. Problems/suggestions/corrections to the users mailing
list please.
Regards,
Rob.
u)
- GUI.pm Timer fixes (Reini Urban)
- many tests added, and MANIFEST updated (Reini Urban, Dan Dascalescu,
Robert May)
I've done little with the test other that take what Reini and Dan have
given me, and re-write them to use Test::More. We still need to think
through a testing strategy.
Jeremy White wrote:
Hi,
Was looking at something else and came across the -container option.
What is it for? The option has no documentation, but does seem to do
"something". It has a message loop (ContainerMsgLoop in
GUI_MessageLoops), and a constant (PERLWIN32GUI_CONTAINER) which is
checke
Jeremy White wrote:
I had to change __MINGW__ in ImageList.xs to __MINGW32__, otherwise I get:
Got it.
When running makefile.pl I get:
Checking if your kit is complete...
Warning: the following files are missing in your kit:
patches/README.txt
patches/patch001.patch
Got it.
I
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'
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 answ
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 onT
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.
All,
I was hoping to target a new release for the end of August, but got
caught up in other stuff, and continue to be busy for the next few
weeks, at least.
I had hoped to complete the following items for the next release:
- fix as many of the trackers as possible
- get all the current sample
Does anyone have any strong views about what versions of Perl we should
continue to support? For some time now we have not released PPMs for
Perl earlier than 5.6.
The reason I ask: I have got to the bottom of tracker 1164766 (Unhook
generating warnings) and it turns out to be a difference b
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.
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 :-)
All,
There is a new list available at
https://sourceforge.net/mail/?group_id=16572
It is a send-only list, sending details of commits made to the Win32-GUI
CVS repository. Subscribe if you want to follow more details of what is
being committed ...
I'll announce it more widely once I'm a b
Reini Urban wrote:
I've done now Devel::Cover tests for the old and new tests.
$ perldoc Devel::Cover
$ HARNESS_PERL_SWITCHES=-MDevel::Cover make test
$ cover
what stmt bran cond sub podtime total
3 tests only:11.4 6.3 9.5 11.1 16.7 100.09
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
I've just spent the evening tracking down this problem, as it was really
annoying me (Tracker: 1165626). The solution was simple, but finding
the information was not. It's such a surprising issue (to me anyway)
that I thought I'd share it with you.
DoModal was using GetParent() to try to fin
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 d
Jeremy White wrote:
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 suppor
Jeremy White wrote:
Ok - think I've got it - just not sure what the fix should be - or even
if a fix is needed. In my app, I catch the terminate event and ask the
user if they are sure they wish to exit. If they say yes, I perform
logic to save various settings. Once the settings have been save
ventName, perlud->szWindowName);
strcat(EventName, "_");
strcat(EventName, Name);
To see the amount of needless calls made...
I haven't tried this yet, but it seems wrong. Can you raise a bug
report and I'll dig further into this one.
Thanks,
Rob.
--
Rober
Jeremy White wrote:
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, a
Jeremy White wrote:
If we spend time on reworking some of the internals for Unicode is it
worth us considering the implications of 64bit further down the road?
I'd be very interested in starting to try to understand what 64bit
support would entail. I'm starting to put together a list of thi
Jeremy White wrote:
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 k
SW_* constants are not defined in GUI_constants.cpp (nor exported in
GUI.pm). In general there are many constants missing.
There are 2 issues to address here:
(1) How should we deal with constants? I, personally, don't like the
way that Win32::GUI by default exports all it's constants into th
Jeremy White wrote:
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', re
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 = ($type) SvIV($arg
t; [100,100],
-size => [400,300],
);
$mw->AddTextfield(
-size => [200,200],
-multiline => 1,
-addstyle => ES_WANTRETURN,
);
$mw->Show();
Win32::GUI::Dialog();
exit(0);
__END__
Regards,
Rob.
--
Robert May
Win32::GUI, a perl extension for native Win32 applications
http://perl-win32-gui.sourceforge.net/
Jeremy White wrote:
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
$v
Jeremy White wrote:
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.
See below.
Personally, I
don't like the way Win32::GUI exports all it's consta
Jeremy White wrote:
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 th
Glenn Linderman wrote:
On approximately 11/1/2005 8:51 AM, came the following characters from
the keyboard of Jeremy White:
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 rel
Glenn Linderman wrote:
from the keyboard of Robert May:
Glenn Linderman wrote:
An alternate would be Win32::Constant
I think I'll stick with the Win32::GUI namespace for now. But I agree
there is room for expanding the scope.
My current prototype has about 1500 constants (and I
Glenn Linderman wrote:
from the keyboard of Robert May:
Glenn Linderman:
Robert May:
Glenn Linderman wrote:
My intention is:
- Win32::GUI::Constants will export nothing by default.
- there will be a tag for the current set of symbols. Any suggestions
for a name?
:compatibility_set
Glenn Linderman wrote:
use Win32::GUI ();
will not export anything, as you'd expect, and as happens today. I
think this is what Jez is already doing.
I'm doing that. But I don't know about Jez. On the other hand, use
Win32::GUI(); also turns off exporting of (non-constant) functions,
I thought I'd share a couple of test that I've done today with you.
(1) speed increases for inlining:
I was interested to know how much time was saved by inline constants.
The following script gives an answer:
#!perl -w
use strict;
use warnings;
use Benchmark qw( :hireswallclock timethese cmpth
Robert May wrote:
Hmm. With 350 names in :compatibility_win32_gui, more files might be
needed. Maybe change Tags.pm
[snip]
eval "require Win32::GUI::Constants::Tags_$spec";
if($@) {
warnings::warnif qq(Failed to load definition for tag ':$spec': $@)
}
else {
Please find attached what I hope is a final beta of a
Win32::GUI::Constants package - v0.00_03.
I'd appreciate a (final?) once over before I up the version to 0.01 and
make it available to a wider audience. I hope to be able to fold it
into Win32::GUI v1.04, but haven't looked at how difficul
Glenn Linderman wrote:
On approximately 11/9/2005 1:26 PM, came the following characters from
the keyboard of Robert May:
Please find attached what I hope is a final beta of a
Win32::GUI::Constants package - v0.00_03.
Constants.PL contains stuff like:
BDR_OUTER0x0003
lection sweep when the program terminates.
If we can agree on this, then I will make the changes, update the
documentation and update the tests.
Your comments welcome, as always.
Regards,
Rob.
Robert May wrote:
Hi Glenn,
Thanks for the investigation. The changes were made by Reini, to try t
ndows
timer, and Interval(n) re-starting it) or (2) Kill(1) freeing all the
perl resources.
I'm going to go ahead and re-work it and update the documentation and tests.
Regards,
Rob.
So, in general, though I'm more of a user than a developer, I agree with
your suggestions.
Glen
ain.
Kill(1) - calls KillTimer and removes the NAME to ID mapping.
I'm going to go ahead and re-work it and update the documentation and
tests.
Updated implementation, documentation, and tests are now in CVS.
Regards,
Rob.
--
Robert May
Win32::GUI, a perl extension for native Win32 applicati
I just committed a number of bug fixes:
- Makefile.PL added code to remove Test::More dependence from PPD
- GUI_MessageLoops.cpp, Window.xs change all mouse related handlers to
use GET_X_LPARAM and GET_Y_LPARAM rather than HIWORD and LOWORD
(Tracker: 1262098)
- GUI.xs added INTERNAL function
rrently have an
environment available.
I hope to tag these files as 1.03 and release tomorrow evening (UK time).
Regards,
Rob.
--
Robert May
Win32::GUI, a perl extension for native Win32 applications
http://perl-win32-gui.sourceforge.net/
ez
White)
- GUI.xs: fixed return value of GetAsyncKeyState
- Re-worked Win32::GUI::Timer package implementation. Now destruction
works correctly.
Contributors to this release:
=
Dan Dascalescu
Reini Urban
Jeremy White
aschwarz1309
Robert May
My thanks to all the o
Jeremy White wrote:
I downloaded the 5.8 ppm and everything seems ok.
Thanks for the feedback.
Rob.
--
Robert May
Win32::GUI, a perl extension for native Win32 applications
http://perl-win32-gui.sourceforge.net/
Last Night I committed a couple of bug fixes:
- GUI.h change order of instructions in PERL_FREE macro to prevent
crashes (Trackers 1243378 and 1248578)
I hope this fix will eliminate most of the crashes/warnings hat happen
on program termination. If you have any example code that still crash
Jeremy White wrote:
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
2) I'm confused about the Perl context and how it's used within
Win32-GUI - and how Scintilla should handle things.
I've got it working by doing:
dTHX; /* fetch context */
in the Scintilla event handlers, but had to remove NOTXSCALL/NOTXSPROC
in some functions where the context isn't us
Jeremy White wrote:
[ 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
Jeremy White wrote:
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
Glenn,
Do you have a pointer to the whole thread so that I can have a browse.
Thanks,
Rob.
Glenn Linderman wrote:
for swap stack trickery sounds bad... and I doubt we are doing it in
Win32::GUI... Thought I'd put it here for the record, if nothing else.
Original Message
To
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
Arthur I Schwarz wrote:
I'm have partitioned my program into modules:
[snip]
The window displays correctly.
All the pull down menus display correctly.
Selecting any item in a pull down menu has no effect (the event seems
to be
unhandled).
Robert May wrote:
My suspicion is that yo
Robert May wrote:
I've already re-worked the whole constants support (see the archive for
this list a couple of months back), and it currently uses a perl hash
to hold the constants and do the lookup, but given the potential
number of constants in the windows header files I was thinki
Arthur Schwarz wrote:
I've just looked at GUI_Options.cpp again and wonder if the following code is
correct:
perlcs->cs.style &= perlcs->cs.style ^ (DWORD) SvIV(ST(next_i));
Looks fine to me:
&= (assignment operator) has lower precedence than ^ (Bitwise exclusive
or) - see perldoc perlop
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
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
Reini Urban's patches have spurred me into digging out some work I was
doing to integrate The GUI Loft's DragDrop.pm file into Win32::GUI
proper. There are some nice ideas from Reini that I would like to steal
to enhance what I was doing.
Here's what I am proposing:
(1) All windows/controls
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
Reini Urban wrote:
>Robert May wrote:
Here's what I am proposing:
(1) All windows/controls will gain the -acceptfiles option that will be
used to set/unset the WS_EX_ACCEPTFILES extended style on the
window/control (For those of you familiar with it, this is all that the
Win32 DrapAcc
Jeremy White wrote:
> Robert May wrote:
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
Glenn Linderman wrote:
On approximately 3/19/2006 10:49 AM, came the following characters from
the keyboard of Robert May:
it is my understanding that PAR
has the ability to determine what methods are used, and only package
up the autoload subs that are required.
I'm unaware of
1 - 100 of 238 matches
Mail list logo
