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

[perl-win32-gui-hackers] CustomDraw finished

[Reini U. <ru...@x-...>]

Attached is the preliminary patch for full CustomDraw support
plus the new DragDrop object.
Missing are the CustomDraw and DragDrop samples which
I have to take out from my app and do some more testing.
t files would also be fine, but I'm not sure yet how to implement a
DropFiles testcase.

Win32-GUI ChangeLog
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
+ [Reini Urban] : 14 Mar 2006
    - GUI.pm : Change version to 1.04, add -dropfiles to Window
    - GUI.h  : add CustomDraw and DropFiles support,
=09start with thread-safe static data definitions.
    - Button.xs, Header.xs, ListView.xs, Rebar.xs, Toolbar.xs,
Tooltip.xs, TreeView.xs:
        add CustomDraw EVENT with Win32::GUI::Button::CustomDraw
object as param.
=09abuse the PAINT constant for NEM, which should not conflict.
    - Customdraw.pm : CustomDraw package definition and helpers
    - GUI.xs : DoEvents(hwnd=3DNULL,wMsgFilterMin=3D0,wMsgFilterMax=3D0,wRe=
moveMsg=3DPM_REMOVE),
=09Try additional OEM ressource in LoadImage,
=09Add Win32::GUI::DragDrop object which is passed to the DropFiles
event as argument.
    - GUI_Helpers.cpp: add SV* CreateNMCustomDraw()
    - GUI_MessageLoops.cpp : Change DropFiles EVENT to pass the
Win32::GUI::DragDrop object
    - ImageList.xs: Add to documention.
    - TYPEMAP: Add HDROP as first-class citizen (Win32::GUI::DragDrop)
    - Window.xs: support -dropfiles property, store it onPostCreate in perl=
cs
    - SrcParser.pm, Documentation.txt: fix some typos
    - samples/CustomDraw.pl, samples/DragDrop.pl: not yet finished

--
Reini Urban
http://phpwiki.org/
http://spacemovie.mur.at/   http://helsinki.at/

Re: [perl-win32-gui-hackers] Re: DragDrop as xs

[Jeremy W. <jez...@ho...>]

>It's very easy to make terrible mistakes in the XS part.
>Devel::LeakTrace helps. I don't like leaks in MessageLoop events.

I'll have a look at that module.

>No, more like:
>-onDragDrop => sub {
>   my ($win, $drag) = @_; # dragged to win
>   print "Mouse: ", join(", ", $drag->MousePosition), "\n";
>   print "Files: ", join(", ", $drag->Files), "\n";
>}

Looks good. Is there any chance that you could provide a simple working 
example that could also be added to CVS?

Cheers,

jez.

Re: [perl-win32-gui-hackers] Re: DragDrop as xs

[Reini U. <ru...@x-...>]

2006/3/9, Jeremy White <jez...@ho...>:
> >And I wonder if we should not support a higher level interface, by filli=
ng
> >the needed properties of this object on creation, with the files
> >and the mousepoint automatically.
> >Then none of the 4 DragDrop functions would be needed and the
> >event would be much simplier to use.
>
> Yeah, I think that would be a better interface - how "easy" would that be=
 to
> implement?

I just did that for the CustomDraw object, which passes a struct to
the event, which really should be accessed as
tied object, a la WindowProps.
When I got that finished, I will port DragDrop to pass such an object
to the event also.
The main XS machinery is already there. CreateObjectbyHandle() ...

It's very easy to make terrible mistakes in the XS part.
Devel::LeakTrace helps. I don't like leaks in MessageLoop events.

> In the end I guess you would end up with an event handler like:
>
> sub {
>   my $xpos=3Dshift; #the X cor of the mouse when dropped
>   my $ypos=3Dshift; #the Y cor of the mouse when dropped
>   foreach $myfile (@_) {
>      #for each file dropped on the window
>      ...
>   }
> }

No, more like:
-onDragDrop =3D> sub {
  my ($win, $drag) =3D @_; # dragged to win
  print "Mouse: ", join(", ", $drag->MousePosition), "\n";
  print "Files: ", join(", ", $drag->Files), "\n";
}

--
Reini Urban
http://phpwiki.org/
http://spacemovie.mur.at/   http://helsinki.at/

RE: [perl-win32-gui-hackers] Re: DragDrop as xs

[Jeremy W. <jez...@ho...>]

>And I wonder if we should not support a higher level interface, by filling
>the needed properties of this object on creation, with the files
>and the mousepoint automatically.
>Then none of the 4 DragDrop functions would be needed and the
>event would be much simplier to use.

Yeah, I think that would be a better interface - how "easy" would that be to 
implement?

In the end I guess you would end up with an event handler like:

sub {
  my $xpos=shift; #the X cor of the mouse when dropped
  my $ypos=shift; #the Y cor of the mouse when dropped
  foreach $myfile (@_) {
     #for each file dropped on the window
     ...
  }
}

Cheers,

jez.

[perl-win32-gui-hackers] Re: DragDrop as xs

[Reini U. <ru...@x-...>]

