perl-win32-gui-hackers — Hacking and developing the Win32::GUI Perl extension

Re: [perl-win32-gui-hackers] GUI samples

[Jez W. <je...@je...>]

> Well, when I compare what I have in my old build area (downloaded
> snapshot) to what I now see via CVS, they appear to be not there.  It is
> not clear to me where they would then be added from, or what technique
> of "not there" was used other than deletion :)

Humm. I'm wrong then. I was under the assumption that the examples CVS
folder was a relatively new addition:)

> > Many previous examples (even the one's that work) use none
> > standard coding, which just cause confusion - for me anyway:)
>
> I certainly have no objection to samples being modified to use standard
> coding, but I'm not sure what non-standard coding was used that was
> confusing.

Many of the smaller examples are ok, but the larger examples use code that
hacks into the internals (typically for functionality that now exists in
base code). A smaller problem is that all of the old examples use OEM.

> If there isn't time to update the sample to use better coding, one could
> add some comments to it (no risk in adding comments) describing the
> non-standard-ness of the coding, but leaving the sample for whatever
> educational value it might have.  ???  I learned a good bit of GUI
> coding from those old samples, although I agree that I got a bit
> confused by some of them, also.

Good idea. I guess it's more of a question to who will do it?:) I don't mind
doing a few, but perhaps someone should "own" the task and divide it out to
those who are willing?

> > Perhaps we should put a call out to the users list for ideas of what
should
> > be included (like the scrolling bitmap example you mentioned) and for
> > volunteers to write them?
>
> I certainly have no objections to this activity, I can't imagine anyone
> that would.  Certainly if someone contributes a concise sample that
> demonstrates some activity (and all the currently-in-CVS samples do
> that, but so do some of the old ones :)), I would lobby for it to be
> included in the samples directory.  And if it is more than a file or 3,
> probably to be included in a samples subdirectory.  And once we go to
> samples subdirectories, the samples wouldn't even need to be that
> concise.... if they are showing a complex topic.

Yeah, I agree. I like the idea of having simple examples for all
controls/core functionality, (say treeview1.pl, treeview2.pl, listview1.pl
etc), as well as more complete applications, such as win32::gui notepad,
paint, calculator etc. Again it would take someone to own, organise and dish
out the tasks.

Cheers,

jez.

Re: [perl-win32-gui-hackers] GetOpenFileName enhancement

[Johan L. <jo...@Da...>]

Hehe :)

My point is that the module should hide the memory management junk from me.

If I use the module, I want the user to select files, I don't want to 
allocate memory. I don't want to have to care about that. So the default 
behaviour should work for most people, most of the time. No surprises. The 
performance overhead in this case can obviously be ignored.

The default behaviour should be overridable for those moments where the 
default buffer is too small or too large. But that's a bonus.


/J
-------- ------ ---- --- -- --  --  -     -     -        -          -
Johan Lindström    Sourcerer @ Boss Casinos   johanl AT DarSerMan.com

Latest bookmark: "Oracle Connection Manager Parameters (cman.ora..."
<http://download-west.oracle.com/docs/cd/B10501_01/network.920/a96581/cman.htm#496765>
dmoz (1 of 7): /Computers/Internet/E-mail/Free/ 9

Re: [perl-win32-gui-hackers] GUI.xs (BeginPaint and EndPaint)

[Glenn L. <pe...@ne...>]

On approximately 5/14/2004 7:22 AM, came the following characters from
the keyboard of Jez White:

> Hi,
>  
> Would any one have any objections if I change (fix depending on your 
> viewpoint:) ) the BeginPaint and EndPaint functions in GUI.xs?
>  
> I think these functions are left over from previous versions (along with 
> the other painting/drawing functions in GUI.xs). They are currently not 
> used by any other internal functions, nor are they documented anywhere. 
> The general usage would stay the same, but I plan to return the details 
> as an array (dc,x,y,x1,x2,flag) rather than messing with the object 
> itself. I think this would be cleaner, faster and more like other xs 
> functions.
>  
> In general usage these functions would be used in conjunction with a 
> Hooked WS_PAINT message, allowing the users program to handle the 
> painting of window directly. A good example, would be the bitmap 
> scrolling example ask for by Glenn Linderman, instead of painting the 
> bitmap into a image control, it could be painted direct into the windows 
> DC (I'll try and put together an example this weekend).
>  
> Comments?

I'm in favor for a several reasons, one of them selfish :)

1) I've never used them, so it won't affect me (and that's not the 
selfish reason)

2) From a brief look at the functions, it sounds like an improvement in 
clarity, and possibly speed.

3) There's a good chance the functions will get better documented as a 
result, so people that didn't take the time to figure them out before, 
may get a benefit from them with this change... (hint, hint)  :)

4) If I get a nice scrolling bitmap example code, I'll be really happy, 
and withdraw my request for adding back the old Win32::GUI::MDI object. 
  (Yep, this is the selfish one, but slightly altruistic as well.)

-- 
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.

Re: [perl-win32-gui-hackers] GUI samples

[Glenn L. <pe...@ne...>]

On approximately 5/14/2004 7:22 AM, came the following characters from
the keyboard of Jez White:

> Hi,
> 
> The current examples show new functionality that has been added over the
> last few months. We should add more examples, but I'm a bit dubious of
> adding examples from previous builds (they haven't been deleted - just not
> added:) ) 

Well, when I compare what I have in my old build area (downloaded 
snapshot) to what I now see via CVS, they appear to be not there.  It is 
not clear to me where they would then be added from, or what technique 
of "not there" was used other than deletion :)

> Many previous examples (even the one's that work) use none
> standard coding, which just cause confusion - for me anyway:)

I certainly have no objection to samples being modified to use standard 
coding, but I'm not sure what non-standard coding was used that was 
confusing.

If there isn't time to update the sample to use better coding, one could 
add some comments to it (no risk in adding comments) describing the 
non-standard-ness of the coding, but leaving the sample for whatever 
educational value it might have.  ???  I learned a good bit of GUI 
coding from those old samples, although I agree that I got a bit 
confused by some of them, also.

