Menu
▾
▴
perl-win32-gui-hackers — Hacking and developing the Win32::GUI Perl extension
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(4) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2003 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(31) |
Dec
(80) |
| 2004 |
Jan
(30) |
Feb
(31) |
Mar
(46) |
Apr
(31) |
May
(48) |
Jun
(16) |
Jul
|
Aug
|
Sep
(20) |
Oct
(31) |
Nov
(13) |
Dec
(1) |
| 2005 |
Jan
(4) |
Feb
(7) |
Mar
|
Apr
(3) |
May
(1) |
Jun
(37) |
Jul
(39) |
Aug
(22) |
Sep
(3) |
Oct
(48) |
Nov
(24) |
Dec
(31) |
| 2006 |
Jan
(4) |
Feb
(6) |
Mar
(19) |
Apr
(17) |
May
(39) |
Jun
(62) |
Jul
(11) |
Aug
(21) |
Sep
(10) |
Oct
(26) |
Nov
(8) |
Dec
|
| 2007 |
Jan
(7) |
Feb
(6) |
Mar
(2) |
Apr
|
May
|
Jun
(4) |
Jul
(10) |
Aug
(1) |
Sep
(2) |
Oct
|
Nov
(1) |
Dec
(2) |
| 2008 |
Jan
(19) |
Feb
(24) |
Mar
|
Apr
(4) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Glenn L. <pe...@ne...> - 2004-03-29 18:26:16
|
Hi Laurent,
I'm excited about all the enhancements you are making to Win32::GUI
these days, can hardly wait to try them out!
On approximately 3/28/2004 11:56 AM, came the following characters from
the keyboard of Laurent ROCHER:
> Hi,
>
> Some small bug fix :
> - UpDown :
> + Fix Scroll event.
> - GUI_Events.cpp :
> + In DoEvent_* functions : PERLWIN32GUI_EVENTHANDLING is set after
> event call.
>
> I looking for NEM support for accelerator and i don't know if my current
> implementation was good.
Of course a strong correlation to the behavior in OEM would be best, at
least as a default behavior. Other options could be considered, but
they should be options, not the default.
> If you look in sample below, you see it's always call -onClick window event
> with accelerator name but not call button click event like in OEM.
> For NEM support it's probably nicer to call Button click method like OEM do.
> What do you think ?
I would agree calling the button click event would be better.... if the
button click event exists.
So Accellerator table is made of
"key" => "name"
where _Click event should be called for the widget named "name". That
assumes that
1) A widget named "name" is defined
2) The widget supports a _Click event (in OEM, sub name_Click exists)
In OEM, I think if either of the above is false, that the accelerator
has no useful effect.
In NEM, the default behavior should be similiar: if the widget named
"name" exists, and has a sub defined for _Click event, it should be called.
But we could also define additional behaviors for accelerators...
A) Calling the _Click event of the parent Window, as you seem to be
presently doing, might be a nice default if there is no widget named
"name", or it has on _Click event.
B) Maybe instead of overusing the _Click event of the parent Window, one
could define a new parent -onAccel event, that would get called with the
accelerator name as a parameter, if there is no widget named "name".
I think if there is a widget named "name", and it doesn't have a _Click
event, then the accelerator for that name should be ignored until there
is a _Click event defined for that widget.
This would result in an extension to the current Accelerator support,
allowing definition of Accelerators that don't have corresponding GUI
actions. Which I think is not only OK, but could be very useful. One
could put the essence of the interface on the GUI, but one could define
Accelerator keys that could do complex combinations of GUI actions, or
even non-GUI actions, instead of being limited to the unit actions
available on the GUI.
C) One could change AcceleratorTable from
"key" => "name"
to also allow
"key" => sub { },
and this would get the parent window and the accelerator key as
parameters? And would completely decouple that accelerator key from any
named widget. Clearly this would be more work to implement, but would
nicely fit the NEM model, as far as I can tell.
> Laurent.
>
> use Win32::GUI;
>
> my $acc = new Win32::GUI::AcceleratorTable(
> "A" => "Window",
> "B" => "Button",
> );
>
> $W = new Win32::GUI::Window(
> -name => "Window",
> -title => "test",
> -pos => [100, 100],
> -size => [280, 280],
> -accel => $acc,
> # NEM call comment for OEM.
> -onClick => sub { my ($self, $name) = @_; print "Window OnClick :
> $name\n"; },
> );
>
> $W->AddButton(
> -name => "Button",
> -pos => [5, 5],
> -size => [100, 100],
> -text => "Just button",
> );
>
> $W->Show;
> Win32::GUI::Dialog();
>
> # OEM call
> sub Window_Click {
> print "Window_Click\n";
> }
>
> sub Button_Click {
> print "Button_Click\n";
> }
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Perl-Win32-GUI-Hackers mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-hackers
>
>
--
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.
|
|
From: Jez W. <je...@je...> - 2004-03-29 10:30:43
|
My 2 cents worth. I *really* like this approach. The idea of one handler is
much cleaner and simpler, especially when you have many items in the table.
Going one step further I'd like to see the same kind of approach taken for
menus!
cheers,
jez.
----- Original Message -----
From: "Laurent ROCHER" <ro...@cl...>
To: "Win32 GUI Hackers" <per...@li...>
Sent: Sunday, March 28, 2004 8:56 PM
Subject: Re: [perl-win32-gui-hackers] New Win32::GUI code in MAIN CVS.
> Hi,
>
> Some small bug fix :
> - UpDown :
> + Fix Scroll event.
> - GUI_Events.cpp :
> + In DoEvent_* functions : PERLWIN32GUI_EVENTHANDLING is set after
> event call.
>
> I looking for NEM support for accelerator and i don't know if my current
> implementation was good.
> If you look in sample below, you see it's always call -onClick window
event
> with accelerator name but not call button click event like in OEM.
> For NEM support it's probably nicer to call Button click method like OEM
do.
> What do you think ?
>
> Laurent.
>
> use Win32::GUI;
>
> my $acc = new Win32::GUI::AcceleratorTable(
> "A" => "Window",
> "B" => "Button",
> );
>
> $W = new Win32::GUI::Window(
> -name => "Window",
> -title => "test",
> -pos => [100, 100],
> -size => [280, 280],
> -accel => $acc,
> # NEM call comment for OEM.
> -onClick => sub { my ($self, $name) = @_; print "Window OnClick :
> $name\n"; },
> );
>
> $W->AddButton(
> -name => "Button",
> -pos => [5, 5],
> -size => [100, 100],
> -text => "Just button",
> );
>
> $W->Show;
> Win32::GUI::Dialog();
>
> # OEM call
> sub Window_Click {
> print "Window_Click\n";
> }
>
> sub Button_Click {
> print "Button_Click\n";
> }
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Perl-Win32-GUI-Hackers mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-hackers
|
|
From: Laurent R. <ro...@cl...> - 2004-03-28 19:58:05
|
Hi,
Some small bug fix :
- UpDown :
+ Fix Scroll event.
- GUI_Events.cpp :
+ In DoEvent_* functions : PERLWIN32GUI_EVENTHANDLING is set after
event call.
I looking for NEM support for accelerator and i don't know if my current
implementation was good.
If you look in sample below, you see it's always call -onClick window event
with accelerator name but not call button click event like in OEM.
For NEM support it's probably nicer to call Button click method like OEM do.
What do you think ?
Laurent.
use Win32::GUI;
my $acc = new Win32::GUI::AcceleratorTable(
"A" => "Window",
"B" => "Button",
);
$W = new Win32::GUI::Window(
-name => "Window",
-title => "test",
-pos => [100, 100],
-size => [280, 280],
-accel => $acc,
# NEM call comment for OEM.
-onClick => sub { my ($self, $name) = @_; print "Window OnClick :
$name\n"; },
);
$W->AddButton(
-name => "Button",
-pos => [5, 5],
-size => [100, 100],
-text => "Just button",
);
$W->Show;
Win32::GUI::Dialog();
# OEM call
sub Window_Click {
print "Window_Click\n";
}
sub Button_Click {
print "Button_Click\n";
}
|
|
From: Jez W. <je...@je...> - 2004-03-28 17:10:31
|
Agreed. I was thinking that we should have a set of simple examples for =
each control (toolbar.pl, listview.pl, listview2.pl, rebar.pl etc). As =
well, as complete applications, such as the notepad suggestion.=20
As a summery:
* All code commented
* No hardcoded constants=20
* Use methods, not send message
* Only use NEM (?).
Cheers,
jez.
----- Original Message -----=20
From: Laurent ROCHER=20
To: Jez White ; guihackers=20
Sent: Sunday, March 28, 2004 4:48 PM
Subject: Re: [perl-win32-gui-hackers] Examples for future builds
I think we need to keep caution than sample must be commented, well =
designed and don't show bad thing ;o)
I suggest not have hard coded constant or strange -style option, =
replace sendmessage by standard method (if availlable)...
We probably need small basic sample and more complex sample.
Why not rewrite notepad or program like that in Win32::GUI perl as =
demonstration ?
It's interresting for complex sample and usefull for test Win32:::GUI.
Laurent.
----- Original Message -----=20
From: Jez White=20
To: guihackers=20
Sent: Sunday, March 28, 2004 3:25 PM
Subject: [perl-win32-gui-hackers] Examples for future builds
Hi,
Laurent has created a directory under CVS for examples that will be =
included in future builds of the new code line.
I was thinking of committing some examples today - but was wondering =
if there is any formal process I should adhere to? I'm also going to ask =
for examples from the users mailing list, so hopefully we'll get a large =
varied collection together.
Thoughts?
jez. |
|
From: Laurent R. <ro...@cl...> - 2004-03-28 15:50:00
|
I think we need to keep caution than sample must be commented, well = designed and don't show bad thing ;o) I suggest not have hard coded constant or strange -style option, replace = sendmessage by standard method (if availlable)... We probably need small basic sample and more complex sample. Why not rewrite notepad or program like that in Win32::GUI perl as = demonstration ? It's interresting for complex sample and usefull for test Win32:::GUI. Laurent. ----- Original Message -----=20 From: Jez White=20 To: guihackers=20 Sent: Sunday, March 28, 2004 3:25 PM Subject: [perl-win32-gui-hackers] Examples for future builds Hi, Laurent has created a directory under CVS for examples that will be = included in future builds of the new code line. I was thinking of committing some examples today - but was wondering = if there is any formal process I should adhere to? I'm also going to ask = for examples from the users mailing list, so hopefully we'll get a large = varied collection together. Thoughts? jez. |
|
From: Laurent R. <ro...@cl...> - 2004-03-28 15:34:35
|
Hi All,
I commit new stuff.
I add reference of Sourceforge Tracker BUG and RFE in changelog.
I close someone but need to check if other can be already close or fix.
Changelog :
[#627779] : Not able use with embedded perl
[#918896] : No [Dbl]RightClick events in NEM
[#921170] : 670: DC Circle strange arguments
[#918899] : No NotifyIcon support in NEM
[#880798] : Accelerators don't work with NEM
Add destroy window mechanism and free perlud ressource when windows
destroy
Add NEM support for notifyIcon.
Add full mouse support (left/middle/right mousedown, mouseup,
mouseDblClick)
- Annimation.xs :
+ Correct Event handling and add OpenEx method.
- Button.xs :
+ Use dwFlags & dwFlagsMask in perlcs for set check state.
+ Fix GetCheck and SetCheck Alias.
- Combobox.xs :
+ Add ComboboxEx ExtendedStyle.
+ Add some documentation and missing methods.
- DC.xs :
+ Fix Circle method.
- GUI.h :
+ Add new dwFlagsMask value in PERLWIN32GUI_CREATESTRUCT and a
BitmaskOptionValueMask macro
+ Add PERLUD_FREE macro calling new Perlud_Free function.
+ Add new common Event constant.
- GUI.pm :
+ Win32::GUI::_new : Use tie return value for safe.
+ Win32::GUI::Window::DESTROY : Change timer/notifyicon clean up
(probably no more need).
+ Win32::GUI::Timer : Change new and Destroy method.
We store timer name in -timers parent hash, and Timer object only
1 time as parent child.
We don't store window parent reference in Timer object for avoid
circular reference.
+ Win32::GUI::NotifyIcon : Change new and Destroy method.
Same mechanism than Timer.
+ In Win32::GUI::WindowProps HASH mechanism :
Add a DESTROY method and call DestroyWindow for remove Self
Window.
- GUI.xs :
+ RegisterClassEx() : Unregister class if first register fail, and
re-try to register.
+ Create : Increment self reference when add to parent hash.
+ DoModal : Remove a forget printf.
- GUI_Events.cpp :
+ DoEvent_Timer() : Change timer name search (related new method
change)
+ DoEvent_NotifyIcon() : Change NotifiIcon name and object search
(related new method change)
and add NEM event support.
- GUI_Helpers.cpp :
+ Add Perlud_Free : Free all allocated data in perlud (hvEvent,
avHooks, svSelf and perlpud).
Use PERLUD_FREE macro for call it.
- GUI_MessageLoops.cpp :
+ Add PERLUD_FREE on WN_DESTROY event.
+ Add new standard event : MouseDblClick, MouseRightDown,
MouseRightUp, MouseRightDblClick,
MouseMiddleDown, MouseMiddleUp,
MouseMiddleDblClick, Char.
+ Add new NotifyIcon event : DblClick, RightDblClick, MiddleClick,
MiddleDblClick.
+ In CustomMsgLoop : Call ControlMsgLoop if PERLWIN32GUI_INTERACTIVE
style flag is set.
- GUI_Options.cpp :
+ ParseNEMEvent : Add new standard event.
+ Add ParseNotifyIconOptions and ParseNEMNotifyIconEvent : add NEM
support for NotifyIcon.
- NotifyIcon.xs :
+ Use ParseNotifyIconOptions for parsing option and NEM event.
- Splitter.xs :
+ Splitter_onEvent : Fix PerlResult return.
- Window.xs :
+ Graphic_onEvent & Graphic_onParseEvent : Clean Interactive
graphics event handling.
Now, CustomMsgLoop call ControlMsgLoop if PERLWIN32GUI_INTERACTIVE
style flag is set.
Ouf ;o)
I try to commit less thing next time.
Laurent
|
|
From: Jez W. <je...@je...> - 2004-03-28 13:25:48
|
Hi, Laurent has created a directory under CVS for examples that will be = included in future builds of the new code line. I was thinking of committing some examples today - but was wondering if = there is any formal process I should adhere to? I'm also going to ask = for examples from the users mailing list, so hopefully we'll get a large = varied collection together. Thoughts? jez. |
|
From: Laurent R. <ro...@cl...> - 2004-03-26 19:06:06
|
Hi,
I correct and commit some little bug.
Changelog :
- GUI.h : PERLUD_FROM_WND macro return now 0 (MinGW Warning).
- GUI.pm :
+ new Graphic method use standard _new creation (and replace hard
coded constant)
+ Fix timer DESTROY
- Window.xs : Graphic_onEvent return Perlresult (and not 0).
For building with MinGW, you need to upgrade to last w32api-2.5.
http://www.mingw.org/download.shtml#hdr2
Laurent.
|
|
From: Laurent R. <ro...@cl...> - 2004-03-25 23:26:46
|
Hi all,
I have commit new Win32::GUI code in CVS [Module : Win32-GUI, Branch : =
HEAD].
Changelog :
- New Base code :=20
+ Separate each control in a specific XS file.
+ Add callback function for each control (onPreCreate, =
onParseOption, onPostCreate, onParseEvent, OnEvent).
+ Rewrite Event Loop.
+ Merge all event firing code in on function (DoEvent) for OEM =
and NEM.
+ New DoModal function.
+ Improve Change method.
+ Add lot of control Win32 API method. (Keep alphabetical order =
and standard API name). =20
+ Add new events for control.
+ Some Clean Up.
+ Reduce size of allocate structure per window.
+ Add Perl context handling.
+ and more...
- Fix doc tools generator (DoDoc.pl and DoHtml.pl)
I have add docs and samples directory in CVS too for have a complet =
tree.
In docs, you can found two scripts :
dodoc.pl : for generate pod files from sources codes.
dohtml.pl : for transform pod to html.
In Samples, i have commit one sample i made for show EOM/NEM/BOTH event =
model.
Laurent. |
|
From: Jez W. <je...@je...> - 2004-03-25 10:03:55
|
Ok, I've tested your changes and it all looks good. I'll continue to use the dev PPM today, just to make sure. Looking forward to the new code line:) Cheers, jez. ----- Original Message ----- From: "Laurent ROCHER" <ro...@cl...> To: "Jez White" <je...@je...> Cc: <per...@li...> Sent: Wednesday, March 24, 2004 9:38 PM Subject: Re: [perl-win32-gui-hackers] Odd problem with 671 > I think i found problem. > > I solve multiple problem of uninitialised variable. > I have commit my change on 655-Fix CVS. > - GUI_MessageLoops.cpp : Fix multiple problem with NEM event and > painting problem. > - GUI.xs : Correct problem with wndprocPreNEM changed two time. > - GUI_Options.cpp : Correct uninitialised variable problem. > > I think it's explain why it's different from compiler and perl version. > > I use generaly Perl58 and i not use lot of NEM event in my script. > So it's explain why it can show this problem before. > I have made dev PPM, can you test it with your scipts : > http://perso.club-internet.fr/rocherl/Win32-GUI-Dev/index.html > > The good news it's, i haven't this problem with my new base code ;o) > I preparing it for commit in Win32-GUI MAIN branch. > > Laurent. > > > > Ok, below is another example of issues between a Ming built 671 and VC > built > > 671 (via the sourceforge PPM). This one is more worrying since it is > > effecting NEM/OEM. The Ming built 671 works correctly. > > > > The example creates a main window, with a child window contained with in > it. > > The child window has two NEM events, scroll and resize. The main window > has > > code for the OEM event Resize. > > > > Under VC: The only event that works is the NEM scroll event in the child > > window. > > Under Ming: All events work (the OEM parent window resize, and the child > NEM > > resize and NEM scroll) > > > > Both examples were run under perl 5.6. > > > > Very strange. > > > > jez. > |
|
From: Laurent R. <ro...@cl...> - 2004-03-24 21:39:18
|
I think i found problem.
I solve multiple problem of uninitialised variable.
I have commit my change on 655-Fix CVS.
- GUI_MessageLoops.cpp : Fix multiple problem with NEM event and
painting problem.
- GUI.xs : Correct problem with wndprocPreNEM changed two time.
- GUI_Options.cpp : Correct uninitialised variable problem.
I think it's explain why it's different from compiler and perl version.
I use generaly Perl58 and i not use lot of NEM event in my script.
So it's explain why it can show this problem before.
I have made dev PPM, can you test it with your scipts :
http://perso.club-internet.fr/rocherl/Win32-GUI-Dev/index.html
The good news it's, i haven't this problem with my new base code ;o)
I preparing it for commit in Win32-GUI MAIN branch.
Laurent.
> Ok, below is another example of issues between a Ming built 671 and VC
built
> 671 (via the sourceforge PPM). This one is more worrying since it is
> effecting NEM/OEM. The Ming built 671 works correctly.
>
> The example creates a main window, with a child window contained with in
it.
> The child window has two NEM events, scroll and resize. The main window
has
> code for the OEM event Resize.
>
> Under VC: The only event that works is the NEM scroll event in the child
> window.
> Under Ming: All events work (the OEM parent window resize, and the child
NEM
> resize and NEM scroll)
>
> Both examples were run under perl 5.6.
>
> Very strange.
>
> jez.
|
|
From: Jez W. <je...@je...> - 2004-03-24 12:04:46
|
Ok, below is another example of issues between a Ming built 671 and VC built
671 (via the sourceforge PPM). This one is more worrying since it is
effecting NEM/OEM. The Ming built 671 works correctly.
The example creates a main window, with a child window contained with in it.
The child window has two NEM events, scroll and resize. The main window has
code for the OEM event Resize.
Under VC: The only event that works is the NEM scroll event in the child
window.
Under Ming: All events work (the OEM parent window resize, and the child NEM
resize and NEM scroll)
Both examples were run under perl 5.6.
Very strange.
jez.
===========================
use Win32::GUI;
use strict;
my $mainwin = new Win32::GUI::Window(
-name => 'Main',
-text => 'Main',
-width => 686,
-height => 566,
);
my $win = new Win32::GUI::Window (
-parent => $mainwin,
-name => "TabWindow",
-height => 200,
-width => 200,
-top => 0,
-left => 0,
-popstyle => WS_CAPTION | WS_SIZEBOX,
-pushstyle => WS_CHILD,
-pushexstyle => WS_EX_CLIENTEDGE,
-hscroll => 1,
-onResize => sub {print "NEM TabWindow resize \n"},
-onScroll => sub {print "NEM TabWindow scroll \n"},
);
$mainwin->Show();
$win->Show();
Win32::GUI::Dialog;
sub ::Main_Resize {
my ($width, $height) = ($mainwin->GetClientRect)[2..3];
print "main resize \n";
$win->Resize($width,$height);
return 1;
}
----- Original Message -----
From: "Laurent ROCHER" <ro...@cl...>
To: "Jeremy White" <jez...@ho...>; <je...@je...>;
<per...@li...>
Sent: Tuesday, March 23, 2004 9:23 PM
Subject: Re: [perl-win32-gui-hackers] Odd problem with 671
>
> I have the backgound paint problem only in perl 5.6 with VC.
> But, work nice in perl5.005 (VC), perl56 (MinGW) and perl 5.8 (VC &
MINGW).
>
> I don't know what wrong.
>
> Laurent.
>
> > Today has been one of those days - if it can go wrong, it has!
> >
> > Anyway, I've retested - and there is a problem - although I'm having
> > difficult in getting a small enough example working (I'll try again in
the
> > morning). However, I came across another issue with PPM 671 and 671
built
> > with ming. The issue is with the -flicker option.
> >
> > I'm on XP, with 5.6.1 (I'll do testing on win98 boxes tomorrow).
> >
> > The example below (created by Steve a couple of months back) runs fine
on
> > ming 671, but with the PPM version the background of the window isn't
> > painted, causing a mess in the window.
> >
> > Very strange.
> >
> > Cheers,
> >
> > jez.
>
|
|
From: Laurent R. <ro...@cl...> - 2004-03-23 21:24:24
|
I have the backgound paint problem only in perl 5.6 with VC. But, work nice in perl5.005 (VC), perl56 (MinGW) and perl 5.8 (VC & MINGW). I don't know what wrong. Laurent. > Today has been one of those days - if it can go wrong, it has! > > Anyway, I've retested - and there is a problem - although I'm having > difficult in getting a small enough example working (I'll try again in the > morning). However, I came across another issue with PPM 671 and 671 built > with ming. The issue is with the -flicker option. > > I'm on XP, with 5.6.1 (I'll do testing on win98 boxes tomorrow). > > The example below (created by Steve a couple of months back) runs fine on > ming 671, but with the PPM version the background of the window isn't > painted, causing a mess in the window. > > Very strange. > > Cheers, > > jez. |
|
From: Jeremy W. <jez...@ho...> - 2004-03-23 20:42:42
|
Today has been one of those days - if it can go wrong, it has!
Anyway, I've retested - and there is a problem - although I'm having
difficult in getting a small enough example working (I'll try again in the
morning). However, I came across another issue with PPM 671 and 671 built
with ming. The issue is with the -flicker option.
I'm on XP, with 5.6.1 (I'll do testing on win98 boxes tomorrow).
The example below (created by Steve a couple of months back) runs fine on
ming 671, but with the PPM version the background of the window isn't
painted, causing a mess in the window.
Very strange.
Cheers,
jez.
=======================
use Win32::GUI;
use Win32::API;
use warnings;
use strict;
# Our MAIN window on the desktop.
my $mainwindow = new Win32::GUI::Window(
-name => "mainwindow",
-pos => [100, 100],
-size => [200,200],
-text => "Scrolling subwindow demo",
-noflicker => 1,
-onResize => \&mainresize
);
# Our window with horizontal scrollbar inside the main window
my $scrollwindow = new Win32::GUI::Window (
-parent => $mainwindow,
-name => "scrollwindow",
-pos => [20,20],
-size => [$mainwindow->ScaleWidth - 40,$mainwindow->ScaleHeight - 40],
-popstyle => WS_CAPTION | WS_SIZEBOX, # Remove caption and sizing handles
-pushstyle => WS_CHILD,
-hscroll => 1,
-noflicker => 1,
-onScroll => \&scrolled
);
# Our scrollable area inside the window with scrollbars
my $scrollarea = new Win32::GUI::Window (
-parent => $scrollwindow,
-name => "scrollarea",
-pos => [0,0],
-noflicker => 1,
-size => [400,$scrollwindow->ScaleHeight],
-popstyle => WS_CAPTION | WS_SIZEBOX,
-pushstyle => WS_CHILD
);
# Define some scrolling parameters
$scrollwindow->ScrollRange(0,0,$scrollarea->ScaleWidth);
$scrollwindow->ScrollPage(0,$scrollwindow->ScaleWidth);
# Add some buttons:
for(0..4) {
$scrollarea->AddButton(
-name => "Button".$_,
-pos => [$_ * 100,0],
-size => [100,$scrollwindow->ScaleHeight],
-text => "Button $_",
-onClick => sub { print 'click';}
);
}
$mainwindow->Show();
$scrollwindow->Show();
$scrollarea->Show();
Win32::GUI::Dialog;
sub scrolled {
# scrolling handler.
my($obj, $scrollbar, $operation, $position) = @_;
# Move the scrollbar and set the left edge of the scrollarea at the same
time:
my $realpos = $scrollwindow->Scroll($scrollbar, $operation, $position);
# If we're dragging the thumb we want a live update:
if($operation == SB_THUMBTRACK) { $realpos = $position };
$scrollarea->Left(0 - $realpos);
}
sub mainresize {
$scrollwindow->Width($mainwindow->ScaleWidth - 40);
$scrollwindow->Height($mainwindow->ScaleHeight - 40);
$scrollarea->Height($scrollwindow->ScaleHeight);
$scrollwindow->ScrollRange(0,0,$scrollarea->ScaleWidth);
$scrollwindow->ScrollPage(0,$scrollwindow->ScaleWidth);
$scrollarea->Left(0 - $scrollwindow->ScrollPos(0));
for(0..4) {
$scrollarea->{"Button$_"}->Height($scrollarea->ScaleHeight);
}
}
_________________________________________________________________
Sign-up for a FREE BT Broadband connection today!
http://www.msn.co.uk/specials/btbroadband
|
|
From: Laurent R. <ro...@cl...> - 2004-03-23 18:17:19
|
Yes it's very strange. What version do you use (5.005, 5.6, 5.8) ? Do you have a small sample with this problem ? What is you child window ? (button, ...) I made some test and don't reproduce your problem. Laurent. ----- Original Message -----=20 From: Jez White=20 To: guihackers=20 Sent: Tuesday, March 23, 2004 5:58 PM Subject: [perl-win32-gui-hackers] Odd problem with 671 Hi, I'm having a *really* strange problem with the binary version of 671. = Basically, some of my child windows (window within a window) aren't = receiving any events (!?). However, if I build 671 with ming, then the = windows receive the events... Thoughts? Jez. |
|
From: Jez W. <je...@je...> - 2004-03-23 16:57:12
|
Hi, I'm having a *really* strange problem with the binary version of 671. = Basically, some of my child windows (window within a window) aren't = receiving any events (!?). However, if I build 671 with ming, then the = windows receive the events... Thoughts? Jez. |
|
From: Laurent R. <ro...@cl...> - 2004-03-22 21:03:27
|
Hi All, A new Win32::GUI release is availlable. This release come from 0.0.665 Fix CVS branch. See on sourceforge for sources and PPM for ActivePerl 5.005, 5.6 & 5.8. http://sourceforge.net/projects/perl-win32-gui This release of Win32::GUI introduces many bug fix and new features : New : - Add anti-flicker option (-noflicker). - Add new methods and documentation for TabStrip, StatusBar, Rebard, = Toolbar. - Add new options for Menu. - Add loading ressources from exe file. - Add SetEvent and GetEvent for NEM event system. - Add support for scrollbar in Window and DialogBox. Fix : - Left() and Top() don't perform translation for non child window. - Update Hook for multiple hooks per message. - Fix some event handling problems. - Fix some doc generation problems. Html documentation is include in PPM distribution and automaticly add in = ActiveState package index documentation. Have fun, Laurent. |
|
From: Laurent R. <ro...@cl...> - 2004-03-22 16:47:06
|
> > If this script isn't too complex it's could be nice to add it in Samples > > directory. > > I think to add this directory in main CVS for provide nice samples with > > Win32::GUI. > Most of my test scripts are simple, they just test a single control or > various GUI concepts. > > If you create a directory on CVS I'll commit them. I'll also send a email to > the users list asking for people to mail me examples, and I'll commit any > responses I get. I'll also search though the mailing list and pull out any > good examples I find. It's probably too short for 0.0.671 (i have finish build all zip ;o). I finish all for 0.0.671 release in 665-fix branch. After this branch should be considered close. For next major release, we can work on MAIN Win32-GUI branch. If Aldo and others are agree, i can commit my code as base code for it. I include Samples, Docs and t directory in it, so we have a complete Win32-GUI tree. > You can never have to many examples:) I agree ;o) Laurent. |
|
From: Jez W. <je...@je...> - 2004-03-22 16:08:31
|
> If this script isn't too complex it's could be nice to add it in Samples > directory. > I think to add this directory in main CVS for provide nice samples with > Win32::GUI. Most of my test scripts are simple, they just test a single control or various GUI concepts. If you create a directory on CVS I'll commit them. I'll also send a email to the users list asking for people to mail me examples, and I'll commit any responses I get. I'll also search though the mailing list and pull out any good examples I find. You can never have to many examples:) Cheers, jez. |
|
From: Aldo C. <da...@pe...> - 2004-03-22 13:20:59
|
On Mon, 2004-03-22 at 14:00, Laurent ROCHER wrote: > If this script isn't too complex it's could be nice to add it in Samples > directory. I think to add this directory in main CVS for provide nice samples with > Win32::GUI. I definitely agree. > I don't know how to update ActiveState repository. > If Aldo put a new Win32-GUI dist file in his CPAN repository, it's > automaticly update in ActiveState ? AFAIK, if the distribution passes the test suite, it is automatically updated in the ActiveState repository. there maybe a problem, however, because some time ago they arbitrarily decided that Win32::GUI was version 0.99 (yes, sometimes ActiveState sucks), and so if we release something like 0.0.671 this will result older than what they already have in the repository. but I will update the file on CPAN nonetheless, and we'll see what happens. cheers, Aldo |
|
From: Laurent R. <ro...@cl...> - 2004-03-22 13:01:22
|
> Good work Laurent! I had a quick glance through your dev codeline, and it > looks good. I'm quite interested in the DoModal stuff:) I've got quite a few > test scripts, so once you've committed these changes I'll run through them. If this script isn't too complex it's could be nice to add it in Samples directory. I think to add this directory in main CVS for provide nice samples with Win32::GUI. > > With the 671 build, perhaps it's time for a bit of self promotion and spread > this build around the web (update the activestate repository etc)? > I don't know how to update ActiveState repository. If Aldo put a new Win32-GUI dist file in his CPAN repository, it's automaticly update in ActiveState ? Laurent |
|
From: Laurent R. <ro...@cl...> - 2004-03-22 12:50:16
|
> Apologies, I haven't read your code yet, so I might have asked something
> obvious in the below. You are "on a roll" Laurent! It all sounds good!
>
> On approximately 3/21/2004 11:02 AM, came the following characters from
> the keyboard of Laurent ROCHER:
>
> > I continue my work on refactoring Win32::GUI code.
> > I have made lot of change :
> > - Add some more methods for controls
>
> Would this happen to include RightClick and DblRightClick ?
Yes those events are handle for control supporting then.
Generaly, Common Control (TreeView, ...) support them via standard notify
code (NM_RCLICK, NM_RDBLCLK).
Basic control (button, label, textfield, ...) have sometime specific message
for that but don't work for every control.
However, all control receive standard window mouse event (WM_MOUSEMOVE,
WM_LBUTTONDOWN, WM_LBUTTONUP, ...).
Those events are handle by MouseMove, MouseDown, MouseUp event.
It's possible to add RMouseDown, RMouseUp, MMouseDown, MMouseUp for Right
and Middle button click.
Click/DblClick event are different than standard mouse event, it's control
dependent.
Event name isn't unified, for sample :
- Graphic generate LButtonDown instead MouseDown and have a RButtonDown
event didn't exist for other control.
- Listbox have a Click event when receive LBN_SELCHANGE. A Change event
should be nicer.
I don't change this for compatibility reason.
>
> > Each event is fire by a unique DoEvent method (same concept
DoEventNEM
> > with arglist).
> > DoEvent handle NEM and OEM event call. (UEM?)
>
> This sounds more efficient. UEM doesn't exist yet, it is what I named a
> concept that would seem to unify OEM, NEM, and Aldo's next generation
> event model.
Yes all event firing code using only one function (easier to change, add
model event).
>
> I think the big interface change with Aldo's next generation event model
> was the addition of the window widget object reference as a parameter to
> the event sub. Neither OEM nor NEM passed that, so you can't add it
> easily without being incompatible. It would be useful, though, to have
> the object reference as a parameter but would require a new flag to
> indicate that the -on* and -event defined subs were expecting the new
> parameter (which should probably be the first parameter).
>
> So I'm not sure if you should call your new DoEvent UEM quite yet, but
> it seems a good foundation step in that direction.
NEM event always send window self reference as first parameter.
I don't think it's usefull for OEM event because function use window name.
It's a good reason to use NEM event ;o)
But, it's possible to add a new event model option switch for do that.
Something like -eventmodel => [both, byref, byname, byname_self].
byname_self is same than byname but with a self as first parameter.
A global SetEventModel can be usefull for setup default event model (actualy
it's BYNAME by default).
> > - Try Write code for NotifyIcon and Accelerator NEM handling (not
tested
> > yet)
>
> Thanks, I'll take a look at this when I get a chance. Since I'd gone a
> certain distance in converting to NEM in my project, and didn't want to
> back-out all that code, I had actually implemented a couple "wrapper"
> functions that searched for -on* and -event, and processed them in Perl,
> using eval to create NAME_EVENT (OEM style) subs that call the NEM
> subs, and then eliminated those parameters (-on* and -event) from the
> calls to Win32::GUI, resulting in OEM. Well, the upshot is that I am
> using NEM style calls, and converting them to OEM on the fly, so I
> should be able to quickly flip-flop my application between using OEM and
> NEM. Which might help in my testing of your additions, if I get time to
> do that.
Ok, i understand why you want self in OEM ;o)
I have same problem with my TabFrame package (NEM didn't exist when i write
it).
I need to keep all instance in a global hash, doing something like that :
# Keep object reference
$Instance{$options{-name}} = $self;
# Add Click Event
eval qq(
sub main::$options{-name}_Click {
return Win32::GUI::TabFrame->ClickEvent($options{-name});
}
);
sub ClickEvent {
my $class = shift;
my $name = shift;
my $element = $Instance{$name};
...
}
NEM, it's easier for that ;o)
Actually, with new event model handling, NEM and OEM work in concert (adding
a new event handle, it's handle in both mode).
Laurent.
|
|
From: Jez W. <je...@je...> - 2004-03-22 11:32:55
|
Good work Laurent! I had a quick glance through your dev codeline, and it looks good. I'm quite interested in the DoModal stuff:) I've got quite a few test scripts, so once you've committed these changes I'll run through them. With the 671 build, perhaps it's time for a bit of self promotion and spread this build around the web (update the activestate repository etc)? cheers, jez. ----- Original Message ----- From: "Laurent ROCHER" <ro...@cl...> To: <per...@li...> Cc: "Aldo Calpini" <da...@pe...> Sent: Sunday, March 21, 2004 7:02 PM Subject: Re: [perl-win32-gui-hackers] Time for a new Release ? and start next Win32::GUI implementation > Hi All, > > > > On approximately 3/14/2004 8:00 PM, came the following characters from > > the keyboard of Glenn Linderman: > > > > > I'd rather not hold anything up, > > > but I need NotifyIcon support if I'm going to use NEM. > > > > Please don't hold up a release on my account. I've chosen to back out > > my attempt to convert code from OEM to NEM... > > > > Ok, if nobody have objection, i made a new release tomorrow. > I tag this release as Win32-GUI-0_0_671 on CVS and upload source and PPM on > sourceforge. > > > And good luck with NEM and UEM development. I'll try to keep tracking > > progress, and offering suggestions that might be helpful, but for now I > > simply must finish my project, as it has customers with a deadline. > > I continue my work on refactoring Win32::GUI code. > I have made lot of change : > - Add some more methods for controls > - Extend callback function to all control. It's probably interresting to > continue in this way for add posibility to create Win32::GUI extension by > adding a system for register callback function. > - Completly rewrite message loop and event handling. > I rewrite all messageloop and keep common event handling in it. > I think message loop are now much easier. > WindowMsgLoop : Message loop for main window class > (WINDOW,DIALOGBOX) > ControlMsgLoop : for child message loop. Use for subclassing > standard child control and Win32::GUI::Class. > ContainerMsgLoop : Special message loop for create container class > with Win32::GUI::Class. > CustomMsgLoop : Special message loop for create specific > Win32::GUI control (splitter, graphics). > Now all specific event is handle in a <Control>_OnEvent callback > function. > Each event is fire by a unique DoEvent method (same concept DoEventNEM > with arglist). > DoEvent handle NEM and OEM event call. (UEM?) > - Try Write code for NotifyIcon and Accelerator NEM handling (not tested > yet) > - New DoModal() (based Aldo previous mail) > - Some code cleanup > - Fix some problem with url link in dodoc.pl and dohtml.pl. > - ... > > I have test some script and it's work not to bad. > I try to keep compatibility with previous version. > > You can see a copy of my developpement directory here : > http://perso.club-internet.fr/rocherl/Win32-GUI-Dev/Win32-GUI.zip > > After Win32::GUI 0.0.671 release, i think we can work on this base code for > next release. > It's probably better to use Main Win32-GUI CVS branch now. > > Cheers, > Laurent > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > Perl-Win32-GUI-Hackers mailing list > Per...@li... > https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-hackers |
|
From: Glenn L. <pe...@ne...> - 2004-03-22 09:44:58
|
Apologies, I haven't read your code yet, so I might have asked something obvious in the below. You are "on a roll" Laurent! It all sounds good! On approximately 3/21/2004 11:02 AM, came the following characters from the keyboard of Laurent ROCHER: > I continue my work on refactoring Win32::GUI code. > I have made lot of change : > - Add some more methods for controls Would this happen to include RightClick and DblRightClick ? > Each event is fire by a unique DoEvent method (same concept DoEventNEM > with arglist). > DoEvent handle NEM and OEM event call. (UEM?) This sounds more efficient. UEM doesn't exist yet, it is what I named a concept that would seem to unify OEM, NEM, and Aldo's next generation event model. I think the big interface change with Aldo's next generation event model was the addition of the window widget object reference as a parameter to the event sub. Neither OEM nor NEM passed that, so you can't add it easily without being incompatible. It would be useful, though, to have the object reference as a parameter but would require a new flag to indicate that the -on* and -event defined subs were expecting the new parameter (which should probably be the first parameter). So I'm not sure if you should call your new DoEvent UEM quite yet, but it seems a good foundation step in that direction. > - Try Write code for NotifyIcon and Accelerator NEM handling (not tested > yet) Thanks, I'll take a look at this when I get a chance. Since I'd gone a certain distance in converting to NEM in my project, and didn't want to back-out all that code, I had actually implemented a couple "wrapper" functions that searched for -on* and -event, and processed them in Perl, using eval to create NAME_EVENT (OEM style) subs that call the NEM subs, and then eliminated those parameters (-on* and -event) from the calls to Win32::GUI, resulting in OEM. Well, the upshot is that I am using NEM style calls, and converting them to OEM on the fly, so I should be able to quickly flip-flop my application between using OEM and NEM. Which might help in my testing of your additions, if I get time to do that. -- 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. |
|
From: Laurent R. <ro...@cl...> - 2004-03-21 19:03:31
|
Hi All,
> On approximately 3/14/2004 8:00 PM, came the following characters from
> the keyboard of Glenn Linderman:
>
> > I'd rather not hold anything up,
> > but I need NotifyIcon support if I'm going to use NEM.
>
> Please don't hold up a release on my account. I've chosen to back out
> my attempt to convert code from OEM to NEM...
>
Ok, if nobody have objection, i made a new release tomorrow.
I tag this release as Win32-GUI-0_0_671 on CVS and upload source and PPM on
sourceforge.
> And good luck with NEM and UEM development. I'll try to keep tracking
> progress, and offering suggestions that might be helpful, but for now I
> simply must finish my project, as it has customers with a deadline.
I continue my work on refactoring Win32::GUI code.
I have made lot of change :
- Add some more methods for controls
- Extend callback function to all control. It's probably interresting to
continue in this way for add posibility to create Win32::GUI extension by
adding a system for register callback function.
- Completly rewrite message loop and event handling.
I rewrite all messageloop and keep common event handling in it.
I think message loop are now much easier.
WindowMsgLoop : Message loop for main window class
(WINDOW,DIALOGBOX)
ControlMsgLoop : for child message loop. Use for subclassing
standard child control and Win32::GUI::Class.
ContainerMsgLoop : Special message loop for create container class
with Win32::GUI::Class.
CustomMsgLoop : Special message loop for create specific
Win32::GUI control (splitter, graphics).
Now all specific event is handle in a <Control>_OnEvent callback
function.
Each event is fire by a unique DoEvent method (same concept DoEventNEM
with arglist).
DoEvent handle NEM and OEM event call. (UEM?)
- Try Write code for NotifyIcon and Accelerator NEM handling (not tested
yet)
- New DoModal() (based Aldo previous mail)
- Some code cleanup
- Fix some problem with url link in dodoc.pl and dohtml.pl.
- ...
I have test some script and it's work not to bad.
I try to keep compatibility with previous version.
You can see a copy of my developpement directory here :
http://perso.club-internet.fr/rocherl/Win32-GUI-Dev/Win32-GUI.zip
After Win32::GUI 0.0.671 release, i think we can work on this base code for
next release.
It's probably better to use Main Win32-GUI CVS branch now.
Cheers,
Laurent
|
18 messages has been excluded from this view by a project administrator.