oops, forgot to attach the patch...


2006/3/9, Reini Urban <ru...@x-...>:
> I simplified and fixed some code in the XS part of DragDrop.
> The second argument to the DropFiles event is now a proper
> Win32::GUI::DragDrop object with the HDROP handle as -handle.
>
> Unicode filenames not yet supported.
>
> And I wonder if we should not support a higher level interface, by fillin=
g
> the needed properties of this object on creation, with the files
> and the mousepoint automatically.
> Then none of the 4 DragDrop functions would be needed and the
> event would be much simplier to use.
>
> Now:
> sub Main_DropFiles {
>   my $win =3D shift; # dropped on which window
>   my @files;
>   if (ref $_[0] eq 'Win32::GUI::DragDrop') { # GUI 1.04
>     #my $pos =3D $_[0]->DragQueryPoint();
>     #my $l =3D $_[0]->DragQueryFile(0xFFFFFFFF);
>     #my $f0 =3D $_[0]->DragQueryFile(0);
>     @files =3D $_[0]->DragQueryFiles();
>     # and from here on the HDROP ressource behind the $_[0] object is des=
troyed.
>   } else {
>     @files =3D Win32::GUI::DragDrop::GetDroppedFiles(shift); # Loft
>   }
>   return 0 unless @files;
>   .. do something with the files
> }
>
> Then:
> sub Main_DropFiles {
>   my $win =3D shift; # dropped on which window
>   my @files;
>   if (ref $_[0] eq 'Win32::GUI::DragDrop') { # GUI 1.04
>     @files =3D $_[0]->DragFiles;
>     $pos =3D $_[0]->DragPos; # pos stored in the perl object
>   } else {
>     @files =3D Win32::GUI::DragDrop::GetDroppedFiles(shift); # Loft
>   }
>   return 0 unless @files;
>   .. do something with the files
> }
>
> Now I will finish all the needed support functions for CustomDraw and
> make a simplier example without Win32::API.
>
> 2006/3/8, Reini Urban <ru...@x-...>:
> > Hi
> > I just finished adding DragDrop to Win32::GUI.
> >
> > I didn't like the Loft methods and it's Win32::API dependency,
> > so it's a good GUI.xs and Window.xs integration with the "DropFiles"
> > NEM and OEM events supported.
> > Attached is the generated pod and patch.
> >
> > A Window can use the -dropfiles =3D> 0|1 option to accept dropping file=
s,
> > or the DragAcceptFiles() method.
> > The event can be registered via <name>_DropFiles or via -onDropFiles.
> > Sample:
> > sub Main_DropFiles {
> >   # check if called as method or function
> >   if ($_[0] =3D~ /Win32::GUI::(Window|DialogBox)/) {
> >     shift;
> >   }
> >   # now the DragDrop handle should be on the stack. (not an object yet =
though)
> >   my $files =3D Win32::GUI::DragDrop::DragQueryFiles(shift);
> >   return 0 unless @$files;
> >   ...
> > }
> >
> > Some notes:
> > The DragDrop handle passed to the event is no object yet.
> > So only the function call is supported yet, not as method.
> >
> > sub win_DropFiles { $files =3D $_[0]->DragQueryFiles(); } # invalid!
> > I didn't care to stash the handle in XS yet. It's just a long.
> --
> Reini Urban
> http://phpwiki.org/
> http://spacemovie.mur.at/   http://helsinki.at/
>


--
Reini Urban
http://phpwiki.org/
http://spacemovie.mur.at/   http://helsinki.at/

[perl-win32-gui-hackers] Re: DragDrop as xs

[Reini U. <ru...@x-...>]

I simplified and fixed some code in the XS part of DragDrop.
The second argument to the DropFiles event is now a proper
Win32::GUI::DragDrop object with the HDROP handle as -handle.

Unicode filenames not yet supported.

And I wonder if we should not support a higher level interface, by filling
the needed properties of this object on creation, with the files
and the mousepoint automatically.
Then none of the 4 DragDrop functions would be needed and the
event would be much simplier to use.

Now:
sub Main_DropFiles {
  my $win =3D shift; # dropped on which window
  my @files;
  if (ref $_[0] eq 'Win32::GUI::DragDrop') { # GUI 1.04
    #my $pos =3D $_[0]->DragQueryPoint();
    #my $l =3D $_[0]->DragQueryFile(0xFFFFFFFF);
    #my $f0 =3D $_[0]->DragQueryFile(0);
    @files =3D $_[0]->DragQueryFiles();
    # and from here on the HDROP ressource behind the $_[0] object is destr=
oyed.
  } else {
    @files =3D Win32::GUI::DragDrop::GetDroppedFiles(shift); # Loft
  }
  return 0 unless @files;
  .. do something with the files
}

Then:
sub Main_DropFiles {
  my $win =3D shift; # dropped on which window
  my @files;
  if (ref $_[0] eq 'Win32::GUI::DragDrop') { # GUI 1.04
    @files =3D $_[0]->DragFiles;
    $pos =3D $_[0]->DragPos; # pos stored in the perl object
  } else {
    @files =3D Win32::GUI::DragDrop::GetDroppedFiles(shift); # Loft
  }
  return 0 unless @files;
  .. do something with the files
}