> Perhaps we should put a call out to the users list for ideas of what should
> be included (like the scrolling bitmap example you mentioned) and for
> volunteers to write them?

I certainly have no objections to this activity, I can't imagine anyone 
that would.  Certainly if someone contributes a concisee sample that 
demonstrates some activity (and all the currently-in-CVS samples do 
that, but so do some of the old ones :)), I would lobby for it to be 
included in the samples directory.  And if it is more than a file or 3, 
proably to be included in a samples subdirectory.  And once we go to 
samples subdirectories, the samples wouldn't even need to be that 
concise.... if they are showing a complex topic.

> 
> Cheers,
> 
> jez.
> 
> 
> ----- Original Message ----- 
> From: "Glenn Linderman" <pe...@ne...>
> To: "Win32 GUI Hackers" <per...@li...>
> Sent: Friday, May 14, 2004 6:14 AM
> Subject: [perl-win32-gui-hackers] GUI samples
> 
> 
> 
>>I notice that there are fewer samples than there used to be, in the
>>samples directory.  Yet a good number of the old samples will still work
>>on the latest GUI.  Is there some reason to delete still-working samples?
>>
>>-- 
>>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.
>>
>>
>>
>>-------------------------------------------------------
>>This SF.Net email is sponsored by: SourceForge.net Broadband
>>Sign-up now for SourceForge Broadband and get the fastest
>>6.0/768 connection for only $19.95/mo for the first 3 months!
>>http://ads.osdn.com/?ad_id=2562&alloc_id=6184&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.

Re: [perl-win32-gui-hackers] GetOpenFileName enhancement

[Glenn L. <pe...@ne...>]

On approximately 5/14/2004 12:56 AM, came the following characters from
the keyboard of Johan Lindstrom:
> At 06:53 2004-05-14, Glenn Linderman wrote:
> 
>> has a special return value for that case.  Win32::GUI's 
>> GetOpenFileName wrapper doesn't really handle the special return 
>> value, and even if it did, it is not the greatest idea to have the 
>> user select his files twice, once causing overflow, and the second 
>> time with a bigger buffer.  It would be much better to have a bigger 
>> buffer to start with.
> 
> 
> In the spirit of Perl, can't we optimize for the common case, and make 
> the uncommon case possible?
> 
> I'd like to not have to say I don't want a tiny, possibly overflowing 
> buffer. I'd like to have the enhanced, larger buffer by default (say a 
> couple of K at least so it never becomes an issue). And if I really need 
> to go beyond even that, maybe it's time for a new parameter.

"a couple of K" would be 8 times the size of the current buffer.  The 
current buffer is allocated on the C runtime stack at 256 bytes, and 
according to someone, allows "about 18 files" to be selected... so a 
couple of K would allow "about 72 files" to be selected.  That sounds 
like plenty for quite a few cases, but I can imagine very practical 
cases where I personally, would like to allow selection of several 
hundred files.

So I guess GetOpenFileName users have presently been living with the 256 
byte buffer.  I haven't heard major complaints... of course most of them 
didn't know  -multisel => 1  was even an available option, so maybe that 
is why.

OK, having said all that, is the point of your post that it would be 
nice to avoid the "malloc/free" calls in many cases?  (But remember, 
this is a user interface function that will soon be waiting for a human 
response measured in seconds, whereas the malloc/free are measured in 
microseconds.)

Or is the point of your post, that the default allocated buffer should 
not be 256 (as it was) but should grow to 2K with this code change?  Or 
should grow to 2K if  -multisel is non-zero (256 being plenty big enough 
if -multisel is zero)?

Or is the point of your post, that you don't think the value of 
-multisel should be permitted to be different than 0 or 1, that rather 
there should be a -resultsbuffersize parameter?

Or have I missed the point of your post?

I'll be glad to tweak my patch to deal with what people believe to be 
the common case.

-- 
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.

Re: [perl-win32-gui-hackers] GUI samples

[Jez W. <je...@je...>]

Hi,

The current examples show new functionality that has been added over the
last few months. We should add more examples, but I'm a bit dubious of
adding examples from previous builds (they haven't been deleted - just not
added:) ) Many previous examples (even the one's that work) use none
standard coding, which just cause confusion - for me anyway:)

Perhaps we should put a call out to the users list for ideas of what should
be included (like the scrolling bitmap example you mentioned) and for
volunteers to write them?

Cheers,

jez.


----- Original Message ----- 
From: "Glenn Linderman" <pe...@ne...>
To: "Win32 GUI Hackers" <per...@li...>
Sent: Friday, May 14, 2004 6:14 AM
Subject: [perl-win32-gui-hackers] GUI samples


> I notice that there are fewer samples than there used to be, in the
> samples directory.  Yet a good number of the old samples will still work
> on the latest GUI.  Is there some reason to delete still-working samples?
>
> -- 
> 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.
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: SourceForge.net Broadband
> Sign-up now for SourceForge Broadband and get the fastest
> 6.0/768 connection for only $19.95/mo for the first 3 months!
> http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click
> _______________________________________________
> Perl-Win32-GUI-Hackers mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-hackers

[perl-win32-gui-hackers] GUI.xs (BeginPaint and EndPaint)

[Jez W. <je...@je...>]

Hi,

Would any one have any objections if I change (fix depending on your =
viewpoint:) ) the BeginPaint and EndPaint functions in GUI.xs?=20

I think these functions are left over from previous versions (along with =
the other painting/drawing functions in GUI.xs). They are currently not =
used by any other internal functions, nor are they documented anywhere. =
The general usage would stay the same, but I plan to return the details =
as an array (dc,x,y,x1,x2,flag) rather than messing with the object =
itself. I think this would be cleaner, faster and more like other xs =
functions.

In general usage these functions would be used in conjunction with a =
Hooked WS_PAINT message, allowing the users program to handle the =
painting of window directly. A good example, would be the bitmap =
scrolling example ask for by Glenn Linderman, instead of painting the =
bitmap into a image control, it could be painted direct into the windows =
DC (I'll try and put together an example this weekend).

Comments?

Cheers,

jez.=20

Re: [perl-win32-gui-hackers] GetOpenFileName enhancement

[Johan L. <jo...@Da...>]

At 06:53 2004-05-14, Glenn Linderman wrote:
>has a special return value for that case.  Win32::GUI's GetOpenFileName 
>wrapper doesn't really handle the special return value, and even if it 
>did, it is not the greatest idea to have the user select his files twice, 
>once causing overflow, and the second time with a bigger buffer.  It would 
>be much better to have a bigger buffer to start with.

In the spirit of Perl, can't we optimize for the common case, and make the 
uncommon case possible?

I'd like to not have to say I don't want a tiny, possibly overflowing 
buffer. I'd like to have the enhanced, larger buffer by default (say a 
couple of K at least so it never becomes an issue). And if I really need to 
go beyond even that, maybe it's time for a new parameter.


/J

-------- ------ ---- --- -- --  --  -     -     -        -          -
Johan Lindström    Sourcerer @ Boss Casinos   johanl AT DarSerMan.com

Latest bookmark: "Perl for Windows Distribution main links."
http://pacific-design.com/?2,810,10
dmoz (1 of 5): /Computers/Programming/Languages/Perl/ 50

[perl-win32-gui-hackers] GUI samples

[Glenn L. <pe...@ne...>]

I notice that there are fewer samples than there used to be, in the 
samples directory.  Yet a good number of the old samples will still work 
on the latest GUI.  Is there some reason to delete still-working samples?

-- 
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.

[perl-win32-gui-hackers] GetOpenFileName enhancement

[Glenn L. <pe...@ne...>]

Per some discussion one ActiveState's perl-win32-users list that you 
might have seen, I was inspired to make GetOpenFileName work a bit better.

The problem at hand is that the results buffer is fixed size, so when 
selecting lots of files, it would overflow the buffer.  Surprisingly, 
Windows actually detects this instance of buffer overflow, and has a 
special return value for that case.  Win32::GUI's GetOpenFileName 
wrapper doesn't really handle the special return value, and even if it 
did, it is not the greatest idea to have the user select his files 
twice, once causing overflow, and the second time with a bigger buffer. 
  It would be much better to have a bigger buffer to start with.

Rather than make a new parameter, it seemed reasonable to me to enhance 
the -multisel => 0|1  to instead be -multisel => 0|bufsize .  So if 
-multisel is true, the appropriate flags are set as they are today, but 
also the buffersize is set to the minimum of 256 bytes (today's size) 
and the bufsize specified in -multisel.  This results in 100% 
compatibility (but a slight slowdown to do a safemalloc/safefree 
sequence) for people using the 0 or 1 values.  But for people that start 
passing in numbers larger than 256, it provides a larger buffer for 
multiple selection results.

Is there any objections to my applying this patch?

In addition to the gui.xs file that I changed, I guess I need to update 
CHANGELOG.  Anything else?

Can I change the version to 0.0.681 ?  Can we start the convention of 
bumping the version by 0.0.002 each time we change something (keeping it 
odd for development versions)?  And then by at least one more when we do 
a build, making it even?  Or maybe each build bumps the second 0.  So 
the next "official" release would be 0.1.0.  And the next development 
release after that would be 0.1.001, 0.1.002, etc.  Official releases 
would always be  N.M.0 ?

-- 
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.

Re: [perl-win32-gui-hackers] New Win32::GUI code in MAIN CVS.

[Glenn L. <pe...@ne...>]

On approximately 4/27/2004 3:32 PM, came the following characters from
the keyboard of Glenn Linderman:
> On approximately 4/27/2004 11:24 AM, came the following characters from
> the keyboard of Laurent ROCHER:
> 
>> Hi,
>>  
>>     I remove Win32::GUI::MDI because it's current implementation not 
>> realy permit to use it in an MDI application context.     I don't 
>> think anyone use this class ;o) And, i don't know this usage too.
> 
> 
> Yes, I did get the idea when I started using Win32::GUI::MDI that it 
> wasn't "true" MDI.
> 
>>     I can restore old Win32::GUI::MDI class. But, this class name 
>> probably confuse user for create MDI application.
> 
> 
> I wonder if restoring it under a different name would cause problems? It 
> would provide a migration path, albeit, an incompatible change.  But if 
> we can find a work-alike, then there is no need to add the class back.  
> Or it would be nice to document the work-alike if we can find it.

Well, I see that there is really very little code in Win32::GUI to 
support the old Win32::GUI::MDI class.  But it must be very magic code, 
because I haven't found a way to make it out of what is presently in the 
CVS.

>>     Win32::GUI::MDI use same window class than Win32::GUI::MDIClient.
>>     You can replace Win32::GUI::MDI with a Win32::GUI::MDIClient but 
>> AddLablel method don't exist for this class.
>>     It's only have a AddChild. And this class it's not same as a 
>> Win32::GUI::Window like Win32::GUI::MDI.
>>  
>>     For compatibility, i think you can replace Win32::GUI::MDI by 
>> something like that :
>>  
>> $mdi_window = Win32::GUI::Window->new (
>>     -remstyle => WS_OVERLAPPEDWINDOW,
>>     -addstyle => WS_VISIBLE | WS_CHILD | WS_CLIPCHILDREN | WS_VSCROLL 
>> | WS_HSCROLL,
>>     -classname => 'MDICLIENT',
>>     -name => 'mdi_window',
>>     -parent => $mw,
>>     -text => 'MDI',
>>     -top => 0, -left => 0,
>>     -width => $mwsw, -height => $mwsh - 40,
>>     );

So when I try doing this, it sort of works, as I mentioned earlier (see 
below), but not quite enough to be able to use it.

 From perusing the code, the biggest difference that I can find is that 
during the window creation, the above code leaves perlcs.iclass as 
WIN32__GUI__WINDOW, making it susceptible to executing code in other 
places that is cased on perlcs.iclass !  Whereas when it had type 
WIN32__GUI__MDICLIENT then some of those cases didn't happen.

At least, that is the best "educated guess" that I can come with.

So, because I can't find a replacement, and it seems quite useful to my 
code, and for backward compatibility, could this MDICLIENT window type 
be reinstated in the source code?


> This is much closer than anything I found.  But:
> 
> The scroll bars appear immediately (but maybe that's just because I need 
> to juggle some sizes that might be a little different than the old 
> class).  But after playing some more, I don't think that was it.
> 
> The scroll bars seem to be "stuck" at the top left... attempting to drag 
> them to see other parts of the window fails, they jump back to the top 
> left.
> 
> Removing WS_CLIPCHILDREN produced no discernible difference.
> 
> Removing the WS_VSCROLL and WS_HSCROLL eliminated the inital scroll 
> bars, but it actually eliminated them completely :(

-- 
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.

[perl-win32-gui-hackers] Win32::GUI Dev PPM

[Laurent R. <ro...@cl...>]

Hi All,

I have made PPM build from Sourceforge Win32::GUI CVS Main branch.

Change since last time :
  a.. MDI support.=20
  b.. New MonthCal control.=20
  c.. New treeView events : BeginLabelEdit, EndLabelEdit
  d.. Fix TextField -prompt option.
  e.. New methods and bug fix.
I build it from my local dev directory with last CVS source (8/05/2004).
I have made 5.6 and 5.8 PPM, and a source zip file.

See : http://perso.club-internet.fr/rocherl/Win32-GUI-Dev/index.html

Laurent

Re: [perl-win32-gui-hackers] New Win32::GUI code in MAIN CVS.

[Laurent R. <ro...@cl...>]

Hi all,

    I commit new stuff on CVS
        - Add MonthCal control
        - Fix TextField -prompt option

ChangeLog  :

+ [Laurent Rocher] : Add MonthCal Control
    - MonthCall.xs : New file
    - GUI.h :
        + Add new event argtype for SV*.
        + New MonthCall control callback function and constant.
    - GUI.pm :
        + Add MonthCall control.
    - GUI_Constants.cpp :
        + Add MonthCall class constant.
    - GUI_Events.cpp :
        + DoEvent : Add new type argument for SV*.
    - GUI_Helpers.cpp :
        + Add MonthCall control.
    - Makefile.pl, Makefile_m.pl :
        + Add MonthCall.xs
    - Samples\MonthCal.pl : New file
    - Docs\DoDoc.pl :
            + Add MonthCall.xs

+ [Steven M. Martin] : Fix TextField -prompt option.
    - GUI.pm :
        +  Win32::GUI::Textfield new : Fix TextField -prompt option when
prompt left was negative.

Laurent.

[perl-win32-gui-hackers] New Events for treeview control

[Jez W. <je...@je...>]

Hi,

I've just committed a change to the treeview control, which added 2 new =
events:

BeginLabelEdit
EndLabelEdit

These events allow the user to edit the label of a node in a treeview.

Cheers,

jez.

[perl-win32-gui-hackers] FASD project: Online survey launched

[Benno L. <ben...@id...>]

Dear Open Source developer

I am doing a research project on "Fun and Software Development" in which I
kindly invite you to participate.
You will find the online survey under http://fasd.ethz.ch/qsf/. The
questionnaire consists of 53 questions and you will need about 15 minutes to
complete it.

With the FASD project (Fun and Software Development) we want to define the
motivational significance of fun when software developers decide to engage
in Open Source projects. What is special about our research project is that
a similar survey is planned with software developers in commercial firms.
This procedure allows the immediate comparison between the involved
individuals and the conditions of production of these two development
models. Thus we hope to obtain substantial new insights to the phenomenon of
Open Source Development.


With many thanks for your participation,
Benno Luthiger


PS:
The results of the survey will be published under
http://www.isu.unizh.ch/fuehrung/blprojects/FASD/.
We have set up the mailing list fa...@we... for this study. Please
see http://fasd.ethz.ch/qsf/mailinglist_de.html for registration to this
mailing list.

_______________________________________________________________________

Benno Luthiger
Swiss Federal Institute of Technology Zurich
8092 Zurich

Mail: benno.luthiger(at)id.ethz.ch
_______________________________________________________________________

Re: [perl-win32-gui-hackers] New Win32::GUI code in MAIN CVS.

[Laurent R. <ro...@cl...>]

Hi all,

    I have commit fix for problem with MDiClient and Menu ID for child.
    I update MDI.pl sample too for show how add Window Child menuitem to
mainframe menu.

ChangeLog  : Fix IdFirstChild option for MDIClient.
    - GUI.pm :
        + Remove registered class for MDIClient.
    - GUI.xs :
        + RegisterClassEx : Remove MDIClient value for -widget option.
        + Create : SubClass MDIClient window.
        + Added SetActiveWindow.
    - GUI_MessageLoops.cpp :
        + MDIClientMsgLoop: Rewrite as simple subclass MsgLoop.
    - MDI.xs :
        + MDIClient_onPreCreate : Change classname.
        + MDIChild_onPreCreate  : Change default style.

Laurent.

Re: [perl-win32-gui-hackers] New Win32::GUI code in MAIN CVS.

[Glenn L. <pe...@ne...>]

Sounds fine.  Just we need to do something to distinguish releases from 
"CVS builds".

0.0.680 seems to have found its way to my hard disk, from one of your 
builds...

On approximately 4/29/2004 11:33 AM, came the following characters from
the keyboard of Laurent ROCHER:

> 
>>I tried to add VERSION checking code to my application so I could easily
>>keep it working under both old and new GUI versions... but the CVS
>>currently identifies itself as 0.0.671.  This is less than the older
>>versions 0.0.680....
> 
> 
> 0.0.680 ?? Don't know this version.
> 
> 
>>I think the CVS version should always be bigger than anything that was
>>ever released....
>>
>>I'd suggest   0.1.0  or   0.0.999   for the "latest CVS" at present,
>>although a future release could still be 0.0.681 or more.
>>
> 
> 
> I actually change version number only when build a new release.
> But, it's probably better to upgrade CVS Version number always to next
> release version.
> 
> I think MAIN CVS version can be upgrade to 0.1 (number for next release).
> Because, this version have lot of a new features and first step for a 1.0
> release ;o)
> 
> Laurent.
> 
> 
> 
> 

-- 
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.

Re: [perl-win32-gui-hackers] New Win32::GUI code in MAIN CVS.

[Laurent R. <ro...@cl...>]

> I tried to add VERSION checking code to my application so I could easily
> keep it working under both old and new GUI versions... but the CVS
> currently identifies itself as 0.0.671.  This is less than the older
> versions 0.0.680....

0.0.680 ?? Don't know this version.

> I think the CVS version should always be bigger than anything that was
> ever released....
>
> I'd suggest   0.1.0  or   0.0.999   for the "latest CVS" at present,
> although a future release could still be 0.0.681 or more.
>

I actually change version number only when build a new release.
But, it's probably better to upgrade CVS Version number always to next
release version.

I think MAIN CVS version can be upgrade to 0.1 (number for next release).
Because, this version have lot of a new features and first step for a 1.0
release ;o)

Laurent.

Re: [perl-win32-gui-hackers] New Win32::GUI code in MAIN CVS.

[Glenn L. <pe...@ne...>]

I tried to add VERSION checking code to my application so I could easily 
keep it working under both old and new GUI versions... but the CVS 
currently identifies itself as 0.0.671.  This is less than the older 
versions 0.0.680....

I think the CVS version should always be bigger than anything that was 
ever released....

I'd suggest   0.1.0  or   0.0.999   for the "latest CVS" at present, 
although a future release could still be 0.0.681 or more.

Or we could use a technique similar to the perl releases.... odd numbers 
are "latest CVS" and releases are always even (henceforth).  Under this 
theory, we would put 0.0.681 in the CVS, and the next release would be 
0.0.682 ... as soon as the release is complete, the CVS would go to 
0.0.683, etc.

On approximately 4/27/2004 11:24 AM, came the following characters from
the keyboard of Laurent ROCHER:

> Hi,
>  
>     I remove Win32::GUI::MDI because it's current implementation not 
> realy permit to use it in an MDI application context. 
>     I don't think anyone use this class ;o) And, i don't know this 
> usage too.
>  
>     I can restore old Win32::GUI::MDI class. But, this class name 
> probably confuse user for create MDI application.
>  
>     Win32::GUI::MDI use same window class than Win32::GUI::MDIClient.
>     You can replace Win32::GUI::MDI with a Win32::GUI::MDIClient but 
> AddLablel method don't exist for this class.
>     It's only have a AddChild. And this class it's not same as a 
> Win32::GUI::Window like Win32::GUI::MDI.
>  
>     For compatibility, i think you can replace Win32::GUI::MDI by 
> something like that :
>  
> $mdi_window = Win32::GUI::Window->new (
>     -remstyle => WS_OVERLAPPEDWINDOW,
>     -addstyle => WS_VISIBLE | WS_CHILD | WS_CLIPCHILDREN | WS_VSCROLL | 
> WS_HSCROLL,
>     -classname => 'MDICLIENT',
>     -name => 'mdi_window',
>     -parent => $mw,
>     -text => 'MDI',
>     -top => 0, -left => 0,
>     -width => $mwsw, -height => $mwsh - 40,
>     );
>  
> 
> Laurent.
>  
>  > On approximately 4/26/2004 9:40 AM, came the following characters from
>  > the keyboard of Laurent ROCHER:
>  > > Hi All,
>  > >
>  > >     I commit new changes.
>  > >         - Window properties now re-work.
>  >
>  > Good :) :)
>  >
>  > >         - Handle correctly Window life and Perl variable life
>  > >          (i hope it work because i loose my hair on it ;o)
>  > >         - Add MDI window support (3 new class MDIFrame, MDIClient and
>  > > MDIChild).
>  > >
>  > >     For MDI, i have add a sample in Samples directory.
>  >
>  > This sounds good, and looks good.  Unfortunately, not compatible with
>  > old Win32::GUI::MDI.  I wonder if there is any way to have the added
>  > functionality you are producing, and still be compatible with the old
>  > code.  My old code was:
>  >
>  > # MDI window
>  >
>  > $mdi_window = Win32::GUI::MDI->new (
>  >    -name => 'mdi_window',
>  >    -parent => $mw,
>  >    -text => 'MDI',
>  >    -top => 0, -left => 0,
>  >    -width => $mwsw, -height => $mwsh - 40,
>  >    -visible => 1,
>  >    );
>  > if ( ! $mdi_window )
>  > { GUtil::demise( "MDI creation error: $^E\n" );
>  > }
>  >
>  > # label_bitmap inside MDI window
>  >
>  > $label_bitmap = $mdi_window->AddLabel(
>  >    -name => 'label_bitmap',
>  >    -bitmap => 1,
>  >    -left => 0, -top => 0, -width => $mwsw - 40, -height => $mwsh - 40,
>  >    -tip => 'list display area',
>  >    );
>  >
>  > The interesting feature is that the label is automatically resized when
>  > you insert a different bitmap via later calles like
>  >
>  >     $label_bitmap->SetImage ( $bitmap );
>  >
>  > The size is taken from the $bitmap image content.  But by being within
>  > an MDI window, scroll bars were automatically added to that window so
>  > that the whole bitmap could be viewed when it is bigger than the
>  > containing MDI window, and the scroll bars would go away when the bitmap
>  > was smaller than the containing MDI window.  And no other code was
>  > needed to achieve it.
>  >
>  > Probably I was using Win32::GUI::MDI for an inappropriate usage.  This
>  > is all code that I wrote, and I am willing to rework it, but some ideas
>  > on how I should best do such a thing would be appreciated.
>  >
>  > The basic goal is a scrollable, fixed size container for a dynamically
>  > sized bitmap.  Showing it via a label is not particularly necessary, but
>  >   that seems to be convenient.
>  >
>  > One thing I didn't like about my above implementation is that I hadn't
>  > figured out how to control the scroll bars via API calls at all, to
>  > choose which part of the image was showing.  The user could scroll at
>  > will, however.
>  >
>  > I'm not sure whether the old Win32::GUI::MDI corresponds more directly
>  > to the new MDIFrame or the MDIClient, or whether one must always have an
>  > MDIClient and MDIChild inside an MDIFrame, or just can put a label
>  > directly into an MDIFrame....
>  >
>  > I tried substituting MDIFrame for MDI in my code above, and got a
>  > surprising error:
>  >
>  > Use of uninitialized value in substitution (s///) at GUI.pm line 1046.
>  >
>  > After uncommenting the debugging print statement in AUTOLOAD, I discover
>  > that it is failing to autoload a method named "-name" on
>  > Win32::GUI::MDIFrame, but not sure why.
>  >
>  > Well, I'll play a bit more, maybe you'll have some ideas of where I
>  > should look.
>  >

-- 
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.

Re: [perl-win32-gui-hackers] New Win32::GUI code in MAIN CVS.

[Glenn L. <pe...@ne...>]

On approximately 4/27/2004 11:24 AM, came the following characters from
the keyboard of Laurent ROCHER:

> Hi,
>  
>     I remove Win32::GUI::MDI because it's current implementation not 
> realy permit to use it in an MDI application context. 
>     I don't think anyone use this class ;o) And, i don't know this 
> usage too.

Yes, I did get the idea when I started using Win32::GUI::MDI that it 
wasn't "true" MDI.

>     I can restore old Win32::GUI::MDI class. But, this class name 
> probably confuse user for create MDI application.

I wonder if restoring it under a different name would cause problems? 
It would provide a migration path, albeit, an incompatible change.  But 
if we can find a work-alike, then there is no need to add the class 
back.  Or it would be nice to document the work-alike if we can find it.

>     Win32::GUI::MDI use same window class than Win32::GUI::MDIClient.
>     You can replace Win32::GUI::MDI with a Win32::GUI::MDIClient but 
> AddLablel method don't exist for this class.
>     It's only have a AddChild. And this class it's not same as a 
> Win32::GUI::Window like Win32::GUI::MDI.
>  
>     For compatibility, i think you can replace Win32::GUI::MDI by 
> something like that :
>  
> $mdi_window = Win32::GUI::Window->new (
>     -remstyle => WS_OVERLAPPEDWINDOW,
>     -addstyle => WS_VISIBLE | WS_CHILD | WS_CLIPCHILDREN | WS_VSCROLL | 
> WS_HSCROLL,
>     -classname => 'MDICLIENT',
>     -name => 'mdi_window',
>     -parent => $mw,
>     -text => 'MDI',
>     -top => 0, -left => 0,
>     -width => $mwsw, -height => $mwsh - 40,
>     );

This is much closer than anything I found.  But:

The scroll bars appear immediately (but maybe that's just because I need 
to juggle some sizes that might be a little different than the old 
class).  But after playing some more, I don't think that was it.

The scroll bars seem to be "stuck" at the top left... attempting to drag 
them to see other parts of the window fails, they jump back to the top left.

Removing WS_CLIPCHILDREN produced no discernible difference.

Removing the WS_VSCROLL and WS_HSCROLL eliminated the inital scroll 
bars, but it actually eliminated them completely :(

-- 
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.

Re: [perl-win32-gui-hackers] New Win32::GUI code in MAIN CVS.

[Laurent R. <ro...@cl...>]

Hi,

    I remove Win32::GUI::MDI because it's current implementation not =
realy permit to use it in an MDI application context.=20
    I don't think anyone use this class ;o) And, i don't know this usage =
too.

    I can restore old Win32::GUI::MDI class. But, this class name =
probably confuse user for create MDI application.

    Win32::GUI::MDI use same window class than Win32::GUI::MDIClient.
    You can replace Win32::GUI::MDI with a Win32::GUI::MDIClient but =
AddLablel method don't exist for this class.=20
    It's only have a AddChild. And this class it's not same as a =
Win32::GUI::Window like Win32::GUI::MDI.

    For compatibility, i think you can replace Win32::GUI::MDI by =
something like that :

$mdi_window =3D Win32::GUI::Window->new (
    -remstyle =3D> WS_OVERLAPPEDWINDOW,
    -addstyle =3D> WS_VISIBLE | WS_CHILD | WS_CLIPCHILDREN | WS_VSCROLL =
| WS_HSCROLL,
    -classname =3D> 'MDICLIENT',
    -name =3D> 'mdi_window',
    -parent =3D> $mw,
    -text =3D> 'MDI',
    -top =3D> 0, -left =3D> 0,
    -width =3D> $mwsw, -height =3D> $mwsh - 40,
    );


Laurent.

> On approximately 4/26/2004 9:40 AM, came the following characters from
> the keyboard of Laurent ROCHER:
> > Hi All,
> >=20
> >     I commit new changes.
> >         - Window properties now re-work.
>=20
> Good :) :)
>=20
> >         - Handle correctly Window life and Perl variable life
> >          (i hope it work because i loose my hair on it ;o)
> >         - Add MDI window support (3 new class MDIFrame, MDIClient =
and
> > MDIChild).
> >=20
> >     For MDI, i have add a sample in Samples directory.
>=20
> This sounds good, and looks good.  Unfortunately, not compatible with=20
> old Win32::GUI::MDI.  I wonder if there is any way to have the added=20
> functionality you are producing, and still be compatible with the old=20
> code.  My old code was:
>=20
> # MDI window
>=20
> $mdi_window =3D Win32::GUI::MDI->new (
>    -name =3D> 'mdi_window',
>    -parent =3D> $mw,
>    -text =3D> 'MDI',
>    -top =3D> 0, -left =3D> 0,
>    -width =3D> $mwsw, -height =3D> $mwsh - 40,
>    -visible =3D> 1,
>    );
> if ( ! $mdi_window )
> { GUtil::demise( "MDI creation error: $^E\n" );
> }
>=20
> # label_bitmap inside MDI window
>=20
> $label_bitmap =3D $mdi_window->AddLabel(
>    -name =3D> 'label_bitmap',
>    -bitmap =3D> 1,
>    -left =3D> 0, -top =3D> 0, -width =3D> $mwsw - 40, -height =3D> =
$mwsh - 40,
>    -tip =3D> 'list display area',
>    );
>=20
> The interesting feature is that the label is automatically resized =
when=20
> you insert a different bitmap via later calles like
>=20
>     $label_bitmap->SetImage ( $bitmap );
>=20
> The size is taken from the $bitmap image content.  But by being within =

> an MDI window, scroll bars were automatically added to that window so=20
> that the whole bitmap could be viewed when it is bigger than the=20
> containing MDI window, and the scroll bars would go away when the =
bitmap=20
> was smaller than the containing MDI window.  And no other code was=20
> needed to achieve it.
>=20
> Probably I was using Win32::GUI::MDI for an inappropriate usage.  This =

> is all code that I wrote, and I am willing to rework it, but some =
ideas=20
> on how I should best do such a thing would be appreciated.
>=20
> The basic goal is a scrollable, fixed size container for a dynamically =

> sized bitmap.  Showing it via a label is not particularly necessary, =
but=20
>   that seems to be convenient.
>=20
> One thing I didn't like about my above implementation is that I hadn't =

> figured out how to control the scroll bars via API calls at all, to=20
> choose which part of the image was showing.  The user could scroll at=20
> will, however.
>=20
> I'm not sure whether the old Win32::GUI::MDI corresponds more directly =

> to the new MDIFrame or the MDIClient, or whether one must always have =
an=20
> MDIClient and MDIChild inside an MDIFrame, or just can put a label=20
> directly into an MDIFrame....
>=20
> I tried substituting MDIFrame for MDI in my code above, and got a=20
> surprising error:
>=20
> Use of uninitialized value in substitution (s///) at GUI.pm line 1046.
>=20
> After uncommenting the debugging print statement in AUTOLOAD, I =
discover=20
> that it is failing to autoload a method named "-name" on=20
> Win32::GUI::MDIFrame, but not sure why.
>=20
> Well, I'll play a bit more, maybe you'll have some ideas of where I=20
> should look.
>=20

Re: [perl-win32-gui-hackers] New Win32::GUI code in MAIN CVS.

[Glenn L. <pe...@ne...>]

On approximately 4/26/2004 9:40 AM, came the following characters from
the keyboard of Laurent ROCHER:
> Hi All,
> 
>     I commit new changes.
>         - Window properties now re-work.

Good :) :)

>         - Handle correctly Window life and Perl variable life
>          (i hope it work because i loose my hair on it ;o)
>         - Add MDI window support (3 new class MDIFrame, MDIClient and
> MDIChild).
> 
>     For MDI, i have add a sample in Samples directory.

This sounds good, and looks good.  Unfortunately, not compatible with 
old Win32::GUI::MDI.  I wonder if there is any way to have the added 
functionality you are producing, and still be compatible with the old 
code.  My old code was:

# MDI window

$mdi_window = Win32::GUI::MDI->new (
   -name => 'mdi_window',
   -parent => $mw,
   -text => 'MDI',
   -top => 0, -left => 0,
   -width => $mwsw, -height => $mwsh - 40,
   -visible => 1,
   );
if ( ! $mdi_window )
{ GUtil::demise( "MDI creation error: $^E\n" );
}

# label_bitmap inside MDI window

$label_bitmap = $mdi_window->AddLabel(
   -name => 'label_bitmap',
   -bitmap => 1,
   -left => 0, -top => 0, -width => $mwsw - 40, -height => $mwsh - 40,
   -tip => 'list display area',
   );

The interesting feature is that the label is automatically resized when 
you insert a different bitmap via later calles like

    $label_bitmap->SetImage ( $bitmap );

The size is taken from the $bitmap image content.  But by being within 
an MDI window, scroll bars were automatically added to that window so 
that the whole bitmap could be viewed when it is bigger than the 
containing MDI window, and the scroll bars would go away when the bitmap 
was smaller than the containing MDI window.  And no other code was 
needed to achieve it.

Probably I was using Win32::GUI::MDI for an inappropriate usage.  This 
is all code that I wrote, and I am willing to rework it, but some ideas 
on how I should best do such a thing would be appreciated.

The basic goal is a scrollable, fixed size container for a dynamically 
sized bitmap.  Showing it via a label is not particularly necessary, but 
  that seems to be convenient.

One thing I didn't like about my above implementation is that I hadn't 
figured out how to control the scroll bars via API calls at all, to 
choose which part of the image was showing.  The user could scroll at 
will, however.

I'm not sure whether the old Win32::GUI::MDI corresponds more directly 
to the new MDIFrame or the MDIClient, or whether one must always have an 
MDIClient and MDIChild inside an MDIFrame, or just can put a label 
directly into an MDIFrame....

I tried substituting MDIFrame for MDI in my code above, and got a 
surprising error:

Use of uninitialized value in substitution (s///) at GUI.pm line 1046.

After uncommenting the debugging print statement in AUTOLOAD, I discover 
that it is failing to autoload a method named "-name" on 
Win32::GUI::MDIFrame, but not sure why.

Well, I'll play a bit more, maybe you'll have some ideas of where I 
should look.


>     It's work but one stuff don't work as expected :-(
>     I have a trouble with menu identifer when try to add a window menu to
> MDIClient.

This limit won't affect me, as I'm not using different menus for MDI 
windows.

>     It's use 0 based identifier for window child menu item but not assigned
> default MDIChild identifier.
>     So, i have a conflict with standard menu item. Need to investigate ...
> 
> Laurent.
> 
> Changelog : Add MDI Window Support and Fix Tied property & Window
> Destruction.
>     - GUI.h :
>         + Added new MDI Constants and Callback functions.
>         + Added a dwData field in PERLWIN32GUI_USERDATA.
>     - GUI.pm :
>         + _new : Fix tied hash property.
>         + Comment AUTOLOAD in Win32::GUI::Window : Is usefull ?
>         + New Win32::GUI::MDIFrame, Win32::GUI::MDIClient,
> Win32::GUI::MDIChild class.
>         + Win32::GUI::WindowProps : Fix Destroy managing.
>         + Register new class for MDI.
>     - GUI.xs :
>         + In GetKeyboardState : Use a stack array for key.
>         + In RegisterClassEx :
>             + Added MDIFrame, MDIClient, MDIChild widget option.
>             + Avoid reccursive Window Msg Loop call.
>         + In Create :
>             + Use a weaken reference for perlpud->SvSelf for clean reference
> count and memory free.
>             + Added MDI support.
>             + Added dwData field support.
>         + In Change : Added MDI support.
>         + In Dialog, DoEvents, DoModal : Added MDI event loop support.
>         + LockWindowUpdate : Rewrite shorter.
>     - GUI_Constants.cpp :
>         + Added MDI class constants.
>     - GUI_Helpers.cpp :
>         + Addes MDI class callback.
>         + Perlud_Free : Correct destruction problem.
>     - GUI_MessageLoops.cpp :
>         + In CommonMsgLoop : Don't manage WM_GETMINMAXINFO for MDI Child.
>         + In WindowMsgLoop :
>             + Added support for WndProc call.
>             + For WM_DESTROY, call default MsgLoop before free perlud.
>             + Handle WM_MDIACTIVATE & WM_SETFOCUS for MDI Window.
>         + Added DefMDIFrameLoop and MDIFrameMsgLoop for MDIFrame Window.
>         + Added MDIClientMsgLoop for MDICLient window.
>         + Added DefMDIChildLoop and MDIChildMsgLoop for MDIChild Window.
>     - GUI_Options.cpp :
>         + In ParseWindowOptions : Added a missing else for class specific
> option parsing.
>     - Makefile.pl &  Makefile_m.pl : Add new MDI.xs file.
>     - MDI.xs : Manage MDI window.
>     - Window.xs : Remove MDI class and add MDI event documentation.
>     - Samples\MDI.pl : New Sample form MDI use.
>     - Docs\DoDoc.pl : Add new MDI.xs file.
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
> For a limited time only, get FREE Ground shipping on all orders of $35
> or more. Hurry up and shop folks, this offer expires April 30th!
> http://www.thinkgeek.com/freeshipping/?cpg=12297
> _______________________________________________
> 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.

Re: [perl-win32-gui-hackers] New Win32::GUI code in MAIN CVS.

[Laurent R. <ro...@cl...>]

Hi

    I restore AUTOLOAD sub in Win32::GUI::Window.
    I understand now what this sub do.

    It's permit to directly call a child window procedure like this :
        $Win->Child->Show;
    it's do same job as :
        $Win->{Child}->Show;

ChangeLog  : Restore AUTOLOAD
    - GUI.pm :
        + Uncomment AUTOLOAD
        + Add AUTOLOAD to MDIFrame, MDIClient.

Laurent

Re: [perl-win32-gui-hackers] New Win32::GUI code in MAIN CVS.

[Laurent R. <ro...@cl...>]

Hi All,

    I commit new changes.
        - Window properties now re-work.
        - Handle correctly Window life and Perl variable life
         (i hope it work because i loose my hair on it ;o)
        - Add MDI window support (3 new class MDIFrame, MDIClient and
MDIChild).

    For MDI, i have add a sample in Samples directory.
    It's work but one stuff don't work as expected :-(
    I have a trouble with menu identifer when try to add a window menu to
MDIClient.
    It's use 0 based identifier for window child menu item but not assigned
default MDIChild identifier.
    So, i have a conflict with standard menu item. Need to investigate ...

Laurent.

Changelog : Add MDI Window Support and Fix Tied property & Window
Destruction.
    - GUI.h :
        + Added new MDI Constants and Callback functions.
        + Added a dwData field in PERLWIN32GUI_USERDATA.
    - GUI.pm :
        + _new : Fix tied hash property.
        + Comment AUTOLOAD in Win32::GUI::Window : Is usefull ?
        + New Win32::GUI::MDIFrame, Win32::GUI::MDIClient,
Win32::GUI::MDIChild class.
        + Win32::GUI::WindowProps : Fix Destroy managing.
        + Register new class for MDI.
    - GUI.xs :
        + In GetKeyboardState : Use a stack array for key.
        + In RegisterClassEx :
            + Added MDIFrame, MDIClient, MDIChild widget option.
            + Avoid reccursive Window Msg Loop call.
        + In Create :
            + Use a weaken reference for perlpud->SvSelf for clean reference
count and memory free.
            + Added MDI support.
            + Added dwData field support.
        + In Change : Added MDI support.
        + In Dialog, DoEvents, DoModal : Added MDI event loop support.
        + LockWindowUpdate : Rewrite shorter.
    - GUI_Constants.cpp :
        + Added MDI class constants.
    - GUI_Helpers.cpp :
        + Addes MDI class callback.
        + Perlud_Free : Correct destruction problem.
    - GUI_MessageLoops.cpp :
        + In CommonMsgLoop : Don't manage WM_GETMINMAXINFO for MDI Child.
        + In WindowMsgLoop :
            + Added support for WndProc call.
            + For WM_DESTROY, call default MsgLoop before free perlud.
            + Handle WM_MDIACTIVATE & WM_SETFOCUS for MDI Window.
        + Added DefMDIFrameLoop and MDIFrameMsgLoop for MDIFrame Window.
        + Added MDIClientMsgLoop for MDICLient window.
        + Added DefMDIChildLoop and MDIChildMsgLoop for MDIChild Window.
    - GUI_Options.cpp :
        + In ParseWindowOptions : Added a missing else for class specific
option parsing.
    - Makefile.pl &  Makefile_m.pl : Add new MDI.xs file.
    - MDI.xs : Manage MDI window.
    - Window.xs : Remove MDI class and add MDI event documentation.
    - Samples\MDI.pl : New Sample form MDI use.
    - Docs\DoDoc.pl : Add new MDI.xs file.

[perl-win32-gui-hackers] Commit

[Jez W. <je...@je...>]

Hi,

I've just committed a minor bug fix for DoModal (the fix stops the =
flicker which sometimes occurred when the modal window returns).

Cheers,

jez.