All,
I've got a couple of new methods for the datetime control that could be
included in the new build.
Cheers,
jez.
###
# (@)METHOD:GetDateTime()
# (preliminary) Returns the date and time in the DateTime control in a ei
Nice one, thanks.
Is there a set of standards for updating the documentation as we are
adding/fixing things? Do I need to update anything?
Cheers,
jez.
From: "Laurent ROCHER" <[EMAIL PROTECTED]>
Reply-To: "Laurent ROCHER" <[EMAIL PROTECTED]>
To:
Subject: Re: [perl-win32-gui-hackers] Metho
Humm - for some reason I'm not getting all messages to this list - anyone
else have that problem? The archive is also not up to date...
I missed the start of the thread - Anyway my 2 cents
Garside Trevor say on win32::GUI Users list flicker problem when
resize
window can be remove by
Today has been one of those days - if it can go wrong, it has!
Anyway, I've retested - and there is a problem - although I'm having
difficult in getting a small enough example working (I'll try again in the
morning). However, I came across another issue with PPM 671 and 671 built
with ming. Th
In short, can we please release a new version of Win32::GUI in the near
future? I would be happy to test a release candidate to make sure it works
with TGL.
I dropped a mail to Laurent to see if he could do a build a week or so ago -
but no reply. Mingw produces larger dll files than the MS c
I did the following to my Makefile:
(1) remove -g from LDDLFLAGS
(2) remove -g -O2 from CCFLAGS
(3) change -O2 to -Os in OPTIMIZE
The '-g' is the biggest culprit, which adds huge amounts of extra stuff to
allow debuggers (and particularly gdb) to run well with the code. The
'-Os' optimises for
We need to agree a version number for the next release. I would propose
1.01 - I think that we should be using a 2-digit second part of the version
number to be CPAN friendly (See perldoc perlmodstyle), and don't see that
there's enough change to justify anything other than incrementing the min
Regarding that old binary compatibility thing: would a PPM built with MinGW
work with ActiveState Perl, or only under Cygwin?
Yes it would work with ActiveState Perl (there should be no compatibility
issues). I've been using PerlApp with MinGW built modules for a while now
(including win32-gui
Is there anyone with a V5.6 Perl who would like to see if they can build a
corresponding release candidate?
Yeah, I'll have a go:)
Cheers,
jez.
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 response
(zero from
Does anyone have any experience with any of the GUI test packages that
actually allow you to interact with a GUI in test, and if so what would
people recommend?
I work professionally as tester. GUI testing is part of my job :) (AutoIt,
Win32::GuiTest and Rational Robot)
Testing GUI apps can
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 checked/used in several plac
Hi,
I'm sure if you ask Aldo for permissions to commit changes, he'll add you
(or, indeed anyone else).
Cheers (and good work BTW).
jez.
I would like feedback on whether the following RFE can also be closed:
1150180 New gridlayout version
1145035 New gridlayout version.
Yes they can be closed.
Cheers,
jez.
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/
Nice, good job:)
I tried with Opera and it looks fine.
Suggestio
Hi,
I've been putting together an example of several of the techniques I use
when building a GUI. One of the things I do is to use lots of child windows
to encapsulate many controls and functionality into one logical package.
This works really well for me, but is still on the 'messy' side, so
This is a known bug with win32-gui.
It is fixed by using perl 5.7 or later or using the circular ref patch
Ok - I've created a tracker item so this issue isn't lost:)
https://sourceforge.net/tracker/index.php?func=detail&aid=1248578&group_id=16572&atid=116572
I've just ran that example under 5
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
I've just had a look at the Visual .Net environment and you can specify
the backcolor of a window (and the background image)
It would be possible to allow the -background option to take a
Win32::GUI::Brush as a value. This would allow bitmaps as patterns for the
background; but it would star
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?
Yes still crashes - on 5.8.7 and 5.6.1 both Win32::GUI 1.02, I'm on XP
Sp2...
Win32-GUI in both cases was the binary from sourceforge, not my own build.
Lea
I've done very limited testing on most of this, so any feedback (especially
negative) is very welcome.
I had a few issues building under mingw:
I had to change __MINGW__ in ImageList.xs to __MINGW32__, otherwise I get:
ImageList.o(.text+0xd2a):ImageList.cpp: undefined reference to
[EMAIL PROT
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 wind
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 kn
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 hand
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 exa
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.
Hi,
Had a problem with Imagelist.xs on Mingw - a couple of #ifdef __MINGW__
should be #ifdef __MINGW32__
Cheers,
jez.
- 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,
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
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,
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,
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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 = ($
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
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
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
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
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
Hi,
All these modules are now in the Win32-GUI source repository:
http://cvs.sourceforge.net/viewcvs.py/perl-win32-gui/
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
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,
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.
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
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
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
[ 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
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
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
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
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.
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
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'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
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
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";
The Custom Draw changes have been checked in.
Cheers,
jez.
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
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
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
(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
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
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
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
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:
As always, any reports of success and/or failure are welcome.
All ok under XP. Nice work.
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'
http://www.codeproject.com/useritems/com_in_c2.asp
http://www.codeproject.com/useritems/com_in_c3.asp
Quality.
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
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'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
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
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
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
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'
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
http://www.codeproject.com/com/com_in__c4.asp
http://www.codeproject.com/useritems/com_in_c5.asp
Cheers,
jez.
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
> 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
See the 'Changes' file in each subdirectory for highlights of any
significant changes.
She builds fine for me. Good job.
Cheers,
jez.
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.
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
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
>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
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
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
1 - 100 of 125 matches
Mail list logo