Now I will finish all the needed support functions for CustomDraw and
make a simplier example without Win32::API.

2006/3/8, Reini Urban <ru...@x-...>:
> Hi
> I just finished adding DragDrop to Win32::GUI.
>
> I didn't like the Loft methods and it's Win32::API dependency,
> so it's a good GUI.xs and Window.xs integration with the "DropFiles"
> NEM and OEM events supported.
> Attached is the generated pod and patch.
>
> A Window can use the -dropfiles =3D> 0|1 option to accept dropping files,
> or the DragAcceptFiles() method.
> The event can be registered via <name>_DropFiles or via -onDropFiles.
> Sample:
> sub Main_DropFiles {
>   # check if called as method or function
>   if ($_[0] =3D~ /Win32::GUI::(Window|DialogBox)/) {
>     shift;
>   }
>   # now the DragDrop handle should be on the stack. (not an object yet th=
ough)
>   my $files =3D Win32::GUI::DragDrop::DragQueryFiles(shift);
>   return 0 unless @$files;
>   ...
> }
>
> Some notes:
> The DragDrop handle passed to the event is no object yet.
> So only the function call is supported yet, not as method.
>
> sub win_DropFiles { $files =3D $_[0]->DragQueryFiles(); } # invalid!
> I didn't care to stash the handle in XS yet. It's just a long.
--
Reini Urban
http://phpwiki.org/
http://spacemovie.mur.at/   http://helsinki.at/

[perl-win32-gui-hackers] DragDrop as xs

[Reini U. <ru...@x-...>]

Hi
I just finished adding DragDrop to Win32::GUI.

I didn't like the Loft methods and it's Win32::API dependency,
so it's a good GUI.xs and Window.xs integration with the "DropFiles"
NEM and OEM events supported.
Attached is the generated pod and patch.

A Window can use the -dropfiles =3D> 0|1 option to accept dropping files,
or the DragAcceptFiles() method.
The event can be registered via <name>_DropFiles or via -onDropFiles.
Sample:
sub Main_DropFiles {
  # check if called as method or function
  if ($_[0] =3D~ /Win32::GUI::(Window|DialogBox)/) {
    shift;
  }
  # now the DragDrop handle should be on the stack. (not an object yet thou=
gh)
  my $files =3D Win32::GUI::DragDrop::DragQueryFiles(shift);
  return 0 unless @$files;
  ...
}

Some notes:
The DragDrop handle passed to the event is no object yet.
So only the function call is supported yet, not as method.

sub win_DropFiles { $files =3D $_[0]->DragQueryFiles(); } # invalid!
I didn't care to stash the handle in XS yet. It's just a long.
--
Reini Urban
http://phpwiki.org/
http://spacemovie.mur.at/   http://helsinki.at/

[perl-win32-gui-hackers] Some new stuff

[Reini U. <ru...@x-...>]

Unfortunately I have no direct cvs access to sf.net here at work,
and haven't checked 1.03_2 yet.
But I would find something like the attached patches (again 1.03) useful.

* Added some old samples from Aldo.
* DoEvents should take more PeekMessages params to be able to filter them,
  and help modeless dialogs.
* CustomDraw event (here only realized for ListView) and the old
workaround from rob
  as sample

--
Reini Urban
http://phpwiki.org/
http://spacemovie.mur.at/   http://helsinki.at/

[perl-win32-gui-hackers] RE: ListView Columns - Text Limit is 1023 Bytes

[Arthur S. <asc...@ve...>]

"One thought that you may want to consider is caching x number of values at a
time.  When the item changes, check the cache FIRST(in a hash based on the
index number as the key),  and only if you do not find the cached data, then do
the DB lookup. "

      o o o

     <snip>

Of note is an article in the Association of Computing Machiner 1985 Computing
Surveys magazine titled:

  Self-Organizing Linear Search
  pp 295 - 311
  ACM Computing Surveys
  1985 V17N3

It describes different means to optimize searches and includes a description of
a pre-search cache of temporary values. Amortized costs are included. 

On a different note, the proposed but not built Burroughs B8000 contained a
hardware 'cache' of frame pointers to enable quick access to objects in nested
procedures. (About 1970).

art  

[perl-win32-gui-hackers] RE: ListView Columns - Text Limit is 1023 Bytes

[Eric H. <eh...@co...>]

Here is a great idea sent to me personally from a List Member that I
wanted to post for everyone to see.

=20

QUOTE:

=20

One thought that you may want to consider is caching x number of values
at a time.  When the item changes, check the cache FIRST(in a hash based
on the index number as the key),  and only if you do not find the cached
data, then do the DB lookup.   I would do something like:

=20

load listview and cache x number of values, 1->x (20 may be a good
number)

when an item is clicked, check the cache first for existence of the
index clicked on

if it is in the cache, show the data from the cache=20

else run your query to load x number of records into the cache either
clearing or keeping all the existing data, depending on your expected
number of items total.  This depends on memory,etc. Obviously, if you
will have thousands of items in the listview, you may not want to keep
all the data in memory for performance reasons. =20

=20

This a) keeps memory footprint small, and b) gives quick response in
"most" cases, c) reduces total database round trips.  I would suggest
using a temp variable to hold the NEW version of the cache until after
your DB query lookup has returned.  This way, if the user clicks on an
item, the item is not in the cache AND the DB look up fails, you still
have all the existing cached data and can have the user try again
without losing the current cached values.  =20

=20

In General, if you or your users would access items sequentially in
"most" cases, you could also set up seperate thread to purge/load the
cache in the background., say  current index -20 through index +20  =20

=20

Just a thought...

=20

END QUOTE=20

=20

[perl-win32-gui-hackers] RE: ListView Columns - Text Limit is 1023 Bytes

[Eric H. <eh...@co...>]

Here is how I populate my textfields on my maintenance screen when a
user clicks a ListView item.

The index to the record in the database is stored as the last column in
each ListView row so I can

Use it to quickly/easily lookup the database row to fetch the memo
fields in their entirety.=20

=20

sub ListView_ItemClick {

  =20

        my $ls_text=3D"";           #-- ls for local scalar

        my $ls_ret=3D"";

        my $ls_error=3D"";

        my $ls_index=3D"";

        my $ls_sqltxt=3D"";

        my %lh_data=3D();          #-- lh for local hash

  =20

       $gs_item =3D shift;           #-- gs for global scalar

=20

       $ls_ret =3D Open_Database();  if ($ls_ret) {return 1;}

=20

       %lh_data  =3D $LV->ItemInfo($gs_item,36);  #-- record index

=20

       $ls_index =3D $lh_data{-text}; =20

=20

       $ls_sqltxt=3D"SELECT Comments, [In House Comments], [Analysis
Proposed Fix], Issue FROM Tracker WHERE Index =3D $ls_index";=20

=20

       $ls_ret =3D $gs_db->Sql($ls_sqltxt);

=20

       If ($ls_ret) {

             $ls_error=3D$gs_db->Error();      #-- get database error =
msg

             Close_Database();

             Win32::GUI::MessageBox($W,$ls_error, "CPS Issue Tracker -
Maintenance Screen - SQL Error($ls_ret)",16,);

             Win32::GUI::MessageBox($W,$ls_sqltxt,"CPS Issue Tracker -
Maintenance Screen - SQL Cmd",16,);

             Win32::GUI::MessageBox($W,"Can't Get Memo Fields From
Database", "CPS Issue Tracker - Maintenance Screen",64,);

            return 1;=20

       }

=20

      $gs_db->FetchRow();

=20

      $ls_text =3D $gs_db->Data("Comments");
$TF_Comments->Text($ls_text);=20

      $ls_text =3D $gs_db->Data("Analysis Proposed Fix");
$TF_ProposedFix->Text($ls_text);=20

      $ls_text =3D $gs_db->Data("In House Comments");
$TF_InHouse->Text($ls_text);=20

      $ls_text =3D $gs_db->Data("Issue");
$TF_Issue->Text($ls_text);=20

=20

      Close_Database();

     =20

      #-- additional code for the event follows but not shown here

}

=20

sub Open_Database() {

=20

       my =
$ls_FILEDSN=3D"FILEDSN=3D$gs_cwd\\Tracker.dsn;PWD=3DWin32Gui102";=20

=20

       #-- we don't want to show password if an error occurs so use this
string as error msg

       my $ls_FILEDSN2=3D"FILEDSN=3D$gs_cwd\\Tracker.dsn";=20

=20

      $gs_db =3D new Win32::ODBC($ls_FILEDSN);=20

=20

      if (! $gs_db) {

            my $ls_error=3DWin32::ODBC::Error();

            Win32::GUI::MessageBox($W,=20

                    "Can't Establish Database Connection
using:\n$ls_FILEDSN2\n$ls_error",=20

                    "CPS Issue Tracker - Error",16,);

            return 1;   =20

     }=20

     return 0;

}

=20

sub Close_Database() {

      $gs_db->Close(); =20

       undef $gs_db;

}

=20

=20

[perl-win32-gui-hackers] RE: ListView Columns - Text Limit is 1023 Bytes

[Eric H. <eh...@co...>]

 The options I have thought of to correct my application are:

=20

1)       load the database data memo fields to an associative array at
the same time I load the data to the ListView.

And then populate the maintenance screen's multiline textfields (to hold
the memo fields) in the ListView

ItemClick event. =20

2)       In the ListView ItemClick event, do a database lookup to fetch
the memo fields at that time instead of

      Holding all record memo fields in an associative array loaded when
the ListView is loaded.

=20

I chose number 2.  The slight drawback to this method is the slight
delay when arrowing or scrolling up/down

Within the ListView since the ItemClick event has to do a database
lookup.  The slight delay really is not

Noticeable but could potentially be if network traffic or database
traffic is high.=20

=20

Eric

[perl-win32-gui-hackers] ListView Columns - Text Limit is 1023 Bytes

[Eric H. <eh...@co...>]

Can the maximum characters stored in a Listview column be increased to
value above 1023 bytes?

I need to store memo field data from an MS-Access database with more
than 1023 characters

In the field.   I have done a print statement in my ODBC fetch statement
to ensure all the memo

Data is returned to the PERL program before inserting into the ListView.
Data is all there in the

Print. But when I print the data after loaded to ListView, it truncates
to 1023 chars.   This is bad

Because my program is written to load DB data to the ListView first.
Then when a user clicks

A ListView item, the data is placed in a maintenance screen for editing
in multiline textfields.

But since the Listview does not hold but 1023 chars, the data does not
get populated entirely into

The textfields.  =20

=20

Can the ListView max text size value be set to accommodate more text
than 1023 bytes?

=20

The length of data displayed in a ListView column is less than 1023
bytes.   You may only

See 700 bytes in the ListView, but it actually stores 1023 bytes.  The
amount of data shown

In the ListView column is not dependant on font size either.  I see the
same length of data

With a small font as with a large font.  That is just an FYI.

=20

Thanks,

Eric=20

Re: [win32gui] RE: [perl-win32-gui-hackers] Commit

[Robert M. <rm...@po...>]

Jeremy White wrote:
> 
> Just tested under ming, and I had the following errors:
> 
> NotifyIcon.xs: In function `void 
> XS_Win32__GUI__NotifyIcon__Add(PerlInterpreter*
> , CV*)':
> NotifyIcon.xs:27: error: `NOTIFYICONDATA_V1_SIZE' undeclared (first use 
> this function)

Thanks - I just committed an addition to GUI.h to rectify this.  Builds 
and test fine under MinGW for me now.

> I changed:
> 
> nid.cbSize = NOTIFYICONDATA_V1_SIZE;
> 
> to:
> 
> nid.cbSize = sizeof(NOTIFYICONDATA);
> 
> and it compiled - I'm not sure what the implications would be of this 
> change?

It'd probably break if you run it on a system with shell.dll version 
less than 5, as that shell.dll is expecting cbSize to be 
NOTIFY_ICONDATA_V1_SIZE (88 bytes), whereas we are compiling with macros 
defined such that sizeof(NOTIFYICONDATA) is 488 bytes.

What this code does is set cbSize to the smallest possible (all 
shell.dll versions should honour this), and then in GUI_Options.cpp I 
set it bigger if the shell.dll version allows it.

> The tests all pass, and your example works fine (nice example BTW!).

Thanks.

Rob.

RE: [perl-win32-gui-hackers] Commit

[Jeremy W. <jez...@ho...>]

>I've just committed my Christmas set of changes.  There's quite a bit here:

Nice changes:)

Just tested under ming, and I had the following errors:

NotifyIcon.xs: In function `void 
XS_Win32__GUI__NotifyIcon__Add(PerlInterpreter*
, CV*)':
NotifyIcon.xs:27: error: `NOTIFYICONDATA_V1_SIZE' undeclared (first use this 
fun
ction)
NotifyIcon.xs:27: error: (Each undeclared identifier is reported only once 
for e
ach function it appears in.)
NotifyIcon.xs: In function `void 
XS_Win32__GUI__NotifyIcon__Modify(PerlInterpret
er*, CV*)':
NotifyIcon.xs:50: error: `NOTIFYICONDATA_V1_SIZE' undeclared (first use this 
fun
ction)
NotifyIcon.xs: In function `void 
XS_Win32__GUI__NotifyIcon__Delete(PerlInterpret
er*, CV*)':
NotifyIcon.xs:70: error: `NOTIFYICONDATA_V1_SIZE' undeclared (first use this 
fun
ction)
NotifyIcon.xs: In function `void 
XS_Win32__GUI__NotifyIcon__SetFocus(PerlInterpr
eter*, CV*)':
NotifyIcon.xs:88: error: `NOTIFYICONDATA_V1_SIZE' undeclared (first use this 
fun
ction)
NotifyIcon.xs: In function `void 
XS_Win32__GUI__NotifyIcon__SetVersion(PerlInter
preter*, CV*)':
NotifyIcon.xs:106: error: `NOTIFYICONDATA_V1_SIZE' undeclared (first use 
this fu
nction)
NMAKE : fatal error U1077: 'C:\WINDOWS\system32\cmd.exe' : return code '0x1'
Stop.

Looking at:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/shell/reference/structures/notifyicondata.asp

I changed:

nid.cbSize = NOTIFYICONDATA_V1_SIZE;

to:

nid.cbSize = sizeof(NOTIFYICONDATA);

and it compiled - I'm not sure what the implications would be of this 
change?

The tests all pass, and your example works fine (nice example BTW!).

Cheers,

jez.

[perl-win32-gui-hackers] Commit

[Robert M. <rm...@po...>]

Hi all,

I've just committed my Christmas set of changes.  There's quite a bit here:

- Label.xs correct -truncate option processing, as SS_.*ELLIPSIS.*
   styles are not single bits

   Using the Win32::GUI::Label -truncate option was broken - fixed it.
   Note that this option can only be used with WinNT and higher (i.e. it
   is ignored by Win98).

- NotifyIcon.xs, GUI_Options.cpp, GUI.pm re-work NofifyIcon
   class. Add balloon tooltips. Add support for message behaviour. Add
   support for setfocus.  Add documentation. (Tracker: 1065072)
- t\05_NotifyIcon*.t, MANIFEST Notify Icon Tests added
- samples\NotifyIcon.pl, MANIFEST add demo app

   Re-worked the NotifyIcon class, added Balloon tips (for Shell.dll
   version 5 and higher only - IIRC that's Win2K and higher only).

   Deprecated (with warning) nasty old way of calling Delete(-id => ... )
   to remove an icon;  deprecated need to set -id option in constructor;
   Added documentation, sample and tests

   New options -ballooon_tip, -balloon_title, -balloon_icon and
   -balloon_timeout;  New methods ShowBalloon(), HideBalloon(),
   SetFocus(), SetBehaviour();  See documentation for details.

- GUI.pm Changed initial value of $Win32::GUI::MenuIdCounter to avoid ID
   clash with predefined WM_COMMAND values (IDOK, IDCANCEL,  etc.)

   Discovered that a Window with -dialogui => 1 and no default button
   fired the first menu item when ENTER pressed.  Fixed.

- GUI.xs Fix SendMessageTimeout to match documentation and return
   undef on failure. (XSRETURN_UNDEF rather than XSRETURN_NO).
- GUI.pm corrected documentation of default values for autohscroll
   and autovscroll in Textfield documentation
- GUI_MessageLoops.cpp added processing of WM_NEXTDLGCTL to
   CommonMessageLoop to allow for tabbing out of multiline Textfields
   when using -dialogui

- GUI_MessageLoops.cpp fixed WM_ERASEBKGND (Tracker:1363141)

   WM_ERASEBKGND was not doing its stuff when called from BeginPaint
   by DefWindowProc, and we had a -background option.  This due to
   BeginPaint Validating the update region before calling WM_ERASEBKGND

- Splitter.xs, GUI_Helpers.cpp, GUI.h re-worked splitter class.
   (Tracker:1363141)

   Re-wrote the splitter class, in an attempt to fix the problems
   reported in Tracker 133141 (drawing problems).  Fixed several
   potential problems (related to losing mouse capture without getting
   a mouse-up), but not this one.  It looks like it is a RichEdit
   re-draw problem, and nothing to do with the splitter class.  I'll
   deal with this in a seperate mail.

- RichEdit.xs made -background and -foreground work
- GUI_MessageLoops.cpp made -background work for Splitter windows
- GUI_Helpers.cpp removed an unnecessary dTHX, replacing it with
   PERLUD_FETCH

- Upped version to 1.03_02

   As my NotifyIcon.pl sample has a dependancy on these code changes,
   allowing use Win32::GUI 1.03_02;


Compiles and tests OK on Win98, VC++ 6.   I haven't tried MinGW or 
Cygwin environments.  The NotifyIcon changes have been tried on Win2K, 
but I haven't run the new NotifyIcon tests there.

Regards,
Rob.
Regard

Re: [win32gui] [perl-win32-gui-hackers] GUI_Options.cpp: Bug?

[Robert M. <rm...@po...>]

Arthur Schwarz wrote:
> I've just looked at GUI_Options.cpp again and wonder if the following code is
> correct:
> 
>   perlcs->cs.style &= perlcs->cs.style ^ (DWORD) SvIV(ST(next_i));

Looks fine to me:

&= (assignment operator) has lower precedence than ^ (Bitwise exclusive 
or) - see perldoc perlop

So it is the same as:

a = a & ( a ^ b)

And drawing up the logic table:

a b  a^b (a^b)&a
- -  --- -------
0 0   1     0
0 1   0     0
1 0   1     1
1 1   0     0

So the result is 1 only if a is 1 and b is 0, which is exactly what 
we're looking for.

You're right that other options are possible (for example a &= ~b, which 
would be my first choice), but it's not broken.  I haven't tried 
comparing speeds.

Regards,
Rob.

[perl-win32-gui-hackers] Re: GUI_Options.cpp: Bug?

[Arthur I S. <Art...@ra...>]

                                                                           
             Arthur Schwarz                                                
             <aschwarz1309@ver                                             
             izon.net>                                                  To 
                                       per...@li...urce 
             12/21/2005 04:58          forge.net,                          
             PM                        art...@ra...       
                                                                        cc 
                                                                           
                                                                   Subject 
                                       GUI_Options.cpp: Bug?               
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           







I've just looked at GUI_Options.cpp again and wonder if the following code
is
correct:

  perlcs->cs.style &= perlcs->cs.style ^ (DWORD) SvIV(ST(next_i));

Shouldn't this be something like:

  perlcs->cs.style &= (perlcs->cs.style | (DWORD) SvIV(ST(next_i)))
                                        ^ (DWORD) SvIV(ST(next_i));

or

  perlcs->cs.style &= ~((DWORD) SvIV(ST(next_i)));

(other formulations are possible)

I don't have the complete picture, but wouldn't the original equation act
as a
toggle? If it's off, it get's turned on, if it's on it get's turned off? Is
there some guarantee that the requested removal action actually has been
previously selected?

The inquiring mind.

art

RE: [perl-win32-gui-hackers] -style deprecated

[Jeremy W. <jez...@ho...>]

>The primary issue is maintenance and ease of understanding. In this case, 
>speed
>is increased and space is decreased.

[snip]

>My motivation is to reduce maintainence, increase clarity, and if possible,
>increase the speed of execution and decrease the memory footprint.

All worthwhile sentiments, and from a macro viewpoint I do agree. I guess 
I'm coming from the "if it isn't broke, don't fix it" mentality of the 
commercial world - which isn't exactly applicable here:)

Cheers,

jez.

[perl-win32-gui-hackers] RE: Constants and hashing

[Arthur S. <asc...@ve...>]

>>our original discussions until now, I think it may be more worthwhile to
>>   figure out how to make _all_ 18000 constants available to Win32::GUI
>>programs, without paying a huge price in memory.  Those constants that
>>actually get used get cached in the stash anyway...
>>

I forgot to mention it. For a 'good' hashing algorithm using a closed hashing
table, the performance is (about) O(1) for table occupancy sizes less than 70%.
As the occupancy increases, the performance decreases asymptotically to O(n), n
= the table size.

For an open hashing table, the amortized rate stays about O(1) for all entries
(without addressing other issues).

So, for Perl hashing, does Perl use open or closed hashing? If Perl uses closed
hashing then for 18,000 entries you need a table able to hold at least 26,000
entries, assuming that the algorithm used is 'good' using the data supplied.

For an open hashing table the size should be about the same + the size needed
to retain collisions. So the performance is good but the table size might
actually increase.

If size is an issue, then maybe hashing is not the answer. But I tend to agree
that on newer computers, size probably is not that significant. But on older
PC's, well, it might be a killer condition.

art

[perl-win32-gui-hackers] GUI_Options.cpp: Bug?

[Arthur S. <asc...@ve...>]

I've just looked at GUI_Options.cpp again and wonder if the following code is
correct:

  perlcs->cs.style &= perlcs->cs.style ^ (DWORD) SvIV(ST(next_i));

Shouldn't this be something like:

  perlcs->cs.style &= (perlcs->cs.style | (DWORD) SvIV(ST(next_i)))
                                        ^ (DWORD) SvIV(ST(next_i)));

(other formulations are possible)

I don't have the complete picture, but wouldn't the original equation act as a
toggle? If it's off, it get's turned on, if it's on it get's turned off? Is
there some guarantee that the requested removal action actually has been
previously selected?

The inquiring mind.

art

RE: [perl-win32-gui-hackers] -style deprecated

[Arthur S. <asc...@ve...>]

> >On another note, while looking for -style I looked at GUI.xs.
> >
> >Being loath to comment:
> >1.  GUI.xs uses a conditional ladder to perform a search.
> >2.  On success, GUI.xs executes code in the conditional block.
> >
> >It occurs to me that there are two operations that need to be performed; 1)
> >search, 2) some action based on the search. The current approach is the 
> >same
...

> However, there is always functions that aren't worth optimising 
> because either they are used during initialisation or they are called 
> infrequently during runtime. I don't know if this is the case in what you've 
> highlighted. Yes, in principle the best code should be always used, but 
> would it be worth your time "fixing" this area when it's not broken? I would 
> say if there is little benefit in terms of performance, your talents are 
> better used elsewhere.

The primary issue is maintenance and ease of understanding. In this case, speed
is increased and space is decreased.

The rationale is that since the basic code doesn't change (search and decision)
future changes are limited to placement of data within a data structure.
Maintaining the current approach requires the generation of code, for the
search, and the placement of the code within a conditional ladder, and the
generation of code for the action to be performed or the reuse of existing
code. Software must be tested and revalidated for new code, search or action.
What the proposed change does is to remove design decisions for the search
phase and at the same time remove any requirement for retesting the search, and
to leave intact decisions and testing related to the action. If an action is
reused, it presumably need not go through any rigorous testing for a reuse. If
a new action is developed, it must be tested.

In a minimalistic sense, all that has been done is to convert an increase in
code to an increase in a data structure and to reuse code. Of more global
scope, with the existing mechanization as the number of entries grows, the
amount of code grows. Even though the code is well organized and easy to
understand, at some stage it becomes almost intractable to maintain because of
its size. 

My motivation is to reduce maintainence, increase clarity, and if possible,
increase the speed of execution and decrease the memory footprint.

art

RE: [perl-win32-gui-hackers] -style deprecated

[Jeremy W. <jez...@ho...>]

>I get the message. What should be used? Looked at all the documentation 
>that I
>have (including my new jeb-doc) and can't find what the alternative is. 
>Sigh.

see:

http://perl-win32-gui.sourceforge.net/cgi-bin/docs.cgi?doc=reference-options

popstyle, pushstyle is what you want.


>On another note, while looking for -style I looked at GUI.xs.
>
>Being loath to comment:
>1.  GUI.xs uses a conditional ladder to perform a search.
>2.  On success, GUI.xs executes code in the conditional block.
>
>It occurs to me that there are two operations that need to be performed; 1)
>search, 2) some action based on the search. The current approach is the 
>same
>type of approach that was used in GUI-Constants.cpp. That was changed to a
>hash, I wonder if this can also be changed (and yeh, I do know about "it's 
>not
>used too often", but the best code is the one to be desired, yes?).
>
>The search consists of two parts:
>   search, action

Personally, I'm a speed freak - if something can be made faster, I'm all for 
it. In my own apps, I'll even go as far as making the code harder to 
maintain:) However, there is always functions that aren't worth optimising 
because either they are used during initialisation or they are called 
infrequently during runtime. I don't know if this is the case in what you've 
highlighted. Yes, in principle the best code should be always used, but 
would it be worth your time "fixing" this area when it's not broken? I would 
say if there is little benefit in terms of performance, your talents are 
better used elsewhere.

My intent is not to discourage you, on the contrary, you clearly know what 
you are doing, and you will be a great asset to the Win32-GUI project. Your 
suggestion may have merit, but you would need to do some testing to see how 
long Win32-GUI spends in the area's that you think could be optimised. If 
you create some code to do this, and you need other people to run it against 
their applications, I'm sure people would help gather the statistics.

Cheers,

jez.

[perl-win32-gui-hackers] -style deprecated

[Arthur S. <asc...@ve...>]

I get the message. What should be used? Looked at all the documentation that I
have (including my new jeb-doc) and can't find what the alternative is. Sigh.

On another note, while looking for -style I looked at GUI.xs. 

Being loath to comment:
1.  GUI.xs uses a conditional ladder to perform a search.
2.  On success, GUI.xs executes code in the conditional block.

It occurs to me that there are two operations that need to be performed; 1)
search, 2) some action based on the search. The current approach is the same
type of approach that was used in GUI-Constants.cpp. That was changed to a
hash, I wonder if this can also be changed (and yeh, I do know about "it's not
used too often", but the best code is the one to be desired, yes?).

The search consists of two parts:
  search, action

A data structure (in C/C++) can be constructed to accomodate this,
to wit:

    typedef struct SEARCH {
              char * Str;
              <type> Action;
            };

    SEARCH  Table[] = { { "string", <attributes> }
                      , { "string", <attributes> }
                      , ...
                      };

    where <type> can be any collection of things you might
    like done. For example:

    <type> could be: typedef bool (*func)(<data type> <data);

    yielding pointers to functions, or it could be an int
    or an enumeration type, yielding a switch statement, 
    or ....
 
    In a similar way the <attributes> can be a single 
    attribute (which is what seems to be done now) or
    some complex list of attributes.

    And the search code could be something like:

    if ( Idx = Search(<input string>) > -1 ) {
      Table[Idx].Func(<data>);   // or
      switch Table[Idx].Swtch;   // or something else
    }

    the choice of Search is left open and need not be
    a function (as shown here).

The sole advantage (that I can see) is that the conditional ladder is made a
search through a data structure. The data structure can be altered but the
Search and action code need not be changed, since the search is independent of
data content and the action is captured as part of the data. And, to some
limited extent, it's faster.

On another note, have you thought about reworking your debug statements? What I
usually do is one of:

# if #defined DEBUG_FLAG
  #define  DEBUG( stmt ) stmt
# else
  #define  DEBUG( stmt )
# endif

  and in use I do something like:

  DEBUG( fprintf (...) ); )

  or in more complex cases, something like:

  DEBUG({ really complex debug code; })

  which all disappears if the flag is not defined. I think
  the code looks cleaner than:

# if defined DEBUG_FLAG
   code;
# endif

Since I normally like to be able interactively turn debugging on and off during
development (and to do it selectively based on some ungodly reasoning), I often
augment the above to something like:

# if #defined DEBUG_FLAG
  #define  DEBUG( flag, stmt ) if ( flag ) stmt
# else
  #define  DEBUG( stmt )
# endif

  with an example of:

  DEBUG( flag, fprintf(); )  // or
  DEBUG( flag, {really complex stuff})

  And if the flag is not a const then it can be turned
  on or off, and if it is a const false, the compiler
  should remove the code.


Whew. Another mind buried in ego.

art

    
    

Re: [perl-win32-gui-hackers] Win32::GUI::Dialog() failure

[Jeremy W. <jez...@ho...>]

>I think I've followed all the suggestions. I've tried to
>put use scoping correctly, and I've found out that the
>only thing that the exporter seems to export are subroutine
>names. It's clear that I don't know what I'm doing. Any
>more suggestions?

could you post an example?

Cheers,

jez.