[perl-win32-gui-users] Multiple ImageList bug
Hi,
I have some code that creates two ImageList objects:
our $ARCHIVE = new Win32::GUI::ImageList(64,64,ILC_COLOR32,0,100);
our $ICONS = new Win32::GUI::ImageList(16,16,ILC_COLOR32 | ILC_MASK,0,10);
don't worry about those constants, they're defined at the top of my script
as:
ILC_COLOR32 => 0x0020,
ILC_MASK=> 0x0001
A listview is set to use imagelist $ICONS, and another listview is set to
use imagelist $ARCHIVE. However, On adding even one image to $ARCHIVE, both
listviews always show images from $ARCHIVE. In fact $ICONS shows 16x16
segments of 64x64 images added to $ARCHIVE.
I'm adding images to $ICONS and $ARCHIVE like so:
$ICONS->Add(new Win32::GUI::Bitmap("resource/downgreen_i.bmp"),new
Win32::GUI::Bitmap("resource/down_m.bmp"));
# the above is done outside of any subroutine.
$ARCHIVE->Add(new Win32::GUI::Bitmap("archivetemp.bmp"));
# the above is done in an addfilestoarchive function.
I've no idea what's causing $ICONS to always show images from $ARCHIVE.
$ICONS is filled at the start of the application, $ARCHIVE is cleared and
filled whenever the addfilestoarchive sub is called.
Do my bitmap objects need to be persistent or something? I would have
thought perl's garbage collector would realise not to clear the anonymous
bitmap objects created with ImageList::Add.
Help!
Steve Pick
perl-win32-gui-users@lists.sourceforge.net
[perl-win32-gui-users] Additional: Multiple ImageList bug
Additional:
print $ARCHIVE."\n".$ICONS."\n";
gives:
Win32::GUI::ImageList=HASH(0x265e044)
Win32::GUI::ImageList=HASH(0x265e044)
Oh dear. Serious bug. They're in the same memory. I'll look at the
Win32::GUI code and see if this is a simple bug that even i can fix.
Steve
- Original Message -
From: "Steve Pick" <[EMAIL PROTECTED]>
To:
Sent: Sunday, October 26, 2003 8:12 PM
Subject: Multiple ImageList bug
> Hi,
>
> I have some code that creates two ImageList objects:
> our $ARCHIVE = new Win32::GUI::ImageList(64,64,ILC_COLOR32,0,100);
> our $ICONS = new Win32::GUI::ImageList(16,16,ILC_COLOR32 | ILC_MASK,0,10);
>
> don't worry about those constants, they're defined at the top of my script
> as:
> ILC_COLOR32 => 0x0020,
> ILC_MASK=> 0x0001
>
> A listview is set to use imagelist $ICONS, and another listview is set to
> use imagelist $ARCHIVE. However, On adding even one image to $ARCHIVE,
both
> listviews always show images from $ARCHIVE. In fact $ICONS shows 16x16
> segments of 64x64 images added to $ARCHIVE.
>
> I'm adding images to $ICONS and $ARCHIVE like so:
> $ICONS->Add(new Win32::GUI::Bitmap("resource/downgreen_i.bmp"),new
> Win32::GUI::Bitmap("resource/down_m.bmp"));
> # the above is done outside of any subroutine.
>
> $ARCHIVE->Add(new Win32::GUI::Bitmap("archivetemp.bmp"));
> # the above is done in an addfilestoarchive function.
>
> I've no idea what's causing $ICONS to always show images from $ARCHIVE.
> $ICONS is filled at the start of the application, $ARCHIVE is cleared and
> filled whenever the addfilestoarchive sub is called.
>
> Do my bitmap objects need to be persistent or something? I would have
> thought perl's garbage collector would realise not to clear the anonymous
> bitmap objects created with ImageList::Add.
>
> Help!
>
> Steve Pick
> perl-win32-gui-users@lists.sourceforge.net
>
>
>
[perl-win32-gui-users] Fixed: Multiple ImageList bug
Me again, sorry for the flood of posts.
Yes, it's a bug in GUI.pm
Win32::GUI::ImageList just uses $self without defining it like:
my $self = {};
So to fix the bug, just find Win32::GUI::ImageList in GUI.pm,
(it's on line 2141 in 0.0.558), and add a definition of $self as
above.
Steve
- Original Message -
From: "Steve Pick" <[EMAIL PROTECTED]>
To:
Sent: Sunday, October 26, 2003 8:32 PM
Subject: Additional: Multiple ImageList bug
> Additional:
>
> print $ARCHIVE."\n".$ICONS."\n";
>
> gives:
> Win32::GUI::ImageList=HASH(0x265e044)
> Win32::GUI::ImageList=HASH(0x265e044)
>
> Oh dear. Serious bug. They're in the same memory. I'll look at the
> Win32::GUI code and see if this is a simple bug that even i can fix.
>
> Steve
>
> - Original Message -
> From: "Steve Pick" <[EMAIL PROTECTED]>
> To:
> Sent: Sunday, October 26, 2003 8:12 PM
> Subject: Multiple ImageList bug
>
>
> > Hi,
> >
> > I have some code that creates two ImageList objects:
> > our $ARCHIVE = new Win32::GUI::ImageList(64,64,ILC_COLOR32,0,100);
> > our $ICONS = new Win32::GUI::ImageList(16,16,ILC_COLOR32 |
ILC_MASK,0,10);
> >
> > don't worry about those constants, they're defined at the top of my
script
> > as:
> > ILC_COLOR32 => 0x0020,
> > ILC_MASK=> 0x0001
> >
> > A listview is set to use imagelist $ICONS, and another listview is set
to
> > use imagelist $ARCHIVE. However, On adding even one image to $ARCHIVE,
> both
> > listviews always show images from $ARCHIVE. In fact $ICONS shows 16x16
> > segments of 64x64 images added to $ARCHIVE.
> >
> > I'm adding images to $ICONS and $ARCHIVE like so:
> > $ICONS->Add(new Win32::GUI::Bitmap("resource/downgreen_i.bmp"),new
> > Win32::GUI::Bitmap("resource/down_m.bmp"));
> > # the above is done outside of any subroutine.
> >
> > $ARCHIVE->Add(new Win32::GUI::Bitmap("archivetemp.bmp"));
> > # the above is done in an addfilestoarchive function.
> >
> > I've no idea what's causing $ICONS to always show images from $ARCHIVE.
> > $ICONS is filled at the start of the application, $ARCHIVE is cleared
and
> > filled whenever the addfilestoarchive sub is called.
> >
> > Do my bitmap objects need to be persistent or something? I would have
> > thought perl's garbage collector would realise not to clear the
anonymous
> > bitmap objects created with ImageList::Add.
> >
> > Help!
> >
> > Steve Pick
> > perl-win32-gui-users@lists.sourceforge.net
> >
> >
> >
>
[perl-win32-gui-users] Solution: flicker in Win32::GUI
Hi, I've recently been looking into the flickering resize in win32::gui. The most compatible solution to this I've found is extremely (and very annoyingly) simple. Just add the style WS_CLIPCHILDREN to your window or dialog box. I tried to implement double-buffering in GUI.xs (I was working with 0.0.558 at the time) but frankly I failed. Steve
[perl-win32-gui-users] Suggested addition to GUI.XS and some good news
Hi, Can anyone currently maintaining or debugging Win32::GUI add this to GUI.xs? It's a small change that lets you do SetParent() from Perl. I've written a dockable-windows routine (panes in your main window can be detached into windows) that works with my (very cool) packing grid object, which will be available to download soon. The docking routine needs to be able to change a window's parent (of course). This works with 665: ### # (@)METHOD:SetParent(VALUE) # Sets a windows parent handle # documentation. HWND SetParent(handle,value) HWND handle HWND value CODE: RETVAL = SetParent(handle, value); OUTPUT: RETVAL While I'm posting I might as well explain what the packing grid object does. It allows you to pack widgets into a grid. Heard that before? Well this does it with a difference. Each object you add to the grid can have properties assigned to it that dictate how it's aligned in the cell (left, center, right, top, middle, bottom) and whether it's stretched to fill the cell (vertically, horizontally or both). Each column or row in the grid can have a fixed width or a variable width. Variable-widthed columns or rows stretch to accommodate large widgets, and scale when the grid is resized (the entire grid can be given Width and Height). Still need more? Columns and rows can be resized. With my DragHandle object (which is a very simple label that can be dragged around the window using the mouse, and constrained horizontally and vertically, showing the appropriate cursors of course) you can implement mouse-dragable column/row sizes very easilly. These three modules are all almost complete, so you'll get them soon. They're all pure perl except for the one mod required for the dockable windows to work. Soon you'll be able to create slick apps *fast* :) Any questions, just ask. Steve
Re: [perl-win32-gui-users] Suggested addition to GUI.XS and some good news
Glenn,
> I'd be glad to incorporate your routine into my code, which I hope
> someday to get on SourceForge. However, I have a question about it
> first. I'm not sure i is 100% complete, though... aren't there
> Win32::GUI data structures that need to be altered also?
Probably. I do know that there's no way I could find of extracting the
parent using Win32::GUI's functions. There is no -parent field that
can be retrieved with something like
my $parent = $mainWin->{-parent};
but this works fine.
> And the other question, is where should it be added? I suppose to the
> main Win32::GUI package... Suggest a specific spot, though.
I've just tagged it onto the end of GUI.xs. I suppose a sensible spot would
be somewhere near wherever SetWindowLong() is, since the functions
are related (you can SetWindowLong(-8,hWnd), to set a window's parent
but that doesnt work properly and MSDN says "no! dont do this!! use
SetParent!")
> On approximately 11/15/2003 5:14 PM, came the following characters from
> the keyboard of Steve Pick:
> > Hi,
> >
> > Can anyone currently maintaining or debugging Win32::GUI add this to
GUI.xs?
> > It's a small change that lets you do SetParent() from Perl.
> >
> > I've written a dockable-windows routine (panes in your main window can
be
> > detached into
> > windows) that works with my (very cool) packing grid object, which will
be
> > available to download soon. The docking routine needs to be able to
change a
> > window's parent (of course).
> >
> > This works with 665:
> >
> >
###
> > # (@)METHOD:SetParent(VALUE)
> > # Sets a windows parent handle
> > # documentation.
> > HWND
> > SetParent(handle,value)
> > HWND handle
> > HWND value
> > CODE:
> > RETVAL = SetParent(handle, value);
> > OUTPUT:
> > RETVAL
> >
> > While I'm posting I might as well explain what the packing grid object
does.
> > It allows you to pack widgets into a grid. Heard that before? Well this
does
> > it with a difference. Each object you add to the grid can have
properties
> > assigned to it that dictate how it's aligned in the cell (left, center,
> > right, top, middle, bottom) and whether it's stretched to fill the cell
> > (vertically, horizontally or both). Each column or row in the grid can
have
> > a fixed width or a variable width. Variable-widthed columns or rows
stretch
> > to accommodate large widgets, and scale when the grid is resized (the
entire
> > grid can be given Width and Height).
> >
> > Still need more? Columns and rows can be resized. With my DragHandle
object
> > (which is a very simple label that can be dragged around the window
using
> > the mouse, and constrained horizontally and vertically, showing the
> > appropriate cursors of course) you can implement mouse-dragable
column/row
> > sizes very easilly.
> >
> > These three modules are all almost complete, so you'll get them soon.
> > They're all pure perl except for the one mod required for the dockable
> > windows to work. Soon you'll be able to create slick apps *fast* :)
> >
> > Any questions, just ask.
> >
> > Steve
> >
> >
> >
> > ---
> > This SF. Net email is sponsored by: GoToMyPC
> > GoToMyPC is the fast, easy and secure way to access your computer from
> > any Web browser or wireless device. Click here to Try it Free!
> > https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl
> > ___
> > Perl-Win32-GUI-Users mailing list
> > Perl-Win32-GUI-Users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
> >
> >
>
> --
> Glenn -- http://nevcal.com/
> ===
> Like almost everyone, I receive a lot of spam every day, much of it
> offering to help me get out of debt or get rich quick. It's ridiculous.
> -- Bill Gates
>
> And here is why it is ridiculous:
> The division that includes Windows posted an operating profit of $2.26
> billion on revenue of $2.81 billion.
> --from Reuters via
> http://biz.yahoo.com/rc/031113/tech_microsoft_msn_1.html
>
> So that's profit of over 400% of investment... with a bit more
> investment in Windows technology, particularly in the area of
> reliability, the profit percentage might go down, but so might the bugs
> and security problems? Seems like it would be a reasonable tradeo
Re: [perl-win32-gui-users] Solution: flicker in Win32::GUI
Hi, In my previous message I explained how to stop flickering in Win32::GUI. It turns out that this technique regularly causes widgets to leave imprints behind. Imprints dont seem to be left if widgets dont overlap, though. As I mentioned before I was already looking at painting off-screen, but I can't seem to get it to work. To solve this problem completely, Win32::GUI should do *all* painting in WM_PAINT. rather than painting individual widgets as they change size, and should ignore WM_ERASEBKGND messages. I tried to implement this, but I'm having trouble navigating the Win32::GUI source. If anyone wants to take on the flickering problem I'd be happy to help out with it. Steve - Original Message - From: "Steve Pick" <[EMAIL PROTECTED]> To: "Win32 GUI" Sent: Saturday, November 15, 2003 7:00 PM Subject: [perl-win32-gui-users] Solution: flicker in Win32::GUI > Hi, > > I've recently been looking into the flickering resize in win32::gui. The > most compatible solution to this I've found is extremely (and very > annoyingly) simple. Just add the style WS_CLIPCHILDREN to your window or > dialog box. > > I tried to implement double-buffering in GUI.xs (I was working with 0.0.558 > at the time) but frankly I failed. > > Steve > > > > --- > This SF. Net email is sponsored by: GoToMyPC > GoToMyPC is the fast, easy and secure way to access your computer from > any Web browser or wireless device. Click here to Try it Free! > https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl > ___ > Perl-Win32-GUI-Users mailing list > Perl-Win32-GUI-Users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users >
Re: [perl-win32-gui-users] Solution: flicker in Win32::GUI
Hi Jez, What you said about WM_ERASEBKGND is true, but the results are similar to setting WS_CLIPCHILDREN. If you block WM_ERASEBKGND messages in the NEM_WindowMsgLoop function in GUI_MessageLoops.cpp by adding something like: if(uMsg == WM_ERASEBKGND) return (LRESULT)1; You get huuuge amounts of streaking whenever anything is painted (obviously, because the background-erase is there so that this doesnt happen). That link is interesting, I'll give it a try. Thanks, Steve - Original Message - From: "Jeremy White" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; Sent: Sunday, November 16, 2003 5:16 PM Subject: Re: [perl-win32-gui-users] Solution: flicker in Win32::GUI > >From: "Steve Pick" <[EMAIL PROTECTED]> > >I've recently been looking into the flickering resize in win32::gui. The > >most compatible solution to this I've found is extremely (and very > >annoyingly) simple. Just add the style WS_CLIPCHILDREN to your window or > >dialog box. > > Steve, > > I've just tried this and it works...Well, sort of:) On XP, any window behind > the window being resized tear as they are redrawn. Also, for some reason > there seems to be a delay in some of the events to any window with > WS_CLIPCHILDREN set (!?). In my case, it means I can't use WS_CLIPCHILDREN > which is a shame since the application looks and feels so *much* better > without the flicker. > > Doing a little searching I came across this page > http://www.catch22.org.uk/tuts/flicker.asp > > === > WM_ERASEBKGND > The prime suspect is usually the WM_ERASEBKGND message. This message is sent > to a window when it's background needs to be erased. This happens because > windows are usually painted using a 2-stage process: > > WM_ERASEBKGND: Clear the background > WM_PAINT: Draw the contents on top > > > > Right then, how do we avoid erasing the background of a window? There are > two methods. > > Set the window's background brush to NULL. (Set the hbrBackground member of > the WNDCLASS structure to zero when you register the window class). > Return non-zero in the WM_ERASEBKGND message handler. > Any one of these will steps will prevent the WM_ERASEBKGND message from > clearing the window. The last option is usually easiest to implement: > > case WM_ERASEBKGND: > return 1; > It is also possible to prevent WM_ERASEBKGND when you invalidate and update > a window. The InvalidateRect API call's last parameter specifies whether or > not a portion of a window is to have it's background erased when it is next > redrawn. Specifying FALSE for this paramter prevents WM_ERASEBKGND from > being sent when the window is redrawn. > > InvalidateRect(hwnd, &rect, FALSE); > > > > I've no idea how to write a message handler for WM_ERASEBKGND - any ideas? > I've played with InvalidateRect in the past but didn't get anywhere fast. > > >I tried to implement double-buffering in GUI.xs (I was working with 0.0.558 > >at the time) but frankly I failed. > > Have a look at some of the code in this page: > > http://www.codeproject.com/gdi/flickerfree.asp > > "This article presents a class called CMemDC that encapsulates most of the > issues associated with writing to off-screen buffers. Adding CMemDC to an > existing application or MFC Active X control is nearly trivial. > > Modifying an MFC Application to use CMemDC > Add the file memdc.h in your project. > Add the line #include "memdc.h" to stdafx.h. > Add a windows message handler for WM_ERASEBKGND. " > > Would it be hard to incorporate it into GUI.xs somehow? The code is > opensource. > > Cheers, > > jez. > > _ > Find a cheaper internet access deal - choose one to suit you. > http://www.msn.co.uk/internetaccess > > > > --- > This SF. Net email is sponsored by: GoToMyPC > GoToMyPC is the fast, easy and secure way to access your computer from > any Web browser or wireless device. Click here to Try it Free! > https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl > ___ > Perl-Win32-GUI-Users mailing list > Perl-Win32-GUI-Users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users >
Re: [perl-win32-gui-users] Solution: flicker in Win32::GUI
Jeremy, > Doing a little searching I came across this page > http://www.catch22.org.uk/tuts/flicker.asp The page gives good advice and does exactly what I've already done with double-buffering. However the problem is that double buffering requires that widgets are drawn when the main window receives WM_PAINT. Win32::GUI by default doesnt seem to handle WM_PAINT at all in the window event loop, and widgets all seem to be drawn somewhere else, and I'm not experienced enough to fix that. > Have a look at some of the code in this page: > > http://www.codeproject.com/gdi/flickerfree.asp I dont think I can use this, it seems to do exactly what I've already tried to implement with my own code, but it doesnt look like it's for drawing *widgets*. While it claims that converting an MFC app to flickerless mode is "easy" it actually looks too difficult for me to do it with Win32::GUI, for exactly the same reason as given above; I cant find where widgets are drawn. Steve - Original Message - From: "Jeremy White" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; Sent: Sunday, November 16, 2003 5:16 PM Subject: Re: [perl-win32-gui-users] Solution: flicker in Win32::GUI > >From: "Steve Pick" <[EMAIL PROTECTED]> > >I've recently been looking into the flickering resize in win32::gui. The > >most compatible solution to this I've found is extremely (and very > >annoyingly) simple. Just add the style WS_CLIPCHILDREN to your window or > >dialog box. > > Steve, > > I've just tried this and it works...Well, sort of:) On XP, any window behind > the window being resized tear as they are redrawn. Also, for some reason > there seems to be a delay in some of the events to any window with > WS_CLIPCHILDREN set (!?). In my case, it means I can't use WS_CLIPCHILDREN > which is a shame since the application looks and feels so *much* better > without the flicker. > > Doing a little searching I came across this page > http://www.catch22.org.uk/tuts/flicker.asp > > === > WM_ERASEBKGND > The prime suspect is usually the WM_ERASEBKGND message. This message is sent > to a window when it's background needs to be erased. This happens because > windows are usually painted using a 2-stage process: > > WM_ERASEBKGND: Clear the background > WM_PAINT: Draw the contents on top > > > > Right then, how do we avoid erasing the background of a window? There are > two methods. > > Set the window's background brush to NULL. (Set the hbrBackground member of > the WNDCLASS structure to zero when you register the window class). > Return non-zero in the WM_ERASEBKGND message handler. > Any one of these will steps will prevent the WM_ERASEBKGND message from > clearing the window. The last option is usually easiest to implement: > > case WM_ERASEBKGND: > return 1; > It is also possible to prevent WM_ERASEBKGND when you invalidate and update > a window. The InvalidateRect API call's last parameter specifies whether or > not a portion of a window is to have it's background erased when it is next > redrawn. Specifying FALSE for this paramter prevents WM_ERASEBKGND from > being sent when the window is redrawn. > > InvalidateRect(hwnd, &rect, FALSE); > > > > I've no idea how to write a message handler for WM_ERASEBKGND - any ideas? > I've played with InvalidateRect in the past but didn't get anywhere fast. > > >I tried to implement double-buffering in GUI.xs (I was working with 0.0.558 > >at the time) but frankly I failed. > > Have a look at some of the code in this page: > > http://www.codeproject.com/gdi/flickerfree.asp > > "This article presents a class called CMemDC that encapsulates most of the > issues associated with writing to off-screen buffers. Adding CMemDC to an > existing application or MFC Active X control is nearly trivial. > > Modifying an MFC Application to use CMemDC > Add the file memdc.h in your project. > Add the line #include "memdc.h" to stdafx.h. > Add a windows message handler for WM_ERASEBKGND. " > > Would it be hard to incorporate it into GUI.xs somehow? The code is > opensource. > > Cheers, > > jez. > > _ > Find a cheaper internet access deal - choose one to suit you. > http://www.msn.co.uk/internetaccess > > > > --- > This SF. Net email is sponsored by: GoToMyPC > GoToMyPC is the fast, easy and secure way to access your computer from > any Web browser or wireless device. Click here to Try it Free! > https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl > ___ > Perl-Win32-GUI-Users mailing list > Perl-Win32-GUI-Users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users >
[perl-win32-gui-users] additional fix for cursors
In addition to Glenn Linderman's fix for resize cursors this should be put in (@)INTERNAL:Create(%OPTIONS) near the top: perlcs.hCursor = LoadCursor(NULL, IDC_ARROW); I've put it just below the line that reads perlcs.iEventModel = PERLWIN32GUI_EM_BYNAME; This will stop the cursor remaining as a resize handle, hourglass etc when moved inside the window. Steve
Re: [perl-win32-gui-users] Windows XP Color Bug
Hi, This happens with most MFC apps. I havent found a way to fix it. This is a crazy bug, most MFC apps will probably exhibit this on windows xp. Microsoft are crazy for not detecting MFC and auto-converting. The only fix is to disable Playskool Mode in windows xp, which you should have done anyway unless you're 5 years old :) Steve - Original Message - From: Chris To: perl-win32-gui-users@lists.sourceforge.net Sent: Friday, November 21, 2003 1:25 AM Subject: [perl-win32-gui-users] Windows XP Color Bug Does anyone have a way to resolve the windows xp color bug? If so, I think it would be a wonderful thing to include.
Re: Re: [perl-win32-gui-users] Windows XP Color Bug
That's a *dreadful* "solution".
1. It doesnt "fix" anything it just makes the background grey.
2. You used a billion labels made wide with spaces instead of using ONE with
-width => $win->Width, -height => $win->Height
3. This would probably screw up capturing events, would make resizing
excrutiatingly slow and flickery, and is generally just *bad*.
Do not do this, use one label until something better comes along that will set
the background correctly (maybe by setting window class color properties? I
have 2k so i cant check it out):
$win->AddLabel ($win,
-name => "background",
-notify => 0,
-width => $win->Width(),
-height => $win->Height(),
-top => 0,
-left => 0
);
Add the label before adding anything else. This will cause uber-flicker.
Steve
- Original Message -
From: Chris
To: perl-win32-gui-users@lists.sourceforge.net
Sent: Friday, November 21, 2003 6:04 PM
Subject: Re: Re: [perl-win32-gui-users] Windows XP Color Bug
However, some people have hacked the playschool mode, to make it allow custom
themes, which was simply done by removeing the check to make sure the themes
are signed, so bow some of use have very nice looking gui's. I found a tempary
fix for the issue, but it's not very cool, for ($zzz=0; $zzz < 1000;
$zzz=$zzz+13) { $Wmain->AddLabel( -name => "back$zzz", -text => "
", -wrap => 0, -top => $zzz, ); }
this will fill the window with the proper color, it's just not the best.
Hi,
This happens with most MFC apps. I havent found a way to fix it. This is a
crazy bug, most MFC apps will probably exhibit this on windows xp. Microsoft
are crazy for not detecting MFC and auto-converting.
The only fix is to disable Playskool Mode in windows xp, which you should
have done anyway unless you're 5 years old :)
Steve
- Original Message -
From: Chris
To: perl-win32-gui-users@lists.sourceforge.net
Sent: Friday, November 21, 2003 1:25 AM
Subject: [perl-win32-gui-users] Windows XP Color Bug
Does anyone have a way to resolve the windows xp color bug? If so, I think it
would be a wonderful thing to include.
Re: Re: [perl-win32-gui-users] Windows XP Color Bug
Right,
I've found this link which may fix the problem of Win32::GUI not using Windows
XP themes if they are available. However I don't have Windows XP, so someone
who does have WinXP and Visual Studio .NET (2003?) might be able to try
creating these crazy manifests:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwxp/html/xptheming.asp
- Original Message -
From: Steve Pick
To: Chris ; perl-win32-gui-users@lists.sourceforge.net
Sent: Friday, November 21, 2003 6:28 PM
Subject: Re: Re: [perl-win32-gui-users] Windows XP Color Bug
That's a *dreadful* "solution".
1. It doesnt "fix" anything it just makes the background grey.
2. You used a billion labels made wide with spaces instead of using ONE with
-width => $win->Width, -height => $win->Height
3. This would probably screw up capturing events, would make resizing
excrutiatingly slow and flickery, and is generally just *bad*.
Do not do this, use one label until something better comes along that will
set the background correctly (maybe by setting window class color properties? I
have 2k so i cant check it out):
$win->AddLabel ($win,
-name => "background",
-notify => 0,
-width => $win->Width(),
-height => $win->Height(),
-top => 0,
-left => 0
);
Add the label before adding anything else. This will cause uber-flicker.
Steve
- Original Message -
From: Chris
To: perl-win32-gui-users@lists.sourceforge.net
Sent: Friday, November 21, 2003 6:04 PM
Subject: Re: Re: [perl-win32-gui-users] Windows XP Color Bug
However, some people have hacked the playschool mode, to make it allow
custom themes, which was simply done by removeing the check to make sure the
themes are signed, so bow some of use have very nice looking gui's. I found a
tempary fix for the issue, but it's not very cool, for ($zzz=0; $zzz < 1000;
$zzz=$zzz+13) { $Wmain->AddLabel( -name => "back$zzz", -text => "
", -wrap => 0, -top => $zzz, ); }
this will fill the window with the proper color, it's just not the best.
Hi,
This happens with most MFC apps. I havent found a way to fix it. This is a
crazy bug, most MFC apps will probably exhibit this on windows xp. Microsoft
are crazy for not detecting MFC and auto-converting.
The only fix is to disable Playskool Mode in windows xp, which you should
have done anyway unless you're 5 years old :)
Steve
- Original Message -
From: Chris
To: perl-win32-gui-users@lists.sourceforge.net
Sent: Friday, November 21, 2003 1:25 AM
Subject: [perl-win32-gui-users] Windows XP Color Bug
Does anyone have a way to resolve the windows xp color bug? If so, I think
it would be a wonderful thing to include.
Re: Re: [perl-win32-gui-users] Windows XP Color Bug
Sorry :)
I had a bad day and this was plain nasty so i reacted in quite an elitist way.
Anyway, someone with more skill than both of us has provided a better solution.
I'm glad you're here and paying attention, Win32::GUI::Users needs everyone it
can get :)
Steve
- Original Message -
From: Chris
To: perl-win32-gui-users@lists.sourceforge.net
Sent: Friday, November 21, 2003 11:49 PM
Subject: RE: Re: [perl-win32-gui-users] Windows XP Color Bug
I told you mine was dirty, and not very good, believe me now?
--
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Pick
Sent: Friday, November 21, 2003 10:29 AM
To: Chris; perl-win32-gui-users@lists.sourceforge.net
Subject: Re: Re: [perl-win32-gui-users] Windows XP Color Bug
That's a *dreadful* "solution".
1. It doesnt "fix" anything it just makes the background grey.
2. You used a billion labels made wide with spaces instead of using ONE with
-width => $win->Width, -height => $win->Height
3. This would probably screw up capturing events, would make resizing
excrutiatingly slow and flickery, and is generally just *bad*.
Do not do this, use one label until something better comes along that will
set the background correctly (maybe by setting window class color properties? I
have 2k so i cant check it out):
$win->AddLabel ($win,
-name => "background",
-notify => 0,
-width => $win->Width(),
-height => $win->Height(),
-top => 0,
-left => 0
);
Add the label before adding anything else. This will cause uber-flicker.
Steve
- Original Message -
From: Chris
To: perl-win32-gui-users@lists.sourceforge.net
Sent: Friday, November 21, 2003 6:04 PM
Subject: Re: Re: [perl-win32-gui-users] Windows XP Color Bug
However, some people have hacked the playschool mode, to make it allow
custom themes, which was simply done by removeing the check to make sure the
themes are signed, so bow some of use have very nice looking gui's. I found a
tempary fix for the issue, but it's not very cool, for ($zzz=0; $zzz < 1000;
$zzz=$zzz+13) { $Wmain->AddLabel( -name => "back$zzz", -text => "
", -wrap => 0, -top => $zzz, ); }
this will fill the window with the proper color, it's just not the best.
Hi,
This happens with most MFC apps. I havent found a way to fix it. This is a
crazy bug, most MFC apps will probably exhibit this on windows xp. Microsoft
are crazy for not detecting MFC and auto-converting.
The only fix is to disable Playskool Mode in windows xp, which you should
have done anyway unless you're 5 years old :)
Steve
- Original Message -
From: Chris
To: perl-win32-gui-users@lists.sourceforge.net
Sent: Friday, November 21, 2003 1:25 AM
Subject: [perl-win32-gui-users] Windows XP Color Bug
Does anyone have a way to resolve the windows xp color bug? If so, I think
it would be a wonderful thing to include.
Re: [perl-win32-gui-users] Help with Win32::Gui::Graphic, WM_Paint and InvalidateRect
The Graphic object has a Paint event in which all your painting should be
done. If you find that the graphic is going blank on resize or something,
then you should call the Paint() event there too.
see http://jeb.ca/perl/win32-gui-docs/index.pl/win32-gui-graphic for a
simple example. You should VALIDATE not invalidate.
Steve
- Original Message -
From: <[EMAIL PROTECTED]>
To:
Sent: Sunday, November 23, 2003 5:58 PM
Subject: [perl-win32-gui-users] Help with Win32::Gui::Graphic, WM_Paint and
InvalidateRect
> Hi,
> I am trying to draw an interactive graph in a window, and I don't want to
use
> GD, ImageMagick, Freeimage or any other libraries because of portability
> issues.
> However, I can't figure out how to correctly use Win32::GUI::Graphic,
> Win32::GUI::DC, WM_Paint and InvalidateRect. I've tried reading through
some of
> my MSDN docs that came with my copy of VC++ 6.0, but I couldn't figure
this
> out.
> I also looked through the samples directory in the Win32::GUI
distribution, but
> none of them use the Graphic object or _Paint handlers.
>
> Can _Paint messages be generated only for Win32::GUI::Graphic objects?
> How do I tell my program to redraw a window object?
> What will cause a window object to be redrawn?
> Does the entire window object have to be redrawn or can an area of
> specified coordinates within the window object be redrawn?
> What are the options that can be set in a "new Win32::GUI::Graphic"? I
> cannot find them in GUI.xs.
> Can someone share a simple, working example of the usage of
> Win32::GUI::Graphic, WM_Paint, and InvalidateRect so that I can get
> started on experimentation?
>
> Thanks in advance,
> Rod
>
> Here is my code so far:
>
> #!c:/Perl/bin/wperl.exe -w
> use strict;
> use Win32::GUI;
>
> my $topwin = new Win32::GUI::Window(
> -name => 'topwin',
> -title => 'window',
> -width => 800,
> -height => 600,
> -pos => [125,75],
> -maximizebox => "0",
> -minimizebox => "0",
> -resizable => "0"
> );
> my $graph = new Win32::GUI::Graphic(
> $topwin,
>-name => "graph"
> );
>
> $topwin->Show();
> $topwin->graph->InvalidateRect(1);
> Win32::GUI::Dialog();
>
> sub topwin_Terminate {
> return -1;
> }
> sub graph_Paint {
> my $W = $topwin->ScaleWidth;
> my $H = $topwin->ScaleHeight;
> my $DC = $topwin->graph->GetDC;
> my $P = new Win32::GUI::Pen(
> -color => 'BLACK',
> -width => 1,
> );
> $DC->SelectObject($P);
> $DC->BeginPath();
> $DC->MoveTo(50,50);
> $DC->LineTo(45,75);
> $DC->EndPath();
> $DC->StrokePath();
> $DC->Validate;
> }
> exit;
>
>
> This message was sent using IMP, the Internet Messaging Program.
>
>
>
> ---
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive? Does it
> help you create better code? SHARE THE LOVE, and help us help
> YOU! Click Here: http://sourceforge.net/donate/
> ___
> Perl-Win32-GUI-Users mailing list
> Perl-Win32-GUI-Users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
>
Re: [perl-win32-gui-users] Help with Win32::Gui::Graphic, WM_Paint and InvalidateRect
An additional note:
why is there a problem with portability? I suggest you try the (horrible)
ImageMagick library if you want something truely portable. I say ImageMagick
is horrible because it crashes a *lot* if you use threads, and the perl
interface is badly documented. But you may want to give it a shot. it's
available for everything.
I went off imagemagick because the binary download is something like 20mb,
and i didnt want THAT in my redistributable.
Steve
- Original Message -
From: "Jeremy White" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>;
Sent: Sunday, November 23, 2003 6:51 PM
Subject: Re: [perl-win32-gui-users] Help with Win32::Gui::Graphic, WM_Paint
and InvalidateRect
> Hi,
>
> All I can say is that DC/Paint does work - and quite well. Although it
does
> take a while to get your head around things. In the end I did go for using
> GD as the graphics engine (along with DIBitmap) since there was a
> performance issue using native windows drawing.
>
> Below is an example from the from 558. I could probably dig out a
> paint/validate example if that would help.
>
> Cheers,
>
> jez.
>
> use Win32::GUI;
>
> $Menu = Win32::GUI::MakeMenu(
> "&Draw" => "&Draw",
> "> &Dots" => "DrawDots",
> "> &Lines" => "DrawLines",
> "> &Boxes" => { -name => "DrawBoxes", -checked => 1 },
> "> &Circles" => "DrawCircles",
> );
>
> $Win = new Win32::GUI::Window(
> -left => 100,
> -top=> 100,
> -width => 300,
> -height => 300,
> -name => "Window",
> -text => "Win32::GUI drawing demo",
> -menu => $Menu,
> );
>
> $Timer = $Win->AddTimer("Timer1", 50);
>
> srand();
>
> $Win->Show();
> Win32::GUI::Dialog();
>
> sub Window_Terminate {
> return -1;
> }
>
> sub DrawDots_Click {
> $Menu->{DrawDots}->Checked(1);
> $Menu->{DrawLines}->Checked(0);
> $Menu->{DrawBoxes}->Checked(0);
> $Menu->{DrawCircles}->Checked(0);
> $Win->InvalidateRect(1);
> }
>
> sub DrawLines_Click {
> $Menu->{DrawDots}->Checked(0);
> $Menu->{DrawLines}->Checked(1);
> $Menu->{DrawBoxes}->Checked(0);
> $Menu->{DrawCircles}->Checked(0);
> $Win->InvalidateRect(1);
> }
>
> sub DrawBoxes_Click {
> $Menu->{DrawDots}->Checked(0);
> $Menu->{DrawLines}->Checked(0);
> $Menu->{DrawBoxes}->Checked(1);
> $Menu->{DrawCircles}->Checked(0);
> $Win->InvalidateRect(1);
> }
>
> sub DrawCircles_Click {
> $Menu->{DrawDots}->Checked(0);
> $Menu->{DrawLines}->Checked(0);
> $Menu->{DrawBoxes}->Checked(0);
> $Menu->{DrawCircles}->Checked(1);
> $Win->InvalidateRect(1);
> }
>
> sub Timer1_Timer {
> my $W = $Win->ScaleWidth;
> my $H = $Win->ScaleHeight;
> my $DC = $Win->GetDC;
> my $left;
> my $top;
> my $right;
> my $bottom;
> my $P;
> my $B;
>
> if($Menu->{DrawDots}->Checked) {
> for(1..20) {
> $DC->SetPixel(
> rand()*$W,
> rand()*$H,
> [ rand()*255, rand()*255, rand()*255 ],
> );
> }
> } elsif($Menu->{DrawBoxes}->Checked) {
> $P = new Win32::GUI::Pen(
> -color => [ rand()*255, rand()*255, rand()*255 ],
> -width => rand()*5,
> );
> $B = new Win32::GUI::Brush(
> [ rand()*255, rand()*255, rand()*255 ]
> );
> $DC->SelectObject($P);
> $DC->SelectObject($B);
> $left = rand()*$W;
> $top= rand()*$H;
> $right = $left + rand()*($W-$left);
> $bottom = $top + rand()*($H-$top);
> $DC->Rectangle($left, $top, $right, $bottom);
> } elsif($Menu->{DrawCircles}->Checked) {
> $P = new Win32::GUI::Pen(
> -color => [ rand()*255, rand()*255, rand()*255 ],
> -width => rand()*5,
> );
> $B = new Win32::GUI::Brush(
> [ rand()*255, rand()*255, rand()*255 ]
> );
> $DC->SelectObject($P);
> $DC->SelectObject($B);
> $left = rand()*$W;
> $top= rand()*$H;
> $right = $left + rand()*($W-$left);
> $bottom = $top + rand()*($H-$top);
> $DC->Ellipse($left, $top, $right, $bottom);
> } elsif($Menu->{DrawLines}->Checked) {
> $P = new Win32::GUI::Pen(
> -color => [ rand()*255, rand()*255, rand()*255 ],
> -width => rand()*5,
> );
> $DC->SelectObject($P);
> $DC->BeginPath();
> $DC->MoveTo(rand()*$W, rand()*$H);
> $DC->LineTo(rand()*$W, rand()*$H);
> $DC->EndPath();
> $DC->StrokePath();
> }
> }
>
>
>
>
> >From: [EMAIL PROTECTED]
> >To: perl-win32-gui-users@lists.sourceforge.net
> >Subject: [perl-win32-gui-users] Help with Win32::Gui::Graphic, WM_Paint
and
> >InvalidateRect
> >Date: Sun, 23 Nov 2003 11:58:55 -0600
> >
> >Hi,
> >I am trying to draw an interactive graph in a window, and I don't want to
> >use
> >GD, ImageMagick, Freeimage or any other libraries because of portability
Re: [perl-win32-gui-users] TextField entry
Hi,
I've just submitted an addition for Win32::GUI v0.0.665 which adds the
keycode and extra info as arguments to the onKeyDown handler. This allows
you to do this, to create a single-line text entry field which detects a
press of the Enter key.
my $textfield = new Win32::GUI::Textfield ($win,
-name => "textfield1",
-left => 0,
-top => 0,
-width => 100,
-height => 20
-multiline => 1,
-autohscroll => 1,
-autovscroll => 0,
-onKeyDown => \&keydown,
);
sub keydown {
my ($additional_data,$keycode) = @_;
if($keycode == 13) {
print "Enter has been pressed.\n";
}
}
Hopefully this will be included in the next CVS update, and will allow you
to get Enter presses without using that nasty "default button" method.
Steve
- Original Message -
From: "Johan Lindstrom" <[EMAIL PROTECTED]>
To:
Sent: Wednesday, November 26, 2003 2:04 PM
Subject: Re: [perl-win32-gui-users] TextField entry
> At 01:58 2003-11-26, Ross Clunie wrote:
> >I would like to be able to use the ENTER key as an event trigger for a
> >textfeild. I have the _LostFocus event set and this works when the tab
key
> >is used but I would like ENTER key to emulate this function. Is it
poosible.
>
> Fake it by adding a button that is -ok and/or -default (I think -ok is an
> option proper). Turn off the -tabstop and put the button outside the
window
> (e.g. at 10, 10).
>
> The button's _Click event will be triggered when you press Enter in the
> Textfield.
>
>
> /J
>
> -- --- -- -- -- -- - - -
> Johan LindströmSourcerer @ Boss Casinos [EMAIL PROTECTED]
>
> Latest bookmark: "Oracle9i Database Concepts -- Contents"
>
> dmoz (1 of 7): /Computers/Internet/E-mail/Free/ 9
>
>
>
> ---
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive? Does it
> help you create better code? SHARE THE LOVE, and help us help
> YOU! Click Here: http://sourceforge.net/donate/
> ___
> Perl-Win32-GUI-Users mailing list
> Perl-Win32-GUI-Users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
>
Re: [perl-win32-gui-users] DC fullscreen
You can get the DC of the screen like this (ripped from
http://jeb.ca/perl/win32-gui-docs/index.pl/win32-gui-dc):
$Screen = new Win32::GUI::DC("DISPLAY");
Then you can write what you like all over it. However this isn't great. You
can also make a window with the style WS_CHILD, which has no titlebar or
border, and call $win->Maximize() on startup to make it fill the whole
screen (except for the taskbar if that's not on auto-hide), then you can
paint in that window's DC (obtain it with $win->GetDC()).
I hope one of these helps.
Steve
- Original Message -
From: "Peter Janson" <[EMAIL PROTECTED]>
To:
Sent: Wednesday, November 26, 2003 9:14 PM
Subject: [perl-win32-gui-users] DC fullscreen
> Hi!
>
> Is there a way to whrite graphics in "fullscreen" mode?
> One could always place the window at -xx, -xx and make the window a trifle
> bigger than the actual screen resolution, but that solution feels "dirty".
>
> Is there a better way?
>
> /Peter Janson
>
>
>
> ---
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive? Does it
> help you create better code? SHARE THE LOVE, and help us help
> YOU! Click Here: http://sourceforge.net/donate/
> ___
> Perl-Win32-GUI-Users mailing list
> Perl-Win32-GUI-Users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
>
Re: [perl-win32-gui-users] Exchange Admin!
That isn't really a Win32::GUI question. I've done stuff like this with an Active Directory server before, but can't remember how i did it. In the end i think i had to use Win32::API and Win32::OLE, since Net::LDAP just didn't work for me. Check out MSDN, i learned a lot from there, i can probably get you some code on Monday, but it's at work at the moment. Steve - Original Message - From: "Jaun Keeve" <[EMAIL PROTECTED]> To: Sent: Friday, November 28, 2003 7:35 AM Subject: [perl-win32-gui-users] Exchange Admin! > Hi All > > I have a text file that lists 1000+ distribution lists and email addresses of the users belonging to the lists. I am trying to automate the process of creating the contacts, the dl's and adding the contacts to the appropriate dl's in Exchange. I am able to query AD and get info using ldap, but with limited knowledge of perl I am unable to create contacts or dl's. I am sure this must be achievable using win32::ole or net::ldap, If anyone has any suggestions or advice it will be much appreciated. > > Many thanks, > Jaun > > > --- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > ___ > Perl-Win32-GUI-Users mailing list > Perl-Win32-GUI-Users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users > >
Re: [perl-win32-gui-users] Progress bar's
Oh dear. I tried so much to get this to work, mucking about with classes and stuff and I couldn't figure out how. Best way I found is to paint your own damn rectangle using a Graphic object :) I realise that's not ideal, but it's the best solution I've got i'm afraid. I'd be interested as well if anyone can enlighten me on how to do coloured progress bars. Steve - Original Message - From: Chris To: perl-win32-gui-users@lists.sourceforge.net Sent: Monday, December 01, 2003 6:15 PM Subject: [perl-win32-gui-users] Progress bar's Okay, I need to know how I can specify a custom color for a progress bar, so it can be red or blue, depending on the status of my application. I've tried to do it by changing the -fill and - color commands and have had no luck, if anyone knows anything about how to do this please help, I've spent 4 hours trying to figure it out now.
Re: [perl-win32-gui-users] Coloring again,
Say what?
What exactly is the problem? Reading the file or applying the colors?
- Original Message -
From: Chris
To: perl-win32-gui-users@lists.sourceforge.net
Sent: Tuesday, December 02, 2003 3:21 AM
Subject: [perl-win32-gui-users] Coloring again,
I'm trying to read in some custom colors though a configuration file. But
they don't seem to work, here's what I have so far.
sub skin {
if ($settings{'skin'} ne 'default') {
if (-e("./$settings{'skin'}/skin.ini")){
logit("Skinning file exists");
$sk=1;
} else {
logit("Skin Files isn't here");
goto DefaultSkin;
}
if ($sk) {
open(TMP, "./$settings{'skin'}/skin.ini");
@skin = ;
close(TMP);
foreach $line (@skin) {
if ($line =~ /(.*?)=(.*?)$/i)
{
$skin{$1}=$2;
}
logit("\$skin{$1}=$skin{$1}");
}
}
} else {
DefaultSkin:
$skin{urlcolor} = 0xFF;
$skin{errorcolor} = 0xFF;
$skin{normalcolor} = 0x00;
$skin{icon} = "icon.ico";
}
}
My custom skin file looks like
urlcolor=0x00FF00
errorcolor=0xFF
normalcolor=0xFF
icon=icon.ico
if someone could help me resile my issue, it would help
[perl-win32-gui-users] Fixed in 670
Hi, The list of fixes is available here: http://sourceforge.net/project/shownotes.php?group_id=16572&release_id=203389 Steve - Original Message - From: "Morbus Iff" <[EMAIL PROTECTED]> To: "Laurent ROCHER" <[EMAIL PROTECTED]>; "Win32GUI" Sent: Sunday, December 14, 2003 9:39 PM Subject: Re: [perl-win32-gui-users] Win32-GUI Release 0.0.670 > >A new Win32::GUI release is availlable. > >This release come from 0.0.665 Fix CVS branch. > > Is there a list of fixes? > > -- > Morbus Iff ( be realistic. demand the impossible. ) > Technical: http://www.oreillynet.com/pub/au/779 > Culture: http://www.disobey.com/ and http://www.gamegrene.com/ > icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus > > > --- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > ___ > Perl-Win32-GUI-Users mailing list > Perl-Win32-GUI-Users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users >
[perl-win32-gui-users] Merry Christmas
Just wanted to wish everyone on the list a Merry Christmas and offer my thanks for all your assistance and work on improving Win32::GUI. Cheers, Steve Pick [EMAIL PROTECTED]
[perl-win32-gui-users] CVS commit
Hi,
I've committed the updated hooks code in 665-Fix. See GUI.xs for the
documentation for the Hook and UnHook functions.
What's new:
Hooks work in Old Event Model and New Event Model
You can hook WM_COMMAND and WM_NOTIFY submessages if you call Hook on a
child widget (like a button, for example)
You can now add multiple hooks for each message. Calling Hook(MSG, CODEREF)
no longer replaces the current handler returning the old handler for that
hook (which didnt work properly anyway) but adds another handler for the
specified message. Returns true if adding succeeded or false otherwise
(normally if it returns false then the hook has already been defined).
When removing hooks they are identified by coderef, so this is WRONG:
$win->Hook(WM_MOVE, sub { print "moved!" });
$win->UnHook(WM_MOVE, sub { print "moved!" });
In that case, UnHook will return false and the hook will not be removed
because the codref passed to the UnHook call will be different to the one
passed to Hook. You should do it like this:
$movedsub = sub { print "moved!\n" };
$win->Hook(WM_MOVE, $movedsub);
$win->UnHook(WM_MOVE, $movedsub);
Some more arguments have been added to the handler callbacks. These are
$type and $msg. $msg is simply the code for the message that triggered the
hook, and $type is 0 for normal window message, WM_NOTIFY for WM_NOTIFY
messages, and WM_COMMAND for WM_COMMAND messages. $type is there because
often WM_COMMAND submessages, WM_NOTIFY submessages and normal messages can
conflict so it's good to check if your handler has been called by the
correct type of message. Yes this is a nasty kludge, but i chose it because
all the other options would have taken too long to get right or would have
been less intuitive.
Doing UnHook() inside a hook handler seems to be safe (after a lot of
bugfixing and tweaks to make it safe), but if you find any problems (usually
crashes) with this kind of thing let me know.
Steve Pick
[EMAIL PROTECTED]
Re: [perl-win32-gui-users] pointers
Hi chris. I recommend you download my plugin Winamp track-spamming perl script for XChat (www.xchat.org) from http://baxpace.com/?page=projects and look at the code. It obtains the title from the current winamp window title, and also gets stuff like bitrate, frequency and kbps. It uses Win32::API to obtain the values. I hope it helps, not sure if it works with Winamp 5. Steve - Original Message - From: "Chris" <[EMAIL PROTECTED]> To: Sent: Friday, January 09, 2004 5:09 PM Subject: [perl-win32-gui-users] pointers > I'm working on controlling winamp, but I have a small issue. When I get the > song name from winamp, it returns it as a pointer, and I'm not sure how to > handle the pointer, so that I can get text output from it. Thanks > > > > > --- > This SF.net email is sponsored by: Perforce Software. > Perforce is the Fast Software Configuration Management System offering > advanced branching capabilities and atomic changes on 50+ platforms. > Free Eval! http://www.perforce.com/perforce/loadprog.html > ___ > Perl-Win32-GUI-Users mailing list > Perl-Win32-GUI-Users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users >
Re: [perl-win32-gui-users] General Perl Text Extraction doubt
Hi, I suggest you obtain HTML::Parser from CPAN (it might be included with ActivePerl - dont know). http://search.cpan.org You're probably going to need to be VERY accomplished to acheive something like this :/ while it's pretty easy to regex out phone numbers and things, it's not easy to obtain the other data. You'd need some kind of artificial intelligence routines to recognise every possible organisation of the data, I wouldn't quite know where to begin. As other people have said, this list is primarilly for Win32::GUI, so if your questions aren't win32::gui oriented you would probably get better results from perlmonks or some other list. Steve - Original Message - From: "#SHUCHI MITTAL#" <[EMAIL PROTECTED]> To: Sent: Thursday, January 08, 2004 5:04 PM Subject: [perl-win32-gui-users] General Perl Text Extraction doubt > Hi all > > Since everyone here is a perl expert and im a total newbie i would be very very grateful if someone could help me out with my doubts. > > I am doing a project to develop a student professor system including databases etc. To start off I need lots of professor data from various websites of educational institutions( for populating my database) . To extract this data and get started I decided to use perl since its text extraction capabilities are known to one n all. > > The problem is all these sites have a totally different HTML format and structure and differ in which the info of all profs is listed, and I cant seem to come up with a generic PERL code to extract this data and put it in text files on my local hard disk. Therefore I think ill need to use REGEX and PATTERN MATCHING to do the task but im not sure how to go about it. I wrote one code that works with www.ntu.edu.sg/sce/staffacad.asp but this is way to specific and doesnt work with any other staff sites.! > I need to do the following: > > 1. Visit the base site of any institute and extract professor information which includes NAME,EMAIL,DEGREE,RESEARCH INTERESTS AND PUBLICATIONS RELEASED > 2. For publications the listing either appears via a link on the profs homepages or as a chunk of data under the heading "PUBLICATIONS" etc. I think i can get the data if its via a link but i dunno hoe to extract that exact chunk in the middle of a page. > 3. All this info shud be extracted to external text files > > I can manage if someone just helps me with snippets of code to gt started with the extraction...accurate extraction of information from any random site of a intitution which has profs listed etc. > For example some sites are www.ntu.edu.sg/sce/staffacad.asp , http://www.ntu.edu.sg/eee/people/, http://www.ie.cuhk.edu.hk/index.php?id=6, http://www.ntu.edu.sg/mpe/admin/staff.asp > > Greatly appreciate any help in any direction...totally lost here..please feel free to ask if u have any doubts regarding my question! > > shuchi > > > > --- > This SF.net email is sponsored by: Perforce Software. > Perforce is the Fast Software Configuration Management System offering > advanced branching capabilities and atomic changes on 50+ platforms. > Free Eval! http://www.perforce.com/perforce/loadprog.html > ___ > Perl-Win32-GUI-Users mailing list > Perl-Win32-GUI-Users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users > >
[perl-win32-gui-users] CVS commit
Hi,
In this update:
- GUI.xs : Made ProgressBar aware of -foreground and -background colour
settings
Example:
my $progressbar = new Win32::GUI::ProgressBar($mainwindow,
-name => "PB1",
-left => 0,
-top => 0,
-width => 100,
-height => 20,
-foreground => [255,0,0], # Red. Can also use a color object as normal
-background => [0,0,0], # Black.
);
$progressbar->Change(-foreground => [80,80,80]); # Change bar colour to
grey.
$progressbar->Change(-background => [0,80,80]); # Change background colour
to slate.
- GUI.xs : Added Result(handle, code) call for explicitly setting the
returned LRESULT from a handler. (normally the value returned from Perl
handlers was not returned from their calling wndproc, this allows you to
specify a result that will be returned.)
Example:
my notifyhandler {
my $object = shift;
$object->Result(20);# set the value we should return to Windows to
be 20.
return 0;
}
See the API documentation on msdn.microsoft.com for valid values to return
on particular messages. This feature is most useful for responding to the
various WM_NOTIFY and WM_COMMAND messages.
- GUI_MessageLoops.cpp : If CommonMsgLoop must be called then it is called
before any Hook handlers are called.
You will probably not notice a difference with this change. Basically it
means that any events that were previously processed AFTER the hooks were
called are now done BEFORE the hooks are called. The most significant
advantage of this is that you can now hook WM_PAINT and do all your
client-area drawing there (previously, any drawing you did was erased
immediately).
Any problems, mail the list. Any suggestions, bug reports or feature
requests, please use:
http://sourceforge.net/tracker/?group_id=16572
Thank you and good night :)
Steve
Re: [perl-win32-gui-users] Intermediate release of Win32::GUI
Before you build a new PPM, let me fix all the broken and/or horrible example code :) I don't know where half of the examples in the current PPM came from, but a lot of them don't work and I'm in the process of fixing them. Steve - Original Message - From: Laurent ROCHER To: perl-win32-gui-users@lists.sourceforge.net Sent: Tuesday, January 13, 2004 8:37 PM Subject: Re: [perl-win32-gui-users] Intermediate release of Win32::GUI Hi all, It's probably not a problem to made new PPM more regular from CVS source code for people don't want/can build it. But, it's more developpement PPM than new WIn32-GUI release. We need a new place for put it. I think to a specific donwload group on sourceforge (a package name like Win32-GUI Dev). If i can, i try to build new ppm this week-end. I use my personnal web space for publish it, until new sourceforge download entry added. For building HTML documentation from source code i use 2 perl script in docs subdirectory (you can found it in source distribution). I do this : cd docs del ./html/*.* del ./pod/*.* perl dodoc.pl perl dohtml.pl I think it's probably a good idea to add samples directory on CVS too. It's permit to add/update/enchance/document it for future Source distribution. Laurent.
[perl-win32-gui-users] CVS: New statusbar methods added
Hi, You'll all be pleased to know that I've enhanced the StatusBar object greatly. Here's the documentation for all the new methods for your status bars: Parts([x1, x2, x3...]) # Divides the statusbar into sections. The list of co-ordinates define the # right-hand edge of each part. # # This method will return a list of co-ordinates for the current parts. # A value of -1 in the final co-ordinate means the last part will # expand rightwards to fill the statusbar. Simple([simplemode]) # If simplemode is not 0, turns simple mode on. Otherwise, turns simple # mode off. Simple mode means the statusbar just shows text, with only one # partition. # # Returns the status of simple mode (0 = off, non-zero = on) PartText(part,[string,[flags]]) # Sets or gets the text in a particular part of the status bar. # # Flags are as follows: # 0 #The text is drawn with a border to appear lower than the plane of #the window. # # SBT_NOBORDERS = 256 #The text is drawn without borders. # # SBT_POPOUT = 512 #The text is drawn with a border to appear higher than the plane of #the window. # # SBT_RTLREADING = 1024 #The text will be displayed in the opposite direction to the text #in the parent window. # # SBT_OWNERDRAW = 4096 #The text is drawn by the parent window. # # When called with no string or flags, in scalar context the method will # return the text string in the specified part of the status bar. In array # context, the method will return the text string and the style flags of # the text in the specified part. # Tip(part,string) # Sets the tooltip text for a particular part of the status bar. # # From SDK documentation: # This ToolTip text is displayed in two situations: # When the corresponding pane in the status bar contains only an icon. # When the corresponding pane in the status bar contains text that is # truncated due to the size of the pane. Icon(part,icon) # Sets or unsets the icon for a particular part of the status bar. If icon # is set to 0 or less, the icon for the specified part of the status bar is # removed. icon should be a Win32::GUI::Icon object. # GetRect(part) # Gets the bounding rectangle for the given part of the status bar. Returns # left, top, right, bottom co-ordinates, or undef on failure. This is useful # for drawing in the status bar. # SetMinHeight(height) # Sets the minimum height of a status window's drawing area, and redraws # the status bar. # # The minimum height produced will be: height + (2 * vertical border width) # GetBorders() # Gets the border values for the status bar. Returns an array containing # width of the horizontal border, width of the vertical border, and the # width of the border between parts. # SetBkColor([color]) # Sets the background color of the status bar. If no color is given, # it sets the background color to the default background color. # Any questions, let me know. Suggestions and bugs to sourceforge tracker. Thank you. Steve
[perl-win32-gui-users] Yet Another CVS Commit...
Hello, me again...
Since some people mentioned window scrollbars in the list a while back, I
decided to implement some functions to make them actually work.
I've also added the relevant constants for scrollbars and statusbars, fixed
the bug with $window->Result(x) (thanks to Glenn Linderman), and applied
Laurent Rocher's tweaks for the Status Bar code.
New functions. Use these in the form:
$window->foo(bar, baz);
###
# (@)METHOD:ScrollPos(scrollbar,[pos])
# Sets / Gets position of a window scrollbar (if enabled). scrollbar
# argument should be set as follows:
# 0 - Horizontal scrollbar
# 1 - Vertical scrollbar
#
# Returns the scrollbar position or undef on failure.
###
# (@)METHOD:ScrollPage(scrollbar,[pagesize])
# Sets / Gets page size of a window scrollbar (if enabled). scrollbar
# argument should be set as follows:
# 0 - Horizontal scrollbar
# 1 - Vertical scrollbar
#
# Returns the scrollbar page size or undef on failure.
###
# (@)METHOD:ScrollRange(scrollbar,[min, max])
# Sets / Gets range for a window scrollbar (if enabled). scrollbar
# argument should be set as follows:
# 0 - Horizontal scrollbar
# 1 - Vertical scrollbar
#
# Returns the scrollbar range as an array, or undef on failure.
###
# (@)METHOD:Scroll(scrollbar,operation,position)
# Handles scrollbar scrolling if you don't want to do it yourself. This is
# most useful in the Scroll event handler for a window or dialog box.
#
# scrollbar can be:
# 0 - Horizontal scrollbar
# 1 - Vertical scrollbar
#
# type is an identifier for the operation being performed on the scrollbar,
# this can be:
# SB_LINEUP, SB_LINELEFT, SB_LINEDOWN, SB_LINERIGHT, SB_PAGEUP
# SB_PAGELEFT, SB_PAGEDOWN, SB_PAGERIGHT, SB_THUMBPOSITION,
# SB_THUMBTRACK, SB_TOP, SB_LEFT, SB_BOTTOM, SB_RIGHT, or SB_ENDSCROLL
#
# Returns the position of the scrollbar or undef on failure.
#
New events for WINDOW/DIALOGBOX:
/*
* (@)EVENT:Scroll(SCROLLBAR, OPERATION, POSITION)
* Sent when one of the window scrollbars is moved. SCROLLBAR identifies
* which bar was moved, 0 for horizontal and 1 for vertical.
*
* OPERATION can be compared against one of the following constants:
* SB_LINEUP, SB_LINELEFT, SB_LINEDOWN, SB_LINERIGHT, SB_PAGEUP
* SB_PAGELEFT, SB_PAGEDOWN, SB_PAGERIGHT, SB_THUMBPOSITION,
* SB_THUMBTRACK, SB_TOP, SB_LEFT, SB_BOTTOM, SB_RIGHT, SB_ENDSCROLL
*
* NEM equivalent: onScroll
* Related messages: WM_HSCROLL, WM_VSCROLL
*/
Example code:
use Win32::GUI;
my $win = new Win32::GUI::Window (
-name => "MainWin",
-left => 0,
-top => 100,
-width => 500,
-height => 300,
-sizable => 1,
-text => "Scrollbar Test",
-noflicker => 0,
-hscroll => 1,
-onScroll => \&scrolled
);
$win->ScrollRange(0,0,100));
$win->ScrollPage(0,10);
$win->ScrollPos(0,50);
$win->Show;
Win32::GUI::Dialog;
sub scrolled {
my($object,$bar,$operation,$pos) = @_;
$object->Scroll($bar,$operation,$pos);
# You could also do something like this if you want more control:
#if($operation == SB_LINEUP) {
#$object->ScrollPos($bar,$object->ScrollPos($bar) - 1);
#}
#elsif($operation == SB_PAGEUP) {
#$object->ScrollPos($bar,$object->ScrollPos($bar) -
$object->ScrollPage($bar));
#}
#elsif($operation == SB_THUMBTRACK) {
#print "Tracking ".($bar == 0 ? "horizontal" : "vertical")."
scrollbar thumb position: ".$pos."\n";
#}
# and so on.
}
Steve.
Re: [perl-win32-gui-users] Avoiding applications hanging?
Hi Nigel,
You need select()! It's the best thing in the world (honest).
The following routine will check for activity on the socket "MYSOCKET" (you
can change this, if you want to pass a socket as an argument, just use
scalars instead of barewords for socket handles, and pass the socket like a
normal sub argument). If no activity occurs in 0.5 seconds, it will return
0. Otherwise it will return 1. You can then have a while loop somewhere in
your program that keeps checking until you get a connection, or some data,
or whatever.
sub checkfordata {
my $timeout = 0.5; # half a second
my $bits = "";
vec($bits,fileno(MYSOCKET),1) = 1;
my $rout;
select($rout=$bits, undef, undef, $timeout);
if(vec($rout,fileno(MYSOCKET),1) == 1) {
# We have some data to read! (connection, incoming packet, yada yada)
return 1;
}
else {
return 0;
}
}
Hope that helps out
Steve.
- Original Message -
From: "Nigel Cannings" <[EMAIL PROTECTED]>
To:
Sent: Thursday, January 15, 2004 5:16 PM
Subject: [perl-win32-gui-users] Avoiding applications hanging?
> hi there
>
> I have a console application, that I want to have show an icon on the
status
> bar - This is no problem with Win32::GUI::Icon.
>
> However, I do not want the application to hang, waiting for an event from
> the (hidden) window - Really the icon is there to show the console app is
> running, and also to be clicked to exit.
>
> Is there any way to display the icon, but allow the main application to
> carry on doing its thing in the background (my application is listening
for
> a socket connection)
>
> Many thanks
>
> Nigel
>
>
> ---
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> ___
> Perl-Win32-GUI-Users mailing list
> Perl-Win32-GUI-Users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
>
Re: [perl-win32-gui-users] Scroll bar example
Sorry, I have not thrown any weight towards the discussion on Select(-1) et al, personally I would disagree that it is counter-intuitive, as user functions such as this one rarely behave like Perl arrays do anyway. I would say that Select(-1) is perfectly viable, but for readability I would say that SelectAll() makes more sense. The way I would do it is implement and document SelectAll(), but quietly make Select(-1) work as well. That satisfies both people who know what to expect from Select(), and people who are not familiar with it. SelectAll() would then be classed as a convenience method. I'm unsure of MDIs, I don't know the "correct" way to implement them yet, but it may be something to look into in the future. Currently I have enough stuff to do fixing and documenting the example scripts and adding to the current docs. Steve - Original Message - From: Frazier, Joe Jr To: Stephen Pick ; Win32-GUI Sent: Friday, January 16, 2004 5:09 PM Subject: RE: [perl-win32-gui-users] Scroll bar example Stephen, see comments inline: -Original Message- From: Stephen Pick [mailto:[EMAIL PROTECTED] Sent: Friday, January 16, 2004 11:26 AM To: Frazier, Joe Jr; Win32-GUI Subject: RE: [perl-win32-gui-users] Scroll bar example Whoa there, slow down... This is NOT an MDI "thing". This is a cheap hack to get Jez's problem solved. Don't use it unless you have to. [JOE:>>>] Ok, this is not a "real" MDI \ solution, but it is very close in approximating the functionality. if the title bars do not become active, remove the WS_CHILD style. [JOE:>>>] This did it. The only problem I still see is that both the child and the parent do not have the ability to have focus. Not sure if this is just because it is a hack or what not. Of course, when true MDI functionality can looked at, this will be solved. I currently do not need MDI windows, but I try to do a quick test any time someone shows some new code so as to get familiar with the newly added functionality and how it works. if things are clipping what they shouldnt, add the WS_CLIPSIBLINGS style. [JOE:>>>] Actually, removing the WS_CHILD seemed to fix this problem also. I added new methods that have API equivalents (SetScrollRange, SetScrollPos...), and I am not the sort of XS programmer who leaves the user to extract a massive struct which I could have done in XS, which is why I did not offer SetScrollInfo(), but instead implemented the older functions that let you do everything SetScrollInfo() does. You must handle all scrolling yourself, as i've said a million times. I will look into MDIs when I have the time; win32::gui already seems to have an MDI object but I'm unsure of what it does. [JOE:>>>] Thanks. I really appreciate that since I brought up the scrolling discussion about a week ago and I think where this thread kind of originated. I away the new PPM and docs so I can play with it(even though I do not have a current project that needs it, but will in the near future). I strongly disagree that adding new functionality is bad. The functions I have added are all documented and most have API equivalents. [JOE:>>>] I apologize if some may have misunderstood my statements. I was really speaking on the other thread of the SelectAll method that Glenn was working on. While I have no problem with a new method, my expectation would be that method names which match those exposed by the API should function similarly. That's all I was saying. > I don't want to have someone how is used to windows programming in VB or > C++ to wonder what something is I do not program XS functions for "VB/VC++ programmers". I write them for Perl programmers. I respect the fact that originally Win32::API was supposed to be very similar to the VB way of doing things. That has changed now. Every new method I add to Win32::GUI attempts to be in-keeping with the general Win32::GUI way of doing things, and is well documented. Win32::GUI is still very similar to the underlying C API, which is a good thing. If they dont know what something is then they can read the docs, which will be regenerated from the new code and distributed with the PPM. Steve [JOE:>>>] Finally, I wish to thank both you and the others who are performing active development of this project. It has been very slow going because of most people relying on Aldo and he is only one person and can only do so much. While the vast majority of my needs are "very" simple with regards to using Win32::GUI, I have not felt compelled to really stretch my designs because the functionally was not there. Due to your and others ongoing daily work with the project, I feel this will inspire thing about new ways to build their windows that they may not have even thought of before. A perfect example is the rebar control. I have never had a use for it in the p
Re: [perl-win32-gui-users] Scroll bar example
"is it possible to use a scroll bar within a window, and not on one of it's
edges?"
Yes, it is. Although I did not implement this yet. What you get when you do it
is one of those scrollbars where the scroll handle blinks on focus. It is
theoretically possible to add scrollbars to anything, but what I was suggesting
you do was as follows:
Create a child window with WS_CHILD and no WS_CAPTION. (-pushstyle => WS_CHILD,
-popstyle => WS_CAPTION - you might need to -popstyle => WS_BORDER as well),
and add scrollbars to it. Assign it a parent using the SetParent() method I
previously described. Now what you will have is a flat, captionless, borderless
"pane" with scrollbars, inside your window. It cannot be moved or resized.
Now repeat the process (create another child window...), but this time when you
call SetParent(win, parent), you should make the parent window the child you
created above. What you now have is a window in a window in a window. It is the
last child you created that you can put your widgets (buttons etc) in. When
your scrollable child receives Scroll messages, you should move the window with
buttons in appropriately.
The attached script should demonstrate things a little better. I don't think
this is the most intuitive way to do things, I do know that the only thing that
receives the Scroll event is a window or dialogbox, because I coded it that
way. I'm thinking of removing this explicit limitation on what can be scrolled.
You can still add scrollbars to and set scroll parameters on any widget.
Steve
- Original Message -
From: Jez White
To: Stephen Pick ; Win32-GUI
Sent: Friday, January 16, 2004 1:34 PM
Subject: Re: [perl-win32-gui-users] Scroll bar example
Thanks for all the replies/suggestions.
I have to admit I'm more confused now than I was when I started:)
I tried your suggestions Steve, I end up with something that works like an
MDI application - which is nice in itself, but not what I was after:)
Basically is it possible to use a scroll bar within a window, and not on one
of it's edges? I'm trying to think of a clearer example than my tab strip one.
Imagine a image viewing program with the main window filled with controls, the
image could be larger than the screen so you want to place scroll bars on the
image and not on the window (almost like putting a scroll bar on a control). I
had assumed you could use somesort of child window to achieve this kind of
effect?
My thought process was basically inline with what Johan was suggesting - if a
child window could be just another control, then the parent window would not
lose focus and everything would be hunky dory. Using a child window in this
manor would also make sense when attaching a child window to a band in the
rebar control.
Or am I just way off the mark here?:)
Cheers,
jez.
- Original Message -
From: Stephen Pick
To: Jez White ; Win32-GUI
Sent: Friday, January 16, 2004 12:58 PM
Subject: RE: [perl-win32-gui-users] Scroll bar example
Your code is bad. What you're doing is creating a floating
"BorderlessWindow" positioned over the top of the main window. If you want to
put your window *INSIDE* the client area I suggest you do this:
use Win32::API;
our $SETPARENT = new Win32::API("user32","SetParent","NN","N") or croak
"Failed to load SetParent from user32.dll";
my $child = new Win32::GUI::DialogBox(
-parent => $win,
-name => "Child",
-left => 0,
-top => 0,
-text => "Child",
-width => 100,
-height => 100,
-style => WS_CHILD,
);
$SETPARENT->Call($child->{-handle}, $win->{-handle});
$child->Width($child->Width); # force update.
After doing this stuff, you'll find you have a dialogbox inside the main
window. It also clips if you drag it "out" of the main window, so it truely is
inside. You can even give it a WS_CAPTION and drag it around in the client area.
Giving things a -parent argument does NOT mean SetParent is called on them
in Win32::GUI.
Steve
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jez White
Sent: 16 January 2004 12:37
To: Win32-GUI
Subject: [perl-win32-gui-users] Scroll bar example
Hi,
The example below will only work on the latest code line from CVS.
I'm trying to get my head round using scroll bars. In my test example I
want to create a window containing one tab strip. In the tab strip there will
be a child window containing a scroll bar and 10 buttons. Scrolling the scroll
bar will move the buttons into and out view.
Now, the scrolling part works fine - but is using a child window in this
way the correct approach? For example, interacting with the child window
(clicking on a button, or scrolling) loses focus (which you would expect for a
normal window) but is not the correct behaviour in this ca
Re: [perl-win32-gui-users] Scroll bar example
Oh, sorry, bugfix,
line 83 add:
$scrollarea->Left(0 - $scrollwindow->ScrollPos(0));
Helps if you keep tracking the scrollbar during resize :)
This stops weird behaviour if you scroll then resize the window.
Steve
- Original Message -
From: Jez White
To: Stephen Pick ; Win32-GUI
Sent: Friday, January 16, 2004 1:34 PM
Subject: Re: [perl-win32-gui-users] Scroll bar example
Thanks for all the replies/suggestions.
I have to admit I'm more confused now than I was when I started:)
I tried your suggestions Steve, I end up with something that works like an
MDI application - which is nice in itself, but not what I was after:)
Basically is it possible to use a scroll bar within a window, and not on one
of it's edges? I'm trying to think of a clearer example than my tab strip one.
Imagine a image viewing program with the main window filled with controls, the
image could be larger than the screen so you want to place scroll bars on the
image and not on the window (almost like putting a scroll bar on a control). I
had assumed you could use somesort of child window to achieve this kind of
effect?
My thought process was basically inline with what Johan was suggesting - if a
child window could be just another control, then the parent window would not
lose focus and everything would be hunky dory. Using a child window in this
manor would also make sense when attaching a child window to a band in the
rebar control.
Or am I just way off the mark here?:)
Cheers,
jez.
- Original Message -
From: Stephen Pick
To: Jez White ; Win32-GUI
Sent: Friday, January 16, 2004 12:58 PM
Subject: RE: [perl-win32-gui-users] Scroll bar example
Your code is bad. What you're doing is creating a floating
"BorderlessWindow" positioned over the top of the main window. If you want to
put your window *INSIDE* the client area I suggest you do this:
use Win32::API;
our $SETPARENT = new Win32::API("user32","SetParent","NN","N") or croak
"Failed to load SetParent from user32.dll";
my $child = new Win32::GUI::DialogBox(
-parent => $win,
-name => "Child",
-left => 0,
-top => 0,
-text => "Child",
-width => 100,
-height => 100,
-style => WS_CHILD,
);
$SETPARENT->Call($child->{-handle}, $win->{-handle});
$child->Width($child->Width); # force update.
After doing this stuff, you'll find you have a dialogbox inside the main
window. It also clips if you drag it "out" of the main window, so it truely is
inside. You can even give it a WS_CAPTION and drag it around in the client area.
Giving things a -parent argument does NOT mean SetParent is called on them
in Win32::GUI.
Steve
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jez White
Sent: 16 January 2004 12:37
To: Win32-GUI
Subject: [perl-win32-gui-users] Scroll bar example
Hi,
The example below will only work on the latest code line from CVS.
I'm trying to get my head round using scroll bars. In my test example I
want to create a window containing one tab strip. In the tab strip there will
be a child window containing a scroll bar and 10 buttons. Scrolling the scroll
bar will move the buttons into and out view.
Now, the scrolling part works fine - but is using a child window in this
way the correct approach? For example, interacting with the child window
(clicking on a button, or scrolling) loses focus (which you would expect for a
normal window) but is not the correct behaviour in this case. Am I missing
something fundamental?
Apologies for the dodgy code - is a hack job:)
cheers,
jez.
===
use Win32::GUI;
use Win32::GUI::BorderlessWindow;
#create the main window
my $win = new Win32::GUI::Window (
-name => "MainWin",
-left => 0,
-top => 100,
-width => 500,
-height => 300,
-sizable => 1,
-text => "Scrollbar Test 2",
-noflicker => 1,
);
#create a tab strip
$win->AddTabStrip (
-name => "Tab",
-left => 0,
-top => 100,
-width => 250,
-height => 150,
);
$win->Tab->InsertItem(-text => 'Some Tab');
#create a child window with a scroll bar
my $childwin = new Win32::GUI::BorderlessWindow (
-name => "Child",
-parent =>$win,
-left => 10,
-top => 250,
-width => 200,
-height => 120,
-hscroll => 1,
-noflicker => 1,
-onScroll => \&scrolled
);
#create content for our child window, 10 buttons.
foreach (0..9) {
$childwin->AddButton (
-name => "Button".$_,
-pos => [$_*50, 30],
-size => [50, 20],
-text => 'Button'.$_,);
}
#set the scrollbar range
Re: [perl-win32-gui-users] New ListView Methods
Committed the changes to 665-Fix. Steve - Original Message - From: "Glenn W Munroe" <[EMAIL PROTECTED]> To: Cc: "Steve Pick1" <[EMAIL PROTECTED]>; "Steve Pick2" <[EMAIL PROTECTED]>; "Laurent ROCHER" <[EMAIL PROTECTED]> Sent: Saturday, January 17, 2004 3:37 PM Subject: [perl-win32-gui-users] New ListView Methods > > I have just posted my new ListView Select methods to the Tracker as a > Feature Request. Perhaps some kind soul (Steve? Laurent?) with CVS write > access would be good enough to take a look and commit the changes to > ListView.xs if all looks OK. > > The consensus of opinion seemed to be that SelectAll() is more intuitive > than Select(-1), though there is also an argument to follow the > underlying API conventions. I've followed Steve's > have-your-cake-and-eat-it approach by implementing both. > > There are four methods. The enhanced Select() allows Select(-1) to > select all items in the list. There are checks for out-of-bounds > parameters and to make sure the list is in the correct mode. I thought > I'd identified a bug with the original method, related to focus (though > I couldn't reproduce it later). *If* it really was there, this should > fix it. SelectAll() is an alternate way to select all items. Following > Windows' conventions (or at least Windows Explorer's), SelectAll() > leaves focus at item 0. The new Deselect() and DeselectAll() methods > enable the programmer to deselect an item programmatically. > Correspondingly, Deselect(-1) is an alternative to DeselectAll(). > > These aren't complex methods, but there is always room for error. Please > let me know if there are any problems. > > Glenn Munroe > > > > > --- > The SF.Net email is sponsored by EclipseCon 2004 > Premiere Conference on Open Tools Development and Integration > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > http://www.eclipsecon.org/osdn > ___ > Perl-Win32-GUI-Users mailing list > Perl-Win32-GUI-Users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users >
Re: [perl-win32-gui-users] Accelerator bug?
Aldo's been silent for a while. Exactly what events are missing? We're running out of space in the NEM to add new events (checking if events are set is based on a 32-bit mask, and most of the bits are used), but I'm sure that's easy to get round. The NEM is probably faster than the OEM, though I've not run any benchmarks. I would no longer even consider using the OEM, having looked at the code for it (mind you I'm hardly in a position to comment on code clarity :) ). Steve - Original Message - From: "Jez White" <[EMAIL PROTECTED]> To: "Stephen Pick" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; Sent: Tuesday, January 20, 2004 11:20 AM Subject: Re: [perl-win32-gui-users] Accelerator bug? > > I'de like to use NEM more - but I am finding some events missing. So it the > NEM slightly "faster" as well? > > Aldo was talking about another model - is this just an enhancement of NEM? > > jez. > > - Original Message - > From: "Stephen Pick" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]>; > Sent: Tuesday, January 20, 2004 10:58 AM > Subject: RE: [perl-win32-gui-users] Accelerator bug? > > > Yes, I use the NEM heavilly. The OEM is a really ugly way of doing > things and basing things on references is much safer and much more > elegant. Every other perl module that needs to do callbacks uses > references (see.. well.. anything, err, LWP for example). This is > because you can check that references are safe to call, whereas with > non-references you have to eval() and then you open up security holes. > > Steve > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] Behalf Of > > Glenn W Munroe > > Sent: 20 January 2004 10:52 > > To: perl-win32-gui-users@lists.sourceforge.net > > Subject: RE: [perl-win32-gui-users] Accelerator bug? > > > > > > > > Just out of interest, is anybody really using the NEM? Are there any > > major advantages to it? I admit it is quite elegant to have a one-line > > subroutine defined as an -event option, but in practice, most event > > handlers will consist of more code than I would like to > > define that way > > and the handler would just end up being another subroutine call. > > > > IMHO, the two major advances in this module recently have been > > accelerators and hooks (I'd say we're approaching GUI > > nirvana), so if at > > least one of them doesn't work in NEM, that knocks it on the head for > > me. > > > > Glenn > > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of > > Glenn Linderman > > Sent: Monday, 19 January, 2004 21:52 > > To: [EMAIL PROTECTED] > > Cc: perl-win32-gui-users@lists.sourceforge.net > > Subject: Re: [perl-win32-gui-users] Accelerator bug? > > > > Glenn, > > > > Sorry for the delay, I was not monitoring this email address > > from 1/15 > > until now. > > > > > > On approximately 1/16/2004 8:28 AM, came the following characters from > > the keyboard of Glenn W Munroe: > > > Glenn, > > > > > > I haven't really used the NEM much yet, but when I knocked > > up a small > > > test script this morning with the new model I found that > > accelerators > > > didn't work. Had you noticed this or can you confirm it? If > > so, is it > > a > > > bug with accelerators themselves or some underlying "feature" of the > > > system? > > > > Indeed, I think it is just a missing feature in NEM. When I > > looked at > > the code inside Win32::GUI for accelerators, I was able to figure out > > and fix accelerators for OEM, but I think NEM has much more code that > > simply isn't there for accelerators. This is one reason I am still > > using OEM. (OEM = Old Event Model, when it takes a break > > from meaning > > Original Equipment Manufacturer :) ) > > > > > Regards, > > > Glenn Munroe > > > > -- > > Glenn -- http://nevcal.com/ > > === > > The best part about procrastination is that you are never bored, > > because you have all kinds of things that you should be doing. > > > > > > > > --- > > The SF.Net email is sponsored by EclipseCon 2004 > > Premiere Conference on Open Tools Development and Integration > > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > > http://www.eclipsecon.org/osdn > > ___ > > Perl-Win32-GUI-Users mailing list > > Perl-Win32-GUI-Users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users > > > > > > > > > > > > --- > > The SF.Net email is sponsored by EclipseCon 2004 > > Premiere Conference on Open Tools Development and Integration > > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > > http://www.eclipsecon.org/osdn > > ___ > > Perl-Win32-GUI-Users mailing list > > Perl-Win32-GUI-Users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/perl-win32-gu
Re: [perl-win32-gui-users] Accelerator bug? Labels & freeform windows
Thanks. Freeform windows - you want Layered windows. You can set a window to be layered by giving it an extended style of WS_EX_LAYERED (0x0008), but I found that this made my window invisible. You may have better luck, as I tried it in an application that I'd made that uses lots of hooks to draw things and therefore is probably incompatible with them. Transparent backgrounds on labels - Try setting WS_EX_TRANSPARENT (0x0020), This seems to screw up drawing a treat, but it may work if you set normal style WS_CLIPCHILDREN (0x0200). Give it a go and let me know the result. Steve - Original Message - From: "Jez White" <[EMAIL PROTECTED]> To: "Steve Pick" <[EMAIL PROTECTED]>; Sent: Tuesday, January 20, 2004 7:29 PM Subject: Re: [perl-win32-gui-users] Accelerator bug? > Indeed he has... > > What events are missing - not sure - I'm in the process of tiding up my app, > and large parts of it I would like to run under NEM - I'll create a bug > report for missing events as I find them. > > cheers, > > jez. > - Original Message - > From: "Steve Pick" <[EMAIL PROTECTED]> > To: "Jez White" <[EMAIL PROTECTED]>; > > Sent: Tuesday, January 20, 2004 7:01 PM > Subject: Re: [perl-win32-gui-users] Accelerator bug? > > > > Aldo's been silent for a while. > > > > Exactly what events are missing? We're running out of space in the NEM to > > add new events (checking if events are set is based on a 32-bit mask, and > > most of the bits are used), but I'm sure that's easy to get round. > > > > The NEM is probably faster than the OEM, though I've not run any > benchmarks. > > > > I would no longer even consider using the OEM, having looked at the code > for > > it (mind you I'm hardly in a position to comment on code clarity :) ). > > > > Steve > > > > - Original Message - > > From: "Jez White" <[EMAIL PROTECTED]> > > To: "Stephen Pick" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; > > > > Sent: Tuesday, January 20, 2004 11:20 AM > > Subject: Re: [perl-win32-gui-users] Accelerator bug? > > > > > > > > > > I'de like to use NEM more - but I am finding some events missing. So it > > the > > > NEM slightly "faster" as well? > > > > > > Aldo was talking about another model - is this just an enhancement of > NEM? > > > > > > jez. > > > > > > - Original Message - > > > From: "Stephen Pick" <[EMAIL PROTECTED]> > > > To: <[EMAIL PROTECTED]>; > > > Sent: Tuesday, January 20, 2004 10:58 AM > > > Subject: RE: [perl-win32-gui-users] Accelerator bug? > > > > > > > > > Yes, I use the NEM heavilly. The OEM is a really ugly way of doing > > > things and basing things on references is much safer and much more > > > elegant. Every other perl module that needs to do callbacks uses > > > references (see.. well.. anything, err, LWP for example). This is > > > because you can check that references are safe to call, whereas with > > > non-references you have to eval() and then you open up security holes. > > > > > > Steve > > > > > > > -Original Message- > > > > From: [EMAIL PROTECTED] > > > > [mailto:[EMAIL PROTECTED] Behalf Of > > > > Glenn W Munroe > > > > Sent: 20 January 2004 10:52 > > > > To: perl-win32-gui-users@lists.sourceforge.net > > > > Subject: RE: [perl-win32-gui-users] Accelerator bug? > > > > > > > > > > > > > > > > Just out of interest, is anybody really using the NEM? Are there any > > > > major advantages to it? I admit it is quite elegant to have a one-line > > > > subroutine defined as an -event option, but in practice, most event > > > > handlers will consist of more code than I would like to > > > > define that way > > > > and the handler would just end up being another subroutine call. > > > > > > > > IMHO, the two major advances in this module recently have been > > > > accelerators and hooks (I'd say we're approaching GUI > > > > nirvana), so if at > > > > least one of them doesn't work in NEM, that knocks it on the head for > > > > me. > > > > > > > > Glenn > > > > > > > > -Original Message- > > > > From: [EMAIL PROTECTED]
Re: [perl-win32-gui-users] Accelerator bug?
> Thinking about it, it would be nice to be able to do this:
>
> $mw->btButton->Change(-events => {Click => sub {return -1}});
There's nothing wrong with the concept and the implementation might actually
be pretty simple (all I think it needs is to bitwise-OR in the constant that
says "yes, capture clicks" to the NEM event mask).
It's on the todo list.
Steve
- Original Message -
From: "Glenn W Munroe" <[EMAIL PROTECTED]>
To: "'Stephen Pick'" <[EMAIL PROTECTED]>
Cc:
Sent: Tuesday, January 20, 2004 8:03 PM
Subject: RE: [perl-win32-gui-users] Accelerator bug?
>
> It sounds like the NEM is the way to go, then. Accordingly, I've added
> non-functioning accelerators to the Tracker as a bug (though I suppose
> it could have been a feature request according to Glenn Linderman's
> reply).
>
> Thinking about it, it would be nice to be able to do this:
>
> $mw->btButton->Change(-events => {Click => sub {return -1}});
>
> but it doesn't seem to work. Is there something fundamentally wrong with
> the idea, or has it just not been implemented (yet)?
>
> Glenn Munroe
>
> -Original Message-
> From: Stephen Pick [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, 20 January, 2004 07:59
> To: [EMAIL PROTECTED]; perl-win32-gui-users@lists.sourceforge.net
> Subject: RE: [perl-win32-gui-users] Accelerator bug?
>
> Yes, I use the NEM heavilly. The OEM is a really ugly way of doing
> things and basing things on references is much safer and much more
> elegant. Every other perl module that needs to do callbacks uses
> references (see.. well.. anything, err, LWP for example). This is
> because you can check that references are safe to call, whereas with
> non-references you have to eval() and then you open up security holes.
>
> Steve
>
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] Behalf Of
> > Glenn W Munroe
> > Sent: 20 January 2004 10:52
> > To: perl-win32-gui-users@lists.sourceforge.net
> > Subject: RE: [perl-win32-gui-users] Accelerator bug?
> >
> >
> >
> > Just out of interest, is anybody really using the NEM? Are there any
> > major advantages to it? I admit it is quite elegant to have a one-line
> > subroutine defined as an -event option, but in practice, most event
> > handlers will consist of more code than I would like to
> > define that way
> > and the handler would just end up being another subroutine call.
> >
> > IMHO, the two major advances in this module recently have been
> > accelerators and hooks (I'd say we're approaching GUI
> > nirvana), so if at
> > least one of them doesn't work in NEM, that knocks it on the head for
> > me.
> >
> > Glenn
> >
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On Behalf Of
> > Glenn Linderman
> > Sent: Monday, 19 January, 2004 21:52
> > To: [EMAIL PROTECTED]
> > Cc: perl-win32-gui-users@lists.sourceforge.net
> > Subject: Re: [perl-win32-gui-users] Accelerator bug?
> >
> > Glenn,
> >
> > Sorry for the delay, I was not monitoring this email address
> > from 1/15
> > until now.
> >
> >
> > On approximately 1/16/2004 8:28 AM, came the following characters from
> > the keyboard of Glenn W Munroe:
> > > Glenn,
> > >
> > > I haven't really used the NEM much yet, but when I knocked
> > up a small
> > > test script this morning with the new model I found that
> > accelerators
> > > didn't work. Had you noticed this or can you confirm it? If
> > so, is it
> > a
> > > bug with accelerators themselves or some underlying "feature" of the
> > > system?
> >
> > Indeed, I think it is just a missing feature in NEM. When I
> > looked at
> > the code inside Win32::GUI for accelerators, I was able to figure out
> > and fix accelerators for OEM, but I think NEM has much more code that
> > simply isn't there for accelerators. This is one reason I am still
> > using OEM. (OEM = Old Event Model, when it takes a break
> > from meaning
> > Original Equipment Manufacturer :) )
> >
> > > Regards,
> > > Glenn Munroe
> >
> > --
> > Glenn -- http://nevcal.com/
> > ===
> > The best part about procrastination is that you are never bored,
> > because you have all kinds of things that you should be doing.
> >
> >
> >
> > ---
> > The SF.Net email is sponsored by EclipseCon 2004
> > Premiere Conference on Open Tools Development and Integration
> > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> > http://www.eclipsecon.org/osdn
> > ___
> > Perl-Win32-GUI-Users mailing list
> > Perl-Win32-GUI-Users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
> >
> >
> >
> >
> >
> > ---
> > The SF.Net email is sponsored by EclipseCon 2004
> > Premiere Conference on Open Tools Development and Integration
> > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> > http://www.eclipsec
Re: [perl-win32-gui-users] ProgressBar inside StatusBar dont work with Timer
Hi,
Yep you've made a slight error - you've neglected to tell the progressbar
where to be. In my example, I had a resize event for the main window (though
it could be for the statusbar if you like) that sets the position of the
progress bar in the statusbar by getting the co-ordinates of the part it's
supposed to be in, and moving and sizing it to sit in that part. If you
implement a similar resize event, it should work.
Steve
- Original Message -
From: <[EMAIL PROTECTED]>
Cc:
Sent: Wednesday, January 21, 2004 4:17 AM
Subject: [perl-win32-gui-users] ProgressBar inside StatusBar dont work with
Timer
> This is modified example from Stephen Pick.
> I replaced while(1) by Timer-Method. The ProgressBar
> dont work with Timer. Have I made a mistake?
> Or I can call ProgressBar only inside main loop?
>
>
> #!perl -w
> use strict;
> use Win32::GUI;
> my $window = new Win32::GUI::Window(
> -name => "main",
> -text => "Status Progress",
> -size => [300,300],
> -pos => [100,100],
> );
> $window->AddLabel( -name=>'test',
> -pos=>[10,10],
> -size=>[100,100]
> );
> my $status = new Win32::GUI::StatusBar($window);
>
> $status->Parts(200,-1);
>
> my $progress = new Win32::GUI::ProgressBar($status, -smooth => 1);
> $progress->SetRange(0,50);
> $progress->SetPos(25);
>
> my $t1 = $window->AddTimer('T1', 1000);
>
> $window->Show;
> Win32::GUI::Dialog();
>
> sub T1_Timer{
> my $random = int rand (50);
> $progress->SetPos($random);
> $window->test->Text($random);
> }
>
> sub main_Terminate{
> return -1;
> }
>
>
>
> ---
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> ___
> Perl-Win32-GUI-Users mailing list
> Perl-Win32-GUI-Users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
>
Re: [perl-win32-gui-users] Accelerator bug?
Ah I understand now. I don't believe one can even change the NEM handlers once set -- correct me if I'm wrong. So what we're looking for here is: 1. A way to change NEM handlers to something else. 2. A way to retrieve NEM handler coderefs. I will poke around and you should see this in my next commit. Steve - Original Message - From: "Glenn Linderman" <[EMAIL PROTECTED]> To: "Stephen Pick" <[EMAIL PROTECTED]> Cc: Sent: Wednesday, January 21, 2004 6:41 PM Subject: Re: [perl-win32-gui-users] Accelerator bug? > I guess I didn't describe the condition well enough. I'll try again. > > The reason to obtain a handler, is if you want to augment the handler to > do more stuff, behind its back. > > So WinSize.pm tries to write a Resize handler that when a parent window > is resized, resizes and repositions all the children according to > user-specified rules. It also remembers the last window position and > size for the next time that window is created. > > To do this, it needs to intercept the Resize event and the Terminate > event, and do some processing before calling the user's _Resize and > _Terminate functions. In OEM, if the user has them, they are defined in > the global symbol table, and can be replaced. > > In order to do this in NEM, one needs a function to obtain the user's > defined coderefs, before replacing them, so that the replacement > function can call the user's function. > > > On approximately 1/21/2004 1:54 AM, came the following characters from > the keyboard of Stephen Pick: > > Hooks were always after the regular handling code, except now they're > > after WM_PAINT and a few other events too. > > > > While it is not possible to retrieve the coderefs for specific NEM > > events, the only time I can imagine you wanting to do this would be to > > find out a handler that a particular gui object is using and call it > > with your own arguments. I can't see that that would be a good plan or > > any particular practical use for it. An example would be nice. > > > > The other points, I'm looking into. > > > > Steve > > > > > >>-Original Message- > >>From: [EMAIL PROTECTED] > >>[mailto:[EMAIL PROTECTED] Behalf Of > >>Glenn Linderman > >>Sent: 21 January 2004 01:39 > >>To: Steve Pick > >>Cc: Jez White; perl-win32-gui-users@lists.sourceforge.net > >>Subject: Re: [perl-win32-gui-users] Accelerator bug? > >> > >> > >>Back when I tried to convert one of my applications from OEM > >>to NEM, I > >>discovered the following problems. Perhaps some of them have > >>been fixed > >>by now. Perhaps some of them were user error. > >> > >>1) The subroutines defined for pop-up menu click events never > >>got called. > >> > >>2) Accelerators didn't work. > >> > >>3) It wasn't possible to obtain the "old" event reference, so > >>that event > >>references could be stacked or nested. > >> > >>The latter item blew away NEM for me, as I wasn't able to port Harold > >>Piske's WinSize module in a reasonable fashion. I didn't really need > >>accelerator keys on that project, but they are handy on all projects, > >>and I prefer to have them available, so that was a negative. > >>And that > >>project used lots of pop-up menus, and when the Click event > >>subroutine > >>doesn't get called, that is a problem. > >> > >>So those are the reasons I gave up on NEM for now. 1) May have been > >>user error... anyone have a code sample in that area? 2) is still a > >>problem, and 3) might be solvable via hooks... but I think hooks > >>executed before the event is seen by the regular handling > >>code would be > >>more effective, and they just got switched to after the > >>regular handling > >>code. Being able to obtain the old code reference would be a handy > >>feature, though, even though hooks do exist. > >> > >> > >>On approximately 1/20/2004 11:01 AM, came the following > >>characters from > >>the keyboard of Steve Pick: > >> > >>>Aldo's been silent for a while. > >>> > >>>Exactly what events are missing? We're running out of space > >> > >>in the NEM to > >> > >>>add new events (checking if events are set is based on a > >> > >>32-bit mask, and > >> > >>>most of the bits
Re: [perl-win32-gui-users] Accelerator bug?
Hi,
I've implemented the following two functions:
$coderef = $window->GetEvent("eventname");
$window->SetEvent("eventname", \&sub);
These allow you to access and modify NEM event handlers.
You can't access and modify OEM event handlers. I should hope that the
reasons are obvious: It would be impossible and pointless.
Sourceforge's CVS is being particularly annoying at the moment (I can't get
a branch list from it, and it keeps failing to respond when connecting) so
you'll probably have to wait a bit before you see the changes appear.
Steve
- Original Message -
From: "Glenn Linderman" <[EMAIL PROTECTED]>
To: "Steve Pick" <[EMAIL PROTECTED]>
Cc: "Win32 GUI Users"
Sent: Wednesday, January 21, 2004 9:29 PM
Subject: Re: [perl-win32-gui-users] Accelerator bug?
> Thanks Steve. I hadn't gotten as far as trying to change one... since I
> couldn't retrieve the current one, I never tried to change it... you've
> already carried the analysis further than I had!
>
> On approximately 1/21/2004 12:42 PM, came the following characters from
> the keyboard of Steve Pick:
>
> > Ah I understand now. I don't believe one can even change the NEM
handlers
> > once set -- correct me if I'm wrong. So what we're looking for here is:
> > 1. A way to change NEM handlers to something else.
> > 2. A way to retrieve NEM handler coderefs.
> >
> > I will poke around and you should see this in my next commit.
> >
> > Steve
> >
> > - Original Message -
> > From: "Glenn Linderman" <[EMAIL PROTECTED]>
> > To: "Stephen Pick" <[EMAIL PROTECTED]>
> > Cc:
> > Sent: Wednesday, January 21, 2004 6:41 PM
> > Subject: Re: [perl-win32-gui-users] Accelerator bug?
> >
> >
> >
> >>I guess I didn't describe the condition well enough. I'll try again.
> >>
> >>The reason to obtain a handler, is if you want to augment the handler to
> >>do more stuff, behind its back.
> >>
> >>So WinSize.pm tries to write a Resize handler that when a parent window
> >>is resized, resizes and repositions all the children according to
> >>user-specified rules. It also remembers the last window position and
> >>size for the next time that window is created.
> >>
> >>To do this, it needs to intercept the Resize event and the Terminate
> >>event, and do some processing before calling the user's _Resize and
> >>_Terminate functions. In OEM, if the user has them, they are defined in
> >>the global symbol table, and can be replaced.
> >>
> >>In order to do this in NEM, one needs a function to obtain the user's
> >>defined coderefs, before replacing them, so that the replacement
> >>function can call the user's function.
> >>
> >>
> >>On approximately 1/21/2004 1:54 AM, came the following characters from
> >>the keyboard of Stephen Pick:
> >>
> >>>Hooks were always after the regular handling code, except now they're
> >>>after WM_PAINT and a few other events too.
> >>>
> >>>While it is not possible to retrieve the coderefs for specific NEM
> >>>events, the only time I can imagine you wanting to do this would be to
> >>>find out a handler that a particular gui object is using and call it
> >>>with your own arguments. I can't see that that would be a good plan or
> >>>any particular practical use for it. An example would be nice.
> >>>
> >>>The other points, I'm looking into.
> >>>
> >>>Steve
> >>>
> >>>
> >>>
> >>>>-Original Message-
> >>>>From: [EMAIL PROTECTED]
> >>>>[mailto:[EMAIL PROTECTED] Behalf Of
> >>>>Glenn Linderman
> >>>>Sent: 21 January 2004 01:39
> >>>>To: Steve Pick
> >>>>Cc: Jez White; perl-win32-gui-users@lists.sourceforge.net
> >>>>Subject: Re: [perl-win32-gui-users] Accelerator bug?
> >>>>
> >>>>
> >>>>Back when I tried to convert one of my applications from OEM
> >>>>to NEM, I
> >>>>discovered the following problems. Perhaps some of them have
> >>>>been fixed
> >>>>by now. Perhaps some of them were user error.
> >>>>
> >>>>1) The subroutines defined for pop-up menu click events never
> >>>>got called.
> >>>>
> >>>>2) Accelera
Re: [perl-win32-gui-users] Outlook email question...
Outlook email question...Hi, No, I don't know how to use CDO and there's no Perl modules that I can find for handling it. However, since CDO is a layer on top of OLE, you might be able to use OLE to do what you want. There's a Perl module for handling OLE available: http://search.cpan.org/~gsar/libwin32-0.191/OLE/lib/Win32/OLE.pm I recommend you check out http://msdn.microsoft.com for information on accessing outlook via OLE. I'm sorry I can't give any examples. Have you tried http://www.perlmonks.org with your question? Steve - Original Message - From: [EMAIL PROTECTED] To: perl-win32-gui-users@lists.sourceforge.net Sent: Friday, January 23, 2004 5:54 PM Subject: [perl-win32-gui-users] Outlook email question... Does anyone have any sample code demonstrating how to move or copy email messages from one folder to another using CDO. Thanks. This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please advise me (by return e-mail or otherwise) immediately. Ce courrier électronique est confidentiel et protégé. L'expéditeur ne renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) désigné(s) est interdite. Si vous recevez ce courrier électronique par erreur, veuillez m'en aviser immédiatement, par retour de courrier électronique ou par un autre moyen.
Re: [perl-win32-gui-users] Win32::FileOp Erro with Win32::GUI
Hi Ramy, Could you verify that Win32::GUI is causing this by testing without GUI code running. Create an application that uses threads and Win32::FileOp without Win32::GUI loaded and see if the problem still occurs. If so, it's out of our hands and is a fault in Win32::FileOp. A lot of modules are not threads-compatible, and it's probable that Win32::FileOp is one of them. If it only happens with Win32::GUI loaded, please let us know and we'll undoubtable jump at the chance to look into it, such a powerhouse of activity that we are. Thanks, Steve - Original Message - From: [EMAIL PROTECTED] To: perl-win32-gui-users@lists.sourceforge.net Sent: Saturday, January 24, 2004 10:24 PM Subject: [perl-win32-gui-users] Win32::FileOp Erro with Win32::GUI Hi All, I noticed that when I use the module Win32::FileOp in a GUI application (may be also not gui) in a Threads, When the threads starts, the script shows error that says : The instruction at "0x28053f9a" referenced memory at "0x10c0". The memory ould not be "read". Click on OK to terminate the program Click on CANCEL to debug the program and sometimes it is The memory ould not be "Written" instead of "read". I actually found that if I use the module "Win32::API" it will generate this error and of course Win32::FileOp use internally this module. The threads works fine if I remove the "use Win32::FileOp;" line but I need to use it for the File Open and Save Dialogs. Any solutions or suggestions? Thank you in advance for help Ramy
Re: [perl-win32-gui-users] Win32::FileOp Erro with Win32::GUI
Hi again, Maybe if you send me the source of an example that causes the error I could look into a fix for you, but I'm not promising anything. You'll really need to talk to Aldo Calpini about this. He wrote Win32::GUI and Win32::API, and his website is at http://dada.perl.it/ Although he assumedly reads this list every now and again to see how people are abusing his babies, he hasn't posted in a very long time. Steve - Original Message - From: [EMAIL PROTECTED] To: Steve Pick ; perl-win32-gui-users@lists.sourceforge.net Sent: Sunday, January 25, 2004 1:13 AM Subject: Re: [perl-win32-gui-users] Win32::FileOp Erro with Win32::GUI Dear Steve, Thanks first for your prompt reply. After some investigation of removing the modules from the script, I found out that the main source of the error come from Win32::API module Since the Win32::FileOp Which uses the Win32::API therefore it generates the error That means a big loose for me and everyone that can not use Win32::API module and all modules based on using it to load and interface to windows with threads as it makes life easier with loading dll's. I am not sure if WIn32::API is actively updated or not as this may be a little bug in it Regards Ramy - Original Message ----- From: Steve Pick To: [EMAIL PROTECTED] ; perl-win32-gui-users@lists.sourceforge.net Sent: Sunday, January 25, 2004 3:03 AM Subject: Re: [perl-win32-gui-users] Win32::FileOp Erro with Win32::GUI Hi Ramy, Could you verify that Win32::GUI is causing this by testing without GUI code running. Create an application that uses threads and Win32::FileOp without Win32::GUI loaded and see if the problem still occurs. If so, it's out of our hands and is a fault in Win32::FileOp. A lot of modules are not threads-compatible, and it's probable that Win32::FileOp is one of them. If it only happens with Win32::GUI loaded, please let us know and we'll undoubtable jump at the chance to look into it, such a powerhouse of activity that we are. Thanks, Steve - Original Message - From: [EMAIL PROTECTED] To: perl-win32-gui-users@lists.sourceforge.net Sent: Saturday, January 24, 2004 10:24 PM Subject: [perl-win32-gui-users] Win32::FileOp Erro with Win32::GUI Hi All, I noticed that when I use the module Win32::FileOp in a GUI application (may be also not gui) in a Threads, When the threads starts, the script shows error that says : The instruction at "0x28053f9a" referenced memory at "0x10c0". The memory ould not be "read". Click on OK to terminate the program Click on CANCEL to debug the program and sometimes it is The memory ould not be "Written" instead of "read". I actually found that if I use the module "Win32::API" it will generate this error and of course Win32::FileOp use internally this module. The threads works fine if I remove the "use Win32::FileOp;" line but I need to use it for the File Open and Save Dialogs. Any solutions or suggestions? Thank you in advance for help Ramy
[perl-win32-gui-users] CVS commit
In this commit: AbsLeft and AbsTop now can take arguments: AbsLeft(10) sets the absolute left co-ordinate of a window to 10 pixels, for example. GetEvent(name) will return the coderef for the specified NEM event handler. "name" should be an event name like "Resize". SetEvent(name, handler) will set the coderef for the specified NEM event handler. "name" should be an event name, and "handler" should be a code reference to a subroutine that will handle the event. You can use this to change event handlers to something else if you need to. Steve.
Re: [perl-win32-gui-users] Win32::FileOp Erro with Win32::GUI
Hi,
> is there an event to catch the mouse move over a button
Yes, you can try onMouseMove from the NEM:
my $button = new Win32::GUI::Button(
-name => "Hello",
-text => "bla bla",
-onMouseMove => \&mousemovehandler
);
sub mousemovehandler {
...
}
If that doesn't work, you can hook the MouseMove event using the Hook Event
Model:
$button->Hook(0x0200, \&mousemovehandler);
Steve
- Original Message -
From: [EMAIL PROTECTED]
To: Jez White ; Steve Pick ; perl-win32-gui-users@lists.sourceforge.net
Sent: Sunday, January 25, 2004 12:46 PM
Subject: Re: [perl-win32-gui-users] Win32::FileOp Erro with Win32::GUI
I solved the problem temp. by using the files dialogs from Win32::GUI
instead of using Win32::FileOp
The main issue is you keep updating either Perl or perl2exe or
the thousands of modules, once you finsh the current beta version
you get another beta and you may need to pay for ups...
Thanks for help
One last thing on my mind now, Is there an event to catch the mouse
move over a button. The reason I am thinking to use buttons instead
of the static toolbars and swap images when the button get the mouse over
and mouse out and active states. May be adding few functions to the tool bar
would
be more practically
Ramy
- Original
- Original Message -
From: Jez White
To: [EMAIL PROTECTED] ; Steve Pick ;
perl-win32-gui-users@lists.sourceforge.net
Sent: Sunday, January 25, 2004 2:23 PM
Subject: Re: [perl-win32-gui-users] Win32::FileOp Erro with Win32::GUI
Hummm. The perl2exe version looks fine - if the error is only happening
with the exe, and you can't reproduce it using the activestate build, then the
best bet is to get in touch with perl2exe support.
As for the 'x' issue - I assume the window is called "Main" and you are
returning the correct value?
jez.
- Original Message -
From: [EMAIL PROTECTED]
To: Jez White ; Steve Pick ; perl-win32-gui-users@lists.sourceforge.net
Sent: Sunday, January 25, 2004 12:03 PM
Subject: Re: [perl-win32-gui-users] Win32::FileOp Erro with Win32::GUI
Perl 2exe info below.
Yes the errors when I compile to exe and run it
but the close "x" issue is always with perl script or compiled
and I am using the terminate event Main_Terminate
---
Perl2Exe V8.00 Copyright (c) 1997-2004 IndigoSTAR Software
Known platforms: Win32
Target platform = Win32 5.008002
$I =
$ENV{'PERL5LIB'} =
Found perl.exe at C:\Perl\bin
LibList = C:\Perl\lib,C:\Perl\site\lib,.
Registered to XXX ENT version
Usage: perl2exe myscript.pl
options:
-smallGenerate smaller exe file (Pro version only)
-tiny Generate even smaller exe file (Pro version
only)
-gui Generate a no-console executable (Pro version
only)
-o=output_filenameOutput file name
-I=directory Specify @INC directory (multiple directories
can be
separated by ; or : characters)
-platform=Win32 Generate code for Win32 (default)
---
- Original Message -
From: Jez White
To: [EMAIL PROTECTED] ; Steve Pick ;
perl-win32-gui-users@lists.sourceforge.net
Sent: Sunday, January 25, 2004 1:55 PM
Subject: Re: [perl-win32-gui-users] Win32::FileOp Erro with Win32::GUI
Hi,
The latest version of perl2exe was on the 31 Dec 2003 - beta support
for 5.8.2 - if you haven't got this version, then you should upgrade. Is your
problem only with the exe?
The window close - are you using the terminate event?
Cheers,
jez.
Re: [perl-win32-gui-users] Status bar Parts method bug.
Hi Jez
Ok, noted. Interesting. I'll look into this on Monday.
Steve
- Original Message -
From: Jez White
To: Win32-GUI
Sent: Sunday, February 15, 2004 10:07 AM
Subject: [perl-win32-gui-users] Status bar Parts method bug.
Hi,
I've found a bug when using the parts method in the status bar control. All
the following statements fail (no error, application just exits):
$status->Parts($width-200,$width-100,-1);
my $temp=$status->Parts($width-200,$width-100,-1);
my @temp=$status->Parts($width-200,$width-100,-1);
While the following works:
print $status->Parts($width-200,$width-100,-1);
foreach ($status->Parts($width-200,$width-100,-1)) {print "$_ \n";}
See example below. I've created a task in the tracker.
Cheers,
jez.
=
use Win32::GUI;
use strict;
my $W = new GUI::Window(
-title=> "Win32::GUI::status test",
-left => 100,
-top => 100,
-width=> 300,
-height => 200,
-name => "main",
-onResize => \&main_resize
);
my $status=$W->AddStatusBar(-name => "Status");
$status->Parts(50,100,-1);
$status->PartText(0,'Lots of text');
$status->PartText(1,'Part 1');
$status->PartText(2,'Part 2');
$W->Show;
Win32::GUI::Dialog;
sub main_resize {
$status->Width($W->ScaleWidth);
$status->Top($W->ScaleHeight - $status->Height);
my $width=$status->Width;
#The following work:
print $status->Parts($width-200,$width-100,-1);
#foreach ($status->Parts($width-200,$width-100,-1)) {print "$_ \n";}
#The following fail:
#$status->Parts($width-200,$width-100,-1);
#my $temp=$status->Parts($width-200,$width-100,-1);
#my @temp=$status->Parts($width-200,$width-100,-1);
}
Re: [perl-win32-gui-users] Shipping resources with your exe
I'd find this functionality kinda handy. Loading resources from the exe is very simple, and it would not be too difficult to extend the Win32::GUI::Bitmap, Icon, etc. objects to accept an additional argument that indicates that the resource should be loaded from the exe rather than from a real file on disk (in fact, it would actually be a trivial matter to do this). What is less trivial is getting the resources in there in the first place. While ResHacker lets you do it, it'd be nice to see a Win32::GUI native way of doing it. Microsoft provides functions for adding, deleting and replacing resources in executable files and I propose we either: 1. Add this update/add/delete functionality into Win32::GUI so that applications can fiddle with their own resources. This may be an exceptionally bad idea (what exe file will it think it's using when running straight from Perl? We dont want it messing with perl.exe's resources) 2. Create a small tool that is distributed with Win32::GUI to pack resources into the exe. I doubt we can re-dist ResHacker with win32::gui and it'd be nice if there was this functionality provided. The Win32::GUI::Bitmap, Icon and Cursor objects could then be modified to first check for a resource identified by the given filename in the current running exe, and if it's not found attempt to use the given filename to load an external file. This seems the best mode of operation to me. Steve - Original Message - From: Jez White To: Win32-GUI Sent: Wednesday, February 18, 2004 6:34 PM Subject: [perl-win32-gui-users] Shipping resources with your exe Hi, One the problems I have when I ship my exe is ensuring that all the resources (bitmaps, cursors and config files) are valid when my app starts up. Typically, just including them in a sub directory can cause problems since the user could delete or alter them. The ideal solution would be to package the resources into the exe and extract them at runtime. See: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/WinUI/WindowsUserInterface/Resources.asp Adding the resources to the exe is quite straightforward (with reshacker) but I'm not sure how easy it would be to implement these function calls (or even it is possible), would anyone find this kind of functionality useful? Cheers, jez.
