Re: [win32gui] Re: [perl-win32-gui-users] Wrappers for listviews/comboboxes etc...
Hi all,
I've been a lurker on this list for some time now (probably a year or
more), but I finally got time in the last few weeks to start playing
with Win32::GUI properly. Firstly can I thank the regulars for a great
set of features, and to say what an improvement V1.0 is over what I had
played with before.
I have been thinking about this wrapper idea for some time, as there are
a number of useful 'widgets' that I would keep reusing, and think they
could be packaged up for others to use. Initially I was thinking of GUI
framework items: examples are splash screens, about boxes and the like,
that virtually every UI wants in order to look professional, but is the
almost the same over and over again. If nothing else these could serve
as great examples of what can be done.
Whilst I don't have anything to contribute in this vein right now, I
though this might be a good moment to introduce HyperLink.pm - a
sub-classing of Win32::GUI::Label that acts as a clickable hyperlink:
Headline features are:
- change of cursor to 'hand' when hovering over the label
- by default text is blue rather than black
- by default text gets underlined when the mouse is hovering
- by default link gets launched in browser when clicked
- takes all options available to Win32::GUI::Label class
- all defaults can be turned off or otherwise controlled
There is more documentation in the file itself, and a demo script
available at http://www.robmay.me.uk/win32gui/
Is this sort of packaging appropriate for others to use? I'd appreciate
feedback on whether more 'widgets' like this might be useful.
Regards,
Rob.
Ariel Serbin wrote:
Thanks for the responses...
That's good to know about Text() on the comboboxes.
I've been doing it the other way, as well.
I'm not sure if there's any weirdness related to
having the 0-width column because I always do
fullrowselect. I've thought about the shadow array
idea before and it is probably the best way to go.
One of the benefits to having the hidden field is that
I can expand it when debugging my code, but that
doesn't seem to be a good reason to design the wrapper
in that manner. Now that I think about it, the array
would probably be best for consistency, since there's
nowhere to hide a key field in the comboboxes.
I'm not exactly sure how I would like to implement
this either. It would be cool to be able to do
something like:
# get some data
$sth = $dbh-prepare('select person_id, first_name,
last_name from people');
...
# call a method to assign ids and populate the LV.
# if called without a key field it could
# automagically assign ids
$lv_wrapper-populate($sth-fetchall_hashref,
'person_id');
# suppose we have a button to remove items
# from the LV
btnRemove_Click {
$id = $lv_wrapper-id();
$lv_wrapper-remove($id);
return 1;
}
The neat thing about the hashref idea is that columns
could be named just by setting the AS params in the
sql and everything would be taken care of. This is a
decent model for when I'm building gui elements from a
DB, but it doesn't really match up to situations where
I build elements from an array of objects.
Any opinions?
-Ariel
---
SF email is sponsored by - The IT Product Guide
Read honest candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
Perl-Win32-GUI-Users mailing list
Perl-Win32-GUI-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
[perl-win32-gui-users] Win32::GUI bugs
A quick question on process: Should potential bugs be discussed on this list before raising bug reports at sourceforge? Rob.
[perl-win32-gui-users] Hyperlink.pm [Was: Wrappers for listviews/comboboxes etc...]
[EMAIL PROTECTED] wrote: Quoting Robert May [EMAIL PROTECTED]: [snip] I though this might be a good moment to introduce HyperLink.pm - a sub-classing of Win32::GUI::Label that acts as a clickable hyperlink: This is a great start - a nice object. Thanks. Although I had a problem with the constants (I'm on5.6) and got the following error: D:\Developmentperl HyperLinkDemo.pl Constant name 'HASH(0x1a4306c)' has invalid characters at HyperLink.pm line 88 BEGIN failed--compilation aborted at HyperLink.pm line 91. Compilation failed in require at HyperLinkDemo.pl line 15. BEGIN failed--compilation aborted at HyperLinkDemo.pl line 15. Once fixed, it worked great. Can you let me have the fix so that I can put it back in the source. Im on 5.8.6 and don't have any other environment to test at the moment. As a suggestion, it would be a good idea to get rid of the dependency on Win32::API - SetCapture and ReleaseCapture are already in Win32::GUI. If you are keen on this idea, I'll add GetCapture, LoadCursor into GUI.xs. The issue would then be ShellExecute - perhaps that should be added too? I'd love to get rid of the Win32::API dependency - you'll see it listed as one of the TODO items in the comments at the start of Hyperlink.pm. I had missed that SetCapture and ReleaseCapture were already there - I guess I searched the source for GetCapture, and didn't find that. It'd be great if you could add GetCapture - should I raise a tracker? LoadCursor() is superseded (according to microsoft) by LoadImage but the API to LoadCursor is much more straightforward ... I did try using the existing Win32::GUI::LoadImage API, but never made it work (it's really only designed to get an image from a file. If we could modify the Win32::GUI::Cursor package to be able to do something like LoadImage(IDC_HAND,IMAGE_CURSOR, 0,0,LR_DEFAULT_SIZE) I think that would be better. It would be great if we could apply the same change to Win32::GUI::Icon to allow us access to default Icon resources too. Am I making any sense? Adding ShellExecute (or ShellExecuteEx) is a bit more tenuous, but it does take a window handle as it's first parameter, so perhaps we can justify it? Rob.
[perl-win32-gui-users] Hyperlink.pm [Was: Wrappers for listviews/comboboxes etc...]
Glenn Linderman wrote:
Would it not be possible to just use
system qq{start whatever_command};
instead of ShellExecute? What is the advantage of ShellExecute?
That seems to work fine on my Win98 system. It takes a bit longer to
return control to the GUI (but only just noticable), and the return
values are less well defined (I can't find any info in the quick search
I've done). I'll put that in, and remove the dependancy on
ShellExecute, unless anyone know why ShellExecute might be preferable.
I've only tried this on W98 - does the fact that start in w2k onwards is
implelented as a shell builtin command cause any problems? The only
other problem I can think of is if the user has any other program called
start.exe/bat/etc. in their path in front of the windows one.
Thanks Glenn.
Rob.
[perl-win32-gui-users] Re: HyperLink.pm
While investigating the start vs. ShellExecute issue I stumbled on this:
http://sourceforge.net/mailarchive/message.php?msg_id=245600
Looks like I was beaten to it by about 3-4 years! OK, it doesn't do the
fancy dynamic underlining, but otherwise almost identical, down to the
Win32::API dependencies. I'll steal the idea of adding an AddHyperLink
method to the Win32::GUI::Window namespace though.
Rob.
Glenn Linderman wrote:
On approximately 2/16/2005 3:00 AM, came the following characters from
the keyboard of [EMAIL PROTECTED]:
Quoting Robert May [EMAIL PROTECTED]:
Hi Rob,
Nice work - thanks for contributing.
I have been thinking about this wrapper idea for
some time, as there are a number of useful 'widgets' that I would keep
reusing, and think they could be packaged up for others to use.
Initially I was thinking of GUI framework items: examples are
splash screens,
about boxes and the like, that virtually every UI wants in order to
look
professional, but is the almost the same over and over again. If
nothing
else these could serve as great examples of what can be done.
I think we’d all agree on this:) It comes down to who is going to do
the work and get the ball rolling. Ideally the sourceforge site would
be best place to have a repository of these kind of objects, and if
someone has the time to spare then I'm sure Aldo would give the
required permissions to play with the website.
Whilst I don't have anything to contribute in
this vein right now, I though this might be a good moment to introduce
HyperLink.pm - a sub-classing of Win32::GUI::Label that acts as a
clickable hyperlink:
This is a great start - a nice object. Although I had a problem with
the constants (I'm on5.6) and got the following error:
D:\Developmentperl HyperLinkDemo.pl
Constant name 'HASH(0x1a4306c)' has invalid characters at
HyperLink.pm line 88
BEGIN failed--compilation aborted at HyperLink.pm line 91.
Compilation failed in require at HyperLinkDemo.pl line 15.
BEGIN failed--compilation aborted at HyperLinkDemo.pl line 15.
Once fixed, it worked great.
As a suggestion, it would be a good idea to get rid of the dependency
on Win32::API - SetCapture and ReleaseCapture are already in
Win32::GUI. If you are keen on this idea, I'll add GetCapture,
LoadCursor into GUI.xs. The issue would then be ShellExecute -
perhaps that should be added too?
Would it not be possible to just use
system qq{start whatever_command};
instead of ShellExecute? What is the advantage of ShellExecute?
[perl-win32-gui-users] HyperLink.pm v0.11 available
Hi, Have updated my HyperLink.pm module, taking into account previous comments. It is available for download from http://www.robmay.me.uk/win32gui/ Summary of changes: - Wrote initial test suite - Turned comments into pod documentation, and completed documentation - Made API backward compatible with Win32::GUI::Hyperink v0.02 - Removed dependency on Win32::API - Added fallback cursor using Win32::GUI::BitmapInline - Correct VERSION format to x.xx for CPAN modules - removed Set/ReleaseCapture dependency on Win32::API - Added Win32::GUI::Window::AddHyperLink() function - Updated demo code to show new AddHyperLink usage Please see the Changes file in the distribution and the POD documentation for further information. I have only tested this on Win98, Perl 5.8.6, and would appreciate feedback on problems from other platforms. If I get positive fedback from this list, then I will make the distribution available from CPAN, and a PPM distribution available from my website. I assume that the namespace Win32::GUI::HyperLink is suitable? A question (that might be better suited to the hackers list?). I want to package the demo script with the distribution. In the current distribution I have followed the Tk model, and created a demos directory beneath the Win32/GUI installation location. In this directory I have created a HyperLink directory for my script. Is this a suitable way to proceed? If I do this, then I would assume that Win32::GUI package would distribute its sample code in the demos directory too. Thanks for your feedback, Rob.
[perl-win32-gui-users] Possible Bug with DoModal
I've gone nearly blind looking through the source code, and can't see
why I am experiencing the following behaviour. I have examined the
windows generated with Spy++, and the modal window has its parent/owner
set correctly, and I cannot see how the movement of the modal window
before calling DoModal causes a change in behaviour.
Am I using DoModal correctly? Does anyone else see the same problem.
Regards,
Rob.
# This shows a possible bug where a modal dialog loses its modality
# Try clicking on the close button of the main window after opening
# the modal window - the modal dialog closes, and a second click is
# need to then close the main window. The main window should
# be disabled.
#.
# If the code to center the dialog is moved to an 'onActivate'
# callback (or removed), then it all works fine.
#
# If the modal window is also a dialog window (-dialogui = 1), then
# it's special navigation features are lost (i.e. tabbing stops working,
# return = OK does not work).
#
# Workarounds:
# (1) Don't Center (or otherwise move the dialog) before calling doModal.
# I have resolved this by putting the Center() call in an onActivate
# handler.
# (2) If you only have one top-level window, set the 'all' flag to 1.
# I.e. $modal-DoModal(1).
use strict;
use warnings;
use Win32::GUI;
my $mw = Win32::GUI::Window-new(
-title = doModal() Bug,
-pos = [100,100],
-size = [200,200],
);
$mw-AddButton(
-text = Open Modal Window,
-onClick = \openModal,
);
my $modal = Win32::GUI::Window-new(
-parent = $mw,
-title = Modal Window,
-size = [100,100],
);
$mw-Show();
Win32::GUI::Dialog();
exit(0);
sub openModal
{
# Comment out this next line to see correct behaviour
$modal-Center($mw);
$modal-DoModal();
return 1;
}
[perl-win32-gui-users] Any plans for another Win32::GUI release
Question targetted at Laurent, I think. Are there any plans for an official 1.XX release, or an unofficial release of a CVS HEAD build, so those of us who don't have the capability to build from the CVS source can take advantage of the fixes and enhancements that are being applied to CVS? Regards, Rob.
Re: [win32gui] Re: [perl-win32-gui-users] Possible Bug with DoModal
I'll raise a bug report, as I can see no reason why there should be a
difference in behaviour depending on whether there is some code to move
a window before the DoModal() call.
Jez White wrote:
Hi,
Interesting one - I don't use DoModal much, but I use it like your
example - it does seem odd behaviour, and I can't see any thing that
is wrong. Perhaps it is a bug?
Cheers,
jez.
- Original Message - From: Robert May
[EMAIL PROTECTED]
To: perl-win32-gui-users@lists.sourceforge.net
Sent: Wednesday, March 16, 2005 9:38 PM
Subject: [perl-win32-gui-users] Possible Bug with DoModal
I've gone nearly blind looking through the source code, and can't see
why I am experiencing the following behaviour. I have examined the
windows generated with Spy++, and the modal window has its
parent/owner set correctly, and I cannot see how the movement of the
modal window before calling DoModal causes a change in behaviour.
Am I using DoModal correctly? Does anyone else see the same problem.
Regards,
Rob.
# This shows a possible bug where a modal dialog loses its modality
# Try clicking on the close button of the main window after opening
# the modal window - the modal dialog closes, and a second click is
# need to then close the main window. The main window should
# be disabled.
#.
# If the code to center the dialog is moved to an 'onActivate'
# callback (or removed), then it all works fine.
#
# If the modal window is also a dialog window (-dialogui = 1), then
# it's special navigation features are lost (i.e. tabbing stops working,
# return = OK does not work).
#
# Workarounds:
# (1) Don't Center (or otherwise move the dialog) before calling
doModal.
# I have resolved this by putting the Center() call in an onActivate
# handler.
# (2) If you only have one top-level window, set the 'all' flag to 1.
# I.e. $modal-DoModal(1).
use strict;
use warnings;
use Win32::GUI;
my $mw = Win32::GUI::Window-new(
-title = doModal() Bug,
-pos = [100,100],
-size = [200,200],
);
$mw-AddButton(
-text = Open Modal Window,
-onClick = \openModal,
);
my $modal = Win32::GUI::Window-new(
-parent = $mw,
-title = Modal Window,
-size = [100,100],
);
$mw-Show();
Win32::GUI::Dialog();
exit(0);
sub openModal
{
# Comment out this next line to see correct behaviour
$modal-Center($mw);
$modal-DoModal();
return 1;
}
---
SF email is sponsored by - The IT Product Guide
Read honest candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
Perl-Win32-GUI-Users mailing list
Perl-Win32-GUI-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
[perl-win32-gui-users] BUG REPORT[1164766]: Unhook() causes perl warning
Glen, thanks for the report.I'd be interested in a 5.8.6 report from someone, so that I can narrow it down to perl, or simply my installation. perl v5.8.4 build 810, Win32::GUI v1.0.1 [snip] I notice the error message you reported was from line 40, but there were not 40 lines in your test case... maybe you had more code than was shared on the list? Indeed - the text of the bug report was in comments at the start of the file, so that I keep it all together. The actual file I used for testing is attached to the sourceforge bug report.
[perl-win32-gui-users] Documentation and default values [Was: BUG Followup[1092732 ]:Slider no longer supports setting position]
Glen, Jez, Johan, Thank you for your follow-ups to the original bug report. I've had a quick scout round the other .xs files, and this documentation syntax isn't used elsewhere. I do, however, believe that I can clarify the syntax of the documentation for trackbasr.xs. The documentation of Win32::GUI::Trackbar::SetPos (from Trackbar.html) says: SetPos(POSITION,[REDRAW=1]) The XS code looks like this: ### # (@)METHOD:SetPos(POSITION, [REDRAW=TRUE]) # Sets the current logical position of the slider in a trackbar. LRESULT SetPos(handle, param, value=TRUE) HWND handle WPARAM param WPARAM value CODE: RETVAL = SendMessage(handle, TBM_SETPOS, value, (LPARAM) param); OUTPUT: RETVAL The code sets value to TRUE if not supplied, allowing the following 3 ways to call SetPos: (1) $obj-SetPos($pos)- value defaults to 1 and redraw is requested in SendMessage() (2) $obj-SetPos($pos, 1)- value explicitly set to 1 and redraw is requested in SendMessage() (3) $obj-SetPos($pos, 0)- value explicitly set to 0 and redraw is not requested in SendMessage() There are other examples where similar behaviour happens. So if we get back to my original bug report on Win32:GUI::Trackbar::Pos(), the documentation says: Pos([VALUE],[REDRAW=1]) And I firmly believe that this can be interpreted as: VALUE is optional. It doesn't have a default. (and if not supplied, method returns current position of slider) If VALUE is provided, then an optional second parameter is available, which if not proided defaults to1(true). The XS code cannot provide a default in this case (due to the optionality of the first argument), and so explicitly looks at the number of arguements. We have 4 ways to call this method, and for consistency with what happens elsewhere this is how I believe the behaviour should be: (1) $obj-Pos() - 0 arguments, return current position (TBM_GETPOS) (2) $obj-Pos($pos) - 1 argument, redraw defaults to 1 and redraw is requested (3) $obj-Pos($pos, 1) - 2 arguments, redraw explicitly set to 1, redraw is requested (4) $obj-Pos($pos, 0) - 2 arguments, redraw explicitly set to 0, redraw is not requested The bug I reported is with option (2), where the current code defaults redraw to 0. For consistency I think this should be changed. Can we reach an agreement on this? (BTW this 'problem' exists with methods Min(), Max(), Pos(), SelStart(), SelEnd() in trackbar.xs) Regards, Rob.
Re: [win32gui] [perl-win32-gui-users] Catching Combobox droplist mouse clicks
From the html page for the Win32::GUI class:
Dialog()
Enter the GUI dialog phase: the script halts, the user can interact
with the created
windows and events subroutines are triggered as necessary; note that
this function
must be called without ANY parameter or instantiation (eg. don't call
it as method
of a created object):
Win32::GUI::Dialog(); # correct
$Window-Dialog();# !!!WRONG!!!
Win32::GUI::Dialog(); does a similar thing to
while(Win32::GUI::DoEvents() != -1) {};
see also DoEvents() see also DoModal()
Regards,
Rob.
Kurt G wrote:
From reading this list it seems I'm wasn't the only Win32::GUI user
befuddled by droplist style Combobox control not catching mouse clicks
and other events. I spent way too much time yesterday RTFM, digging
for a solution, and trying to get it to work but finally today
stumbled into the solution:
If you create a Window and Combobox control like so:
$Window = new Win32::GUI::Window( ... options ... );
$Window-AddCombobox( ... options );
...and if your main window is processing messages like so:
$Window-Dialog();
...then it seems that not all messages (such as mouse clicks) are
filtered down to the Combobox control (thus not allowing droplist
items to be selected with mouse clicks) unless you change the above
statement to this:
GUI::Dialog();
...or I suppose Win32::GUI::Dialog() would work just the same, and
presto, now you can mouse click on items in the Combobox droplist.
Seems to affect which messages are being passed down to the Combobox
control via its parent window.
I don't know if this is a Win32::GUI::Combobox bug or what but anyhow
hope this hint is useful to other users running into similar issues.
-Kurt
---
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great
events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
___
Perl-Win32-GUI-Users mailing list
Perl-Win32-GUI-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
Re: [perl-win32-gui-users] Catching Combobox droplist mouse clicks
Jez White wrote: Kurt, droplist didn't work with the mouse but it wasn't obvious why. I wonder if invoking Dialog() via an instance should be outright forbidden in GUI.pm or GUI.xs. Unless there is a reason for Dialog to exists as a method - it probably should be forbidden - thoughts anyone? I can't (personally) see any reason for calling Dialog() on a specific window, but given that MS allow GetMessage() to be called with a specific window handle, there must be cases when people want to do this, and Dialog() is written to allow it. Hence, I wouldn't change it to be forbidden. Perhaps a warning issued if Dialog() is not called statically? Something like: if( PL_dowarn items !=0) warn(You probably meant Win32::GUI::Dialog()\n); near the start of the CODE section? Regards, Rob.
[perl-win32-gui-users] CVS Commits - bug fixes and enhancements
All, Jez White has kindly committed a set of changes that have been accumulating in my workspace. Details below: I will post a further message (to the users list only) about the Coolmenu changes mentioned below. + [Robert May] : Fixes for Toolbars: - Toolbar.xs: + Fixed message processing to switch on lparam-code, rather than HIWORD(wparam) + Various documentation changes where functions take command identifier, rather than button index + Fixed GetButtonInfo test for error conditions + Fixed GetButtonInfo returned flags to be 0 or 1 only. + Added missing GetString method + Fixed SetButtonInfo to set required cbsize element of button structure. - GUI.h + Added define for TB_GETSTRING for MinGW. + [Robert May] : Support for Coolmenu - GUI.h + Added prototyle for ProcessEventError so it can be called from GUI_Helpers.cpp + Added 'message' WM_TRACKPOPUP_MSGHOOK to use as a callback handle in the hooks array (see TrackPopupMenu, GUI.xs) - GUI_Helpers.cpp + Added WindowsHookMsgProc callback to be used by SetWindowsHookEx in TrackPopupMenu (GUI.xs) - GUI.xs + Re-worked TrackPopupMenu to: (1) allow X,Y to be optional, and use current cursor position if not provided. (2) use TrackPopupMenuEx, rather than TrackPopupMenu, and allow an (optional) excluded rectangle to be provided (3) to allow a (optional) code reference to a callback funtion to be provided that will be called for events occuring while the menu is displayed. + Added RemoveMenu() to Win32::GUI::Menu + [Robert May] : Support for chevrons in rebars - GUI.h + Added define for RBN_CHEVRONPUSHED for MinGW. - GUI_Options.cpp: + Added -idealwidth to ParseRebarBandOptions - Rebar.xs + Added ChevronPushed event: Rebar_onParseEvent, Rebar_onEvent + Added -idealwidth to GetBandInfo, InsertBand, and SetBandInfo (via ParseRebarBandOptions), including documentation + Documented RBBS_USECHEVRON style + [Robert May] : - GUI_MessageLoops.cpp + Fixed second parameter to DoHook() during WM_NOTIFY messages to be lparam-code, rather than HIWORD(wparam). + [Robert May] : - GUI.pm (Fix for Richedit crash. Tracker: 1064828, 1153899) + Moved LoadLibrary for richedit.dll to constructor to prevent loading library unnecessarily + Removed end block to FreeLibrary*(), as not necessary (and can get executed before Richedit's DESTROY method) + [Robert May] : - Trackbar.xs + Modifed Pos() to get one argument call have correct default for second argument. + Modifed Min() to get one argument call have correct default for second argument. + Modifed Max() to get one argument call have correct default for second argument. + Modifed SelStart() to get one argument call have correct default for second argument. + Modifed SelEnd() to get one argument call have correct default for second argument. Regards, Rob.
[perl-win32-gui-users] Internet Exlorer like tool and menu bars (Coolbar.pm)
All, I have for some time no been tinkering with getting Internet Explorer like menu bars working (aka CoolMenu or CoolBar). If you have the facility to download the latest CVS code, and build your own Win32::GUI, then you may be interested in my Coolbar.pm module, available from http://www.robmay.me.uk/win32gui/ Coolbar.pm is an experimental module to do Internet Explorer like menu bars and toolbars. Currently only the menubar functionality is (mostly) implemented. To use this module you need to download and build a Win32::GUI installation from the sourceforge CVS, as there are required changes in the codebase. Currently you need to read the comments and look at the example to see how to use it - there will be proper documentation in the fullness of time. [If you want to play, and can't build your own, then might be able to build a PPM from the current CVS, but I'm using MinGW, and the libraries I'm building are huge compared to the VC++ built ones.] Looking forward to your feedback. Regards, Rob.
Re: [perl-win32-gui-users] Internet Exlorer like tool and menu bars (Coolbar.pm)
Aldo Calpini wrote: Jez White wrote: The coolbar basically inherits from the rebar - various changes were added by Rob so that menus can be added to a band within the rebar:) cool then :-) See more information on what I've implemented at: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/commctls/faq/iemenubar.asp As you can't put a menubar in a Rebar you have to simulate a menu using a toolbar, with buttons for each menu selection, and drop-down menus from each button. You then have to handle all the keyboard/mouse navigation, and handle moving menus into a drop-down from the rebar chevron (which is displayed when the rebar becomes too small to display all the buttons). Coolbar.pm wraps all this functionality into a simple to use API that takes a standard Win32::GUI menu definition (as you would pass to MakeMenu()). I intend to add capabilities for standard toolbars and chevrons to the package. See: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/commctls/faq/ietoolbar.asp Regards, Rob.
Re: [perl-win32-gui-users] RichEdit and Hyperlink
Len,
This should get you started. I've only tested on activestate perl
5.8.6, and win98. You'll need a Win32::GUI build from CVS if you want
to be able to click on the links,as Hook()ing WM_NOTIFY messages is
broken in Win32::GUI V1.0.
Let me know how you get on.
Regards,
Rob.
#!perl
use strict;
use warnings;
use Win32::GUI;
# some constants
sub WM_USER {1024};
sub WM_NOTIFY{78};
sub WM_LBUTTONDOWN {513};
sub EM_AUTOURLDETECT {return(WM_USER()+91);};
sub ENM_LINK {67108864};
sub EN_LINK {1803};
my $mw = Win32::GUI::Window-new(
-title = Richedit control with URLs,
-pos = [100, 100],
-size = [400,300],
);
# Create a richedit 2.0 control (note change to class, as Win32::GUI
natively only supports
# richedit 1.0)
my $re = $mw-AddRichEdit(
-width = $mw-ScaleWidth(),
-height = $mw-ScaleHeight(),
-class = RichEdit20A,
);
# Turn on Auto-highlighting of links
# See
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/commctls/richedit/richeditcontrols/richeditcontrolreference/richeditmessages/em_autourldetect.asp
$re-SendMessage(EM_AUTOURLDETECT, 1, 0);
# Set the richedit's event mask to pass us EN_LINK messages
my $em = $re-GetEventMask();
$re-SetEventMask($em | ENM_LINK);
# Hook the EN_LINK message
# NOTE: hooking WM_NOTIFY messages if broken in Win32::GUI V1.0 - you
need the head revision from CVS
# for this to work
$re-Hook(EN_LINK, \handleLink);
# Put some text in the richedit control
$re-Text(Some text with a link: http://www.robmay.me.uk/win32gui/\n; .
Some more text with another link: file:///C:/\n);
$mw-Show();
Win32::GUI::Dialog();
# Avoid bug in Win32::GUI V1.0 causing crash on exit with Richedit -
fixed in CVS head revision
undef $re;
exit(0);
# Handler for the EN_LINK messages
# See
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/commctls/richedit/richeditcontrols/richeditcontrolreference/richeditnotificationmessages/en_link.asp
sub handleLink
{
my ($object, $wParam, $lParam, $type, $msgcode) = @_;
# return if it's not the message we wanted - see the documentation for
Hook()
# for why this is necessary
return if $type != WM_NOTIFY;
return if $msgcode != EN_LINK;
# lParam is a pointer to an ENLINK structure
# This is pretty tortuous, but perl really doesn't expect to be handling
# pointers to real memory. What it does is treat $lParam as a real
pointer
# to memory, grabs 32 bytes from that memory location, and unpacks the
# bytes as sets of long (4-byte) numbers
my ($hwndFrom, $idFrom, $code, $orig_msg, $orig_wParam, $orig_lParam,
$cpMin, $cpMax) =
unpack('', unpack(P32, pack('L', $lParam)));
# if message is a left mouse down, then extract the link text
# and print it (or launch it in a browser, or whatever ... )
# See link above for what messages $orig_msg may contain
if($orig_msg == WM_LBUTTONDOWN) {
my $text = $object-GetTextRange($cpMin, ($cpMax-$cpMin));
print Clicked on link: $text\n;
}
return;
}
[EMAIL PROTECTED] wrote:
Does anyone know if it is possible to put a Hyperlink in a RichEdit
control, and in particular a file:// hyperlink?
Thanks
Len.
Re: [win32gui] [perl-win32-gui-users] Catching die() before Win32::GUI
Can you catch the 'die' by putting the offending call in an eval block
(perldoc -f eval).
Regards,
Rob.
#!perl
use strict;
use warnings;
use Win32::GUI;
my $mw = Win32::GUI::Window-new(
-title = Cheating death,
-pos = [100,100],
-size = [100,100],
);
$mw-AddButton(
-text = Click me!,
-name = B1,
);
$mw-Show();
Win32::GUI::Dialog();
exit(0);
sub B1_Click
{
eval {
die 'Don't press the button';
};
warn Warning: $@ if $@;
return 1;
}
__END__
Robinson wrote:
[docs]
Finally, you should note that events are really evaluated (as if they were
called with eval()), so that errors are trapped, and a message box is shown.
This box reports the offending event name on the title bar, the error
message in its body and has OK and Cancel buttons. If you press OK,
Win32::GUI will ignore the error and go on with the dialog (the event, of
course, doesn't take place); if you press Cancel instead the dialog will end
(with return code -1). This means that for example if you define an event
like:
sub Button1_Click {
die();
}
your script will not die immediately at the click of a button, but the
message box will appear, reporting for example ``Died at script.pl line
73''.
[/docs]
I'm using XMLRPC::Lite with Win32::GUI and if the person's offline, they'll
of course get an error which (in X::L) results in a call to die(). which
brings up the OK/Cancel box. which kills the app on cancel. Not what I'd
like to happen. Anyone know a way _around_ this?
--
Robinson
[EMAIL PROTECTED]
---
This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.
Play to win an NEC 61 plasma display: http://www.necitguy.com/?r=20
___
Perl-Win32-GUI-Users mailing list
Perl-Win32-GUI-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
[perl-win32-gui-users] New release soon: Win32::GUI v1.01 RC1 available for testing
All, We've been discussing a new release on the hackers list for the last week or so. There's a lot of good additions and bug fixes that have been made by various contributors since the V1.0 release at the end of last year. Release candidate 1 (RC1) for V1.01 is available for downloading and testing. PPMs for ActiveState perl 5.6 and 5.8 are available from http://www.robmay.me.uk/win32gui/ The PPMs include the CHANGELOG. It is important to uninstall the previous versions, as these new PPMs install the html document tree in a different location (C:\Perl\html\site\lib\Win32\GUI rather than the incorrect C:\Perl\html\lib\Win32\GUI) - instructions are in the README.TXT file with the distribution. Assuming that there are no problems with this release candidate, then I would propose making it a formal release in the next few weeks. Please feedback your experiences (good as well as bad) to this list. I do intend to do some significant work on the documentation in the next week or so, so hopefully those changes will make it into the v1.01 release. Regards, Rob.
Re: [win32gui] [perl-win32-gui-users] New release soon: Win32::GUI v1.01 RC1 available for testing
Robert May wrote: [edited] Release candidate 1 (RC1) for V1.01 is available for downloading and testing. PPMs for ActiveState perl 5.6 and 5.8 are available from http://www.robmay.me.uk/win32gui/ The PPMs include the CHANGELOG. Assuming that there are no problems with this release candidate, then I would propose making it a formal release in the next few weeks. Please feedback your experiences (good as well as bad) to this list. My server logs show a number of you having downloaded RC1. My assumption from no feedback is that you are having no problems with it, but I can't be sure. Please can I have an it's OK or I'm having trouble response, so that I can get some confidence of where we are with this release, as I'm reluctant to put a formal build up on Sourceforge based only my experience. There are a few small changes that I want to complete prior to a V1.01 release (although none of them really affect a PPM distribution). Would any of you how downloaded the RC1 distribution be prepared to test an RC2 distribution as well? Regards, Rob.
Re: [win32gui] [perl-win32-gui-users] TabFrame - deprecated style
Chris Wearn wrote:
Hi All,
Using the TabFrame module developed by Laurent... however using the
latest checkout from Sourceforge CVS, in use, it errors with non-fatal
warnings of '-style' and '-exstyle' being deprecated in GUI.pm line 597.
Has anybody got a fix for Frame.pm to work.
Chris,
I was just having a look at this - it seems Win32::GUI's support for
control of warnings is somewhat limited. I will start a discussion on
the hackers list to see if we can come up with a better solution. In
the mean time, try adding this somewhere near the start of your
program. It will silence the messages that you are worried about:
$SIG{__WARN__} = sub { print $_[0] if $_[0] !~
/^Win32::GUI.*-(ex)?style/; };
Regards,
Rob.
[perl-win32-gui-users] ANNOUNCE: Win32::GUI v1.02
I am please to announce that v1.02 of Win32::GUI is available for download from SourceForge. Win32::GUI is a Perl extension allowing creation of native Win32 GUI applications. Project summary and download: http://sourceforge.net/projects/perl-win32-gui/ Release notes: http://sourceforge.net/project/shownotes.php?release_id=341357 My thanks to everyone who has been involved in preparing this release. Regards, Rob.
RE: [perl-win32-gui-users] listview text color
Glenn W Munroe wrote:
I'm afraid the short answer is no (as far as I'm aware)--at least not
using the latest Win32::GUI release. Someone asked this a year or so ago and
I looked into it, eventually coming up with a tremendous hack (using hooks)
to get it to work. Since then, the XS code has changed and the hack doesn't
even work any more. Having said that, I don't think it would be *too*
difficult to get it to work again, but it would involve modifying the
listview XS code. In case you're interested, I've included the code as a
guide (it worked a couple of releases ago, but the Hook call now fails). Jez
White and Chris Wearn have done some work on the listview code recently;
maybe they have some ideas too...
Glenn
Glenn,
I fixed this up to work with the CVS release of Win32::GUI some time ago. Now
that we have a V1.02 release that it will run against it's time to share it back
with you and the list. The fundamental problem was that Hook()ing WM_NOTIFY
messages was broken in Win32::GUI v1.0
With your permission I'd like to add this as a sample to the project?
Regards,
Rob.
#!perl -w
use strict;
use warnings;
use Win32::API;
use Win32::GUI 1.02;
# Some constants not defined in Win32::GUI
# These definitions will get inlined by the complier,
# and work with older versions of perl than 'use constant'
sub WM_NOTIFY {0x4E};
sub NM_CUSTOMDRAW {-12};
sub CDRF_NEWFONT{2};
sub CDRF_NOTIFYITEMDRAW {32};
sub CDDS_PREPAINT {1};
sub CDDS_ITEMPREPAINT {65537};
sub CLR_RED {0xFF};
sub CLR_GREEN {0x00FF00};
sub CLR_BLUE{0xFF};
sub CLR_WHITE {0xFF};
sub CLR_BLACK {0x00};
# Win32::API call that we want, defined the old way for maximum backwards
# compatability with Win32::API
my $CopyMemory = Win32::API-new(kernel32, RtlMoveMemory, NPI, V)
or die Can't find CopyMemory;
my $mw = Win32::GUI::Window-new(
-text = Colour ListView,
-size = [ 200, 200 ],
-pos = [ 200, 200 ],
);
sub mw_Terminate { return -1 }
my $lv = $mw-AddListView(
-pos = [ 0, 0 ],
-size = [ 190, 125 ],
);
$lv-InsertColumn(
-index = 0,
-text = Item,
);
$lv-ColumnWidth(0,180);
$lv-InsertItem(-text = One);
$lv-InsertItem(-text = Two);
$lv-InsertItem(-text = Three);
$lv-InsertItem(-text = Four);
$lv-TextColor(CLR_RED);
$lv-Hook(NM_CUSTOMDRAW, \lv_CustomDraw);
$mw-Show;
Win32::GUI::Dialog();
exit(0);
sub lv_CustomDraw
{
my ($object, $wParam, $lParam, $type, $msgcode) = @_;
return if $type != WM_NOTIFY;
return if $msgcode != NM_CUSTOMDRAW;
my ($dwDrawStage, $dwItemSpec)=
unpack(x12Ix20i, unpack(P40, pack(L,$lParam)));
if ($dwDrawStage==CDDS_PREPAINT) {
$object-Result(CDRF_NOTIFYITEMDRAW);
}
elsif ($dwDrawStage==CDDS_ITEMPREPAINT) {
my $clrText;
if($dwItemSpec==1) {
$clrText=pack(II,CLR_WHITE,CLR_BLUE);
}
elsif ($dwItemSpec==2) {
$clrText=pack(II,CLR_GREEN,CLR_BLACK);
}
else {
return;
}
$CopyMemory-Call($lParam+48, $clrText, 8);
$object-Result(CDRF_NEWFONT);
}
return 0; # return 0 essential, otherwise forced Result is ignored
}
__END__
Re: [win32gui] [perl-win32-gui-users] The window -backgroud option
That doesn't work here either, and I agree that it should. I raised a tracker for this one too: 1236283 Rob. Jeremy White wrote: Can anyone remember if this has ever worked? Looking at the options logic within Win32-GUI you should be able to do: my $win = new Win32::GUI::Window( -name= WinMain, -pos = [100, 100], -size = [100, 100], -background = [0,255,0], ); Which would set the background to green - but it doesn't... Cheers, jez. --- This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual core and dual graphics technology at this free one hour event hosted by HP, AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar ___ Perl-Win32-GUI-Users mailing list Perl-Win32-GUI-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
Re: [win32gui] [perl-win32-gui-users] DragDrop Functionality?
Jason, The XS changes that are required are in Win32::GUI (and have been for some time), and that package seems to work fine for me in the quick test I just did (Win98, Perl 5.8.7, Win32::GUI 1.02). I'll put adding the required functions on the TODO list, as it would be nice to get rid of the dependency on Win32::API. No promises of timescales though. Rob. Jason P. wrote: I know there is an old patch available to add DragDrop http://user.bahnhof.se/%7Ejohanl/perl/Win32GUI/DragDrop.pmcapabilites to Win32::GUI, however it is OUTDATED as all, well, u get the point. Has it been considered for integration with the main package as of yet? Jason. --- This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual core and dual graphics technology at this free one hour event hosted by HP, AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar ___ Perl-Win32-GUI-Users mailing list Perl-Win32-GUI-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
Re: [perl-win32-gui-users] listview text color
Glenn W Munroe wrote: Rob, No problem adding it as a sample. When I posted this, it was a little tongue in cheek, as the RtlMoveMemory API call is a tremendous kludge, but I couldn't figure any way to do it with pure perl. Then again, if it *is* the only way, then I guess it also qualifies as a useful technique! Cheers, Glenn Glenn, In my excitement at having a working CUSTOMDRAW example, I overlooked this. I suspect that we shouldn't have samples that depends on Win32::API. I'll write an example that use a control that doesn't require writing back into the structure. Like you, I can't think of a way to poke the values back in pure perl (perhaps this is a good reason to implement the NM_CUSTOMDRAW handler XS side?). If anyone knows of a way, then suggestions welcome. Rob. [code example for customdraw listview snipped]
Re: [win32gui] [perl-win32-gui-users] RichEdit-Text or -GetSelText loses Unicode
Dan,
$re-Text() behind the scenes calls the win32api GetWindowText API,
which in turn sends a WM_GETTEXT message to the richedit control. As far
as I can see there is no Unicode version of GetWindowText.. You
actually need to send a EM_GETTEXTEX message (see msdn for more
information). This message can be set to get the text in unicode
(UCS-2) and that then needs to be converted to perl characters.
As Win32::GUI does not support the EM_GETTEXTEX message, calling it is
somewhat tricky, but the following seems to work here. If you'd like
native support for EM_GETTEXTEX, then please raise a RFC.
Regards,
Rob.
#! perl -w
use strict;
use warnings;
use Win32::GUI;
# constants:
sub WM_USER() {1024};
sub EM_GETTEXTEX() {+WM_USER+94};
sub GT_DEFAULT() {0};
my $w = Win32::GUI::Window-new(
-name = 'Main',
-size = [800, 600],
);
my $re = $w-AddRichEdit(
-size = [600, 400],
);
$w-AddButton(
-name = 'btnChange',
-pos = [600, 500],
-text = '$re-Text($re-Text)',
);
my $rtf_prolog = '{\rtf1\ansi\deff0
{\fonttbl{\f0 \fcharset1\fnil Times New Roman;}}
{\stylesheet {\*\cs0 \additive Default Paragraph Font;}}';
$re-Text($rtf_prolog . 'This, \u305?, is not exactly the letter i' . '}');
$w-Show();
Win32::GUI::Dialog();
exit(0);
sub btnChange_Click {
my $text1 = $re-Text();
my $maxlen = 1024;
my $buffer = x $maxlen;
my $flags = GT_DEFAULT;
my $codepage = 1200;
my $struct = pack(LLIpp, $maxlen, $flags, $codepage, undef, undef);
my $address = pack(P20, $struct);
my $wparam = unpack(L, $address);
my $numTchar = $re-SendMessage(EM_GETTEXTEX, $wparam, $buffer);
my $octets = substr($buffer, 0, ($numTchar*2));
use Encode qw/decode/;
my $text2 = decode(UCS-2LE, $octets);
print --$text1--\n;
print --$text2--\n;
return 1;
}
__END__
Dan Dascalescu wrote:
I'm trying to get a useful Perl representation of the Unicode string
edited by the user in a RichEdit. It turned out that if I use
$RichEdit-Text, some Unicode characters are corrupted (transformed to
Latin equivalents). The same happens for GetSelText.
In other words, $RichEdit-Text($RichEdit-Text) corrupts the text!
I looked in RichEdit.xs, then at
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/commctls/richedit/richeditcontrols/richeditcontrolreference/richeditmessages/em_setoptions.asp
, but I couldn't figure out a fix.
So is there a way to retrieve the intact Unicode content of a RichEdit?
The code below demonstrates the problem (should I submit it as a bug?).
Or, is there a way to retrieve the RTF behind the RichEdit, other than
by doing a Save and reading the file?
Thanks,
Dan
#! perl -w
use strict;
use Win32::GUI;
my $w = Win32::GUI::Window-new(
-name = 'Main',
-size = [800, 600],
);
my $re = $w-AddRichEdit(
-size = [600, 400],
);
$w-AddButton(
-name = 'btnChange',
-pos = [600, 500],
-text = '$re-Text($re-Text)',
);
my $rtf_prolog = '{\rtf1\ansi\deff0
{\fonttbl{\f0 \fcharset1\fnil Times New Roman;}}
{\stylesheet {\*\cs0 \additive Default Paragraph Font;}}';
$re-Text($rtf_prolog . 'This, \u305?, is not exactly the letter i' . '}');
sub btnChange_Click {
$re-Text($re-Text);
}
$w-Show;
Win32::GUI::Dialog();
sub Main_Terminate {
-1;
}
---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492opÌk
___
Perl-Win32-GUI-Users mailing list
Perl-Win32-GUI-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
Re: [perl-win32-gui-users] RichEdit-Text or -GetSelText loses Unicode
Glenn Linderman wrote:
Hi Rob,
I've been trying for a year to get some form of Unicode support into
Win32::GUi, and you did it in an afternoon! (it seems)
I was aware that you had been looking at this, but hadn't realised the
scope: I though that you were looking for a 'full' unicode build.
Congratulations, you must know a bunch more about the Windows API
than I ever did (or ever want to, but gradually I'm being sucked in).
Probably not, but I'm a good reader, and have plenty of experience of
interpreting other peoples documents. I think you need a particular
mindset to get anywhere with the MDSN documentation :-).
My failed attempts were firstly to compile with __UNICODE__ (or some
such #define)
-DUNICODEIIRC
turned on, which did nothing... my second attempt showed more promise:
to define a Window class using a Unicode class name, which seems to be
the official way of getting controls to use Unicode within such Windows.
Do you have a reference to this 'official' way of doing it, as I have
not seen this.
This second attempt ran into the problem that UCS2 Unicode (used by
Windows) has all those interspersed NUL characters, and Win32::GUI has
lots of code that infers lengths by looking for the single-byte NUL
character...
Right. You can't just compile with -DUNICODE and expect it all to work,
unless it was written right to start with. If we want to be able to do
this, then we'll need to trawl the code and replace all type definitions
for strings and characters with TCHAR and LPTSTR definitions (etc.).
Also we'll need to do a trawl and correct any pointer arithmetic for
that it can work in both ANSI and UNICODE worlds.
and then Perl Unicode support being UTF8, the single-byte NUL
character still works, although it is inefficient to keep
recalculating lengths... and then I haven't yet found an XS-callable
API to convert from UCS2 to UTF8...
There are some helper functions/macros in ...Perl/Core/Win32.h, but I
haven't looked at how they would get used yet. They wrap the win32api
WideCharToMultiByte and MultiByteToWideChar functions.
I suppose one could call back to Perl's Encode module, but that seems
inefficient to do in as many places as one would have to do it...
I believe that there are specific perlapi functions to do this. I think
it was perldoc perlapi where I was looking at this.
For my needs, I can keep most of the interfaces in English. I only
need to input/output Unicode text via (1) the filesystem (2) a text
string editing window (Textfield or RichEdit). So the code you posted
might enable everything I _need_...
(1) is handled by perlIO, and is quite well documented.
(2) I've attached below what I hope is enough for you (and anyone else)
to achieve this with a Richedit control.
I'll be playing with the code you posted, and hoping that you can
follow through with somewhat more official support in Win32::GUI.
I'll be glad to help as I can with testing, but -- I'll email you
off-list to discuss this more.
I'm afraid that Unicode support isn't high on my list of priorities, but
I've added it to the list. I think full support in Win32::GUI will be
significant work, as it wasn't written for this in the first place. I
hope to be proven wrong.
I'll open this tracker in response to the email below. Perhaps it
should be generalized to other controls containing text, such as
ListBox, ComboBox, etc., if that is possible. I've already
generalized it to Textfield ... thinking that it should be about the
same support for Textfield and RichEdit, and maybe even easier for
Textfield... and Textfield doesn't have the extra formatting baggage
that RichEdit does, so could be simpler to use for simple text entry
work.
Sadly, I think that doing this with anything other that RichEdit will
require the changes I mention above. With RichEdit, we're fortunate to
have an API that allows us to get the contents in whatever codepage we
want, but the same is not true for the other controls.
Have a play with this.
Regards,
Rob.
#! perl -w
use strict;
use warnings;
use Win32::GUI;
my $w = Win32::GUI::Window-new(
-name = 'Main',
-size = [800, 600],
);
my $re = $w-AddRichEdit(
-size = [600, 400],
);
$w-AddButton(
-name = 'btnChange',
-pos = [600, 500],
-text = '$re-TextEx($re-TextEx())',
);
# Unicode representations:
# U+0041 LATIN CAPITAL LETTER
# U+00ED LATIN SMALL LETTER I WITH ACUTE
# U+0131 LATIN SMALL LETTER DOTLESS I
# U+263A WHITE SMILING FACE # NOTE: smiling face displayed as box, due to font
not having this codepoint
my $init_text = A: \x{0041} These, \x{00ED}, \x{0131}, are not exactly the letter
i. \x{263A};
display_unicode_string($init_text);
$re-TextEx($init_text);
$w-Show();
Win32::GUI::Dialog();
exit(0);
sub btnChange_Click {
$re-TextEx(my $text = $re-TextEx());
display_unicode_string($text);
return 1;
}
# Print a perl
Re: [win32gui] [perl-win32-gui-users] RichEdit-Text or -GetSelText loses Unicode
Glenn Linderman wrote:
However, the code shown seems like it can't perform a round trip.
Right. I never implemented the return, as Dan's query was only for
getting the text out. I should have change the button label to reflect
this.
I haven't yet figured out the magic by which \u305? gets
translated to a dotless i
That's RTF magic.\u305? is an RFT escape, with the unicode
codepoint in decimal. The equivalent in a (interpolated) perl string is
\x{0131}
Could it be that one must bypass $re-Text( ... ) also, and use a
SendMessage call for that also?
See my recent post with code for doing the return trip, and eliminating
the need for the RTF magic.
Regards,
Rob.
[perl-win32-gui-users] Announce: Win32::GUI::SplashScreen
Win32::GUI::SplashScreen v0.01 has been released. Win32::GUI::SplashScreen is a module to make it exceedingly easy to add a Splash screen to your Win32::GUI application. Create your bitmap (or JPEG if you have Win32::GUI::DIBitmap available), and add 2 lines to your existing application. That's it. Download source or PPM (suitable for Perl 5.6 or 5.8) and view documentation at http://www.robmay.me.uk/ Download Source from CPAN. Feedback on bugs and enhancements welcome. Regards, Rob.
Re: [perl-win32-gui-users] Announce: Win32::GUI::SplashScreen
Sorry all - wrong link. That should be: http://www.robmay.me.uk/win32gui/ Robert May wrote: Win32::GUI::SplashScreen is a module to make it exceedingly easy to add a Splash screen to your Win32::GUI application. Create your bitmap (or JPEG if you have Win32::GUI::DIBitmap available), and add 2 lines to your existing application. That's it. Download source or PPM (suitable for Perl 5.6 or 5.8) and view documentation at http://www.robmay.me.uk/ Download Source from CPAN. Feedback on bugs and enhancements welcome. Regards, Rob. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ Perl-Win32-GUI-Users mailing list Perl-Win32-GUI-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
Re: [perl-win32-gui-users] Announce: Win32::GUI::SplashScreen
And finally . I've upped the version to V0.02 and fixed a bug I just found with selecting the directories o look for the splash image in. Also the bitmap shipped with the samples was corrupted. Apologies if you already downloaded it, should be fine now. Robert May wrote: Sorry all - wrong link. That should be: http://www.robmay.me.uk/win32gui/ Robert May wrote: Win32::GUI::SplashScreen is a module to make it exceedingly easy to add a Splash screen to your Win32::GUI application. Create your bitmap (or JPEG if you have Win32::GUI::DIBitmap available), and add 2 lines to your existing application. That's it. Download source or PPM (suitable for Perl 5.6 or 5.8) and view documentation at http://www.robmay.me.uk/ Download Source from CPAN. Feedback on bugs and enhancements welcome. Regards, Rob. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ Perl-Win32-GUI-Users mailing list Perl-Win32-GUI-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ Perl-Win32-GUI-Users mailing list Perl-Win32-GUI-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
Re: [win32gui] Re: [perl-win32-gui-users] RichEdit-Text or -GetSelText loses Unicode
The behaviour is marginally better (from a brief experiment) if you use
-class = RichEdit20A
(Richedit 2or 3 depending on your system) when creating the RichEdit
control. I couldn't see any immediate difference between that and
RichEdit20W. Put still not perfect.
By using the clipboard viewer it's possible to see that the correct
unicode chars are copied, and it looks like the paste is doing a
conversion back to ANSI code-page. Don't know how to solve that :-(
Rob.
Glenn Linderman wrote:
On approximately 7/17/2005 4:46 PM, came the following characters from
the keyboard of Glenn Linderman:
Playing. Results below.
Played some more. Discovered that pasting into the RichEdit window
from the character map works for most characters, but interestingly,
not for those below (and maybe others, I didn't try all of them, just
particular ones I know I need).
\x{2013} \x{2014} \x{201c}
Likely there is a Unicode - ANSI - Unicode conversion somewhere in
the paste path that doesn't get it right :( or isn't invertible or
something.
Re: [win32gui] [perl-win32-gui-users] System Tray problem after upgrade to v1.02 from v1.00
Daniel, Could you post a minimal example that exhibits this problem so that I can verify and track it down. I have played with with the TrackPopupMenu implementation in this release, but my testing didn't show any such problems. Also what Perl version, and what windows platform? Regards, Rob. Daniel Åkesson wrote: Well, Please check: http://www.perlmonks.org/?node_id=476373 to see my problem :) Thanks, Daniel --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492opÌk ___ Perl-Win32-GUI-Users mailing list Perl-Win32-GUI-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
Re: [win32gui] [perl-win32-gui-users] System Tray problem after upgrade to v1.02 from v1.00
Daniel Åkesson wrote:
my($x, $y) = Win32::GUI::GetCursorPos();
$mw_win32-TrackPopupMenu($systray_menu-{SystrayMenu}, $x, $y);
My most humble apologies. I've broken TrackPopupMenu() in a piece of
logic that I spent so long looking at that I was *sure* I had it
right. The fix is trivial, and I've put it into CVS. If you want to
build your own immediately I can send you a patch. If not try one of
these:
$mw_win32-TrackPopupMenu($systray_menu-{SystrayMenu});
will, as of V1.02, do the GetCursorPos() for you.
If you need backwards compatibility with earlier versions of Win32::GUI, then
$mw_win32-TrackPopupMenu($systray_menu-{SystrayMenu}, $x, $y, TPM_LEFTALIGN |
TPM_TOPALIGN | TPM_LEFTBUTTON );
should work in all cases. (I've broken the 3-parameter call variant)
I've raised a tracker: 1241830, so that there is visibility of the problem.
Does anyone think this is serious enough (as it breaks backwards compatibility)
to warrant thinking about another release?
Regards,
Rob.
[perl-win32-gui-users] Next release [Was: System Tray problem after upgrade to v1.02 from v1.00]
Glenn Linderman wrote: On approximately 7/20/2005 12:58 PM, came the following characters from the keyboard of Robert May: I've raised a tracker: 1241830, so that there is visibility of the problem. Does anyone think this is serious enough (as it breaks backwards compatibility) to warrant thinking about another release? Well, it certainly warrants thinking about one :) And you've already started thinking about one, or you wouldn't have written this! Indeed It has bitten Daniel, and may bite others. If we are planning another release in the near term (a month or so) I wouldn't think it is necessary to put one out now. But if we are not planning another release in the near term, then I would recommend doing one now to avoid problems for other people. I would have though that targeting a bug-fix only release for a month's time might be realistic. I'd like to get the following done: - fix as many of the trackers as possible - get all the current sample code to work properly - include all the examples from the tutorial (and check that they all work :-), fixing the tutorial as necessary - work on the test suite - get a semi-decent web-page up as our Homepage at SourceForge. If you do choose to make a new release, I am available to help with the builds for the next week, after that it gets uncertain for a while. Thanks for you offer, but I now have an all-dancing MSVC++6 environment, so am reasonably self-sufficient in this regard. Regards, Rob.
Re: [win32gui] RE: [perl-win32-gui-users] Next release [Was: System Tray problem after upgrade to v1.02 from v1.00]
Frazier, Joe Jr wrote:
I would have though that targeting a bug-fix only release for
a month's time might be realistic. I'd like to get the
following done:
- fix as many of the trackers as possible
- get all the current sample code to work properly
- include all the examples from the tutorial (and check that
they all work :-), fixing the tutorial as necessary
- work on the test suite
- get a semi-decent web-page up as our Homepage at SourceForge.
Hey, if possible, can someone come up with an example of using Win32::GUI with one or more background worker thread(s)?
Here's my threads example that I'm working on - funnily I was just
discussing it off-list.
#!perl -w
use strict;
use warnings;
use Win32::GUI;
use threads;
use Thread::Queue;
# Win32::GUI is not very thread friendly, so ensure the worker thread
# is created before you create any Win32::GUI objects
print Boss: Starting\n;
print Boss: creating queues\n;
my $qd = Thread::Queue-new();
my $qu = Thread::Queue-new();
print Boss: creating worker thread\n;
my $t = threads-new(\worker);
my $working = 0; # set by the boss when the worker is working
my $instruction = 1;
my $W = new Win32::GUI::Window (
-pos = [100,100],
-size = [200,200],
-name = MW,
) or die Creating main window;
$W-AddButton (
-text = Execute Thread,
-name = But1,
) or die Creating Button1;
# Timer is used to read results back from worker thread
$W-AddTimer( Tim1, 1000) or die Creating Timer;
$W-Show();
Win32::GUI::Dialog();
# tidy up
print Boss: Sending kill to worker\n;
$qd-enqueue(undef);
print Boss: About to wait for worker\n;
my $r = $t-join();
print Boss: worker completed after executing $r instructions\n;
exit(0);
sub But1_Click
{
$W-But1-Disable();
print Boss: Button Clicked: starting worker ($instruction)\n;
$qd-enqueue($instruction++);
$working = 1;
return 1;
}
sub MW_Terminate
{
if($working) {
print Boss: Can't exit while worker is working\n;
return 0;
}
return -1;
}
sub Tim1_Timer
{
#print Boss: timer went off\n;
if(my $val = $qu-dequeue_nb()) {
print Boss: worker finished instruction $val\n;
$W-But1-Enable();
$working=0;
}
return 1;
}
# The worker thread entry point
sub worker
{
print Worker: starting\n;
my $count = 0;
print Worker: waiting for instructions\n;
while(my $num = $qd-dequeue()) {
print Worker: got instruction $num\n;
$count++;
for my $i (0..5) {
print Worker:doing work ($i)\n;
sleep(1);
}
print Worker: Done instruction $num\n;
$qu-enqueue($num);
}
print Worker: Terminating after $count instructions\n;
return $count;
}
__END__
It wouldn't take much to turn it into a proper example. Does this seem like
the right way to do it?
Something I would like to see for example would be a list of sites in say a
Win32::GUI::Grid (or listview at worst case, if we want to not use extensions in the
examples) with one or more threads that periodically(using a 20 second timer for example)
connect to the sites and measure response times to populate another column on the Grid.
Interesting idea - again it wouldn't be very difficult
I have seen one or two examples on the list for using threads, but it would be
nice to have one in the core distribution.
Also, has anyone created a PPM for this release yet? If so, is it available on a repository, or only on the sourceforge site for download?
There's a PPM in the bribes repository
(http://www.bribes.org/perl/ppmdir.html#ap)
|ppm install http://www.bribes.org/perl/ppm/Win32-GUI.ppd
(I haven't tested it)
I am also in dialog with ActiveState, and it *should* get in their
repository on their next build cycle (which was supposed to be last
Tuesday night, but it doesn't look like it happened yet)
Rob.
|
Re:[perl-win32-gui-users] Help My GUI, please
[EMAIL PROTECTED] wrote: Thanks Steve; I've already downloaded the tutorial and it is incomplete. If you mean that parts 6-8 are missing, then they have not been written (yet?). If I remember correctly, it is replicated in CPAN and JEB. So they have been tried also. The material in JEB, dada, and CPAN which represents each of the GUI modules is in similar fashion incomplete, so that has also been tried. The examples contain deprecated features (see below) although this group and others have indicated that this may be addressed and solved in the future. I hope to review what's there for the v1.03 release, but we'll have to see when that happens, and what time I have available. I don't intend to write any more at the moment. If you have downloaded and installed the V1.02 PPM from sourceforge, then you have pretty much all the documentation that I am aware of existing installed in your ActiveState html documentation tree. You can also take a look at the samples that come with the source (although some of them are also suffering from a lack of maintenance). You can find them in C:\Perl\site\lib\Win32\GUI\demos (assuming standard ActiveState install). The archive for this list often turns up interesting stuff to: http://sourceforge.net/mail/?group_id=16572 how do I find out how to use it? I've read, looked at, downloaded all the documentation from www.dada.it, The documentation at Aldo's site is, sadly, woefully out of date. The documentation is not complete! Indeed, but we're (slowly) getting it better. If you (or anyone else) want to contribute, then we'd welcome any input. So I've looked at my MSVC++ 6.0 MSDN (never do that again) The MSDN documentation needs a particular mindset, but is the authoritative source for Win32 programming. and it seems that after all is said and done, the list (@_) of input values is passed to a binary - where I can't look. You can download the source from Sourceforge if you want to look into the 'binary'. Let's take an example. I wanted a ListBox with a scroll bar and a title/caption/name, or whatever. I used attributes I discovered from GUI.pm All the common options are documented in the Win32::GUI::Reference::Options documentation (See Win32-GUI-Reference-Options in your ActiveState documentation tree) for the scroll bar (-autovscroll and -vscroll) and I used attributes which really did work for a window (-caption, -title, -name) for a title, and none of it worked. It's more usual to create a top-level window, and put a Listview in it, than to add title and caption to a listview. But there was an example with a deprecated feature (-style =), -style has been deprecated in favour of -(add|push|rem|pop)style. This is (somewhat) documented in the Common options page. So, sigh, where do I get documentation and/or how do I help? Am I missing something (two weeks is really not a long time to learn language and GUI)? It certainly isn't. Many years of programming and I'm still learning. I hope that I'll have all the existing documentation up on Sourceforge within another week or so. Regards, Rob.
Re: [win32gui] [perl-win32-gui-users] Re: Perl-Win32-GUI-Users digest, Vol 1 #1074 - 5 msgs
[EMAIL PROTECTED] wrote:
I do have a concrete example (given below).
Behavior:
1. A window containing a list view w/caption and scroll bar is displayed.
No it's not. There's no scrollbars in your example.
2. On clicking the terminate ('X') in the list view I expect
that my list view terminate sub (ReportBox_Terminate) will be called.
Hmm. I've never seen anyone trying that combination of styles on a
child window. I'm pretty surprised it works at all. If you're looking
for an MDI (multiple-document interface) style application then you
should be investigating Win32::GUI::MDI. I've never used this, so can't
help. There's an example in the demos directory that I've already
pointed you at.
3. The ReportBox_Terminate subroutine is never called (the print statement
is not executed).
OK. I have *NO* idea what the expected behaviour would be for the
example you've given.
What should the event handler name be (object name_event name) so that
termination of the list box will cause the event handler to be invoked?
Why do you want to terminate the listbox?
#! /bin/perl
Surely not?
#! C:\Perl\bin\perl.exe -w
or something similar?
use Win32::GUI ( WS_BORDER # Exporter doesn't seem to correctly
, WS_CAPTION# export values given in GUI.pm
, WS_CHILD # @EXPORT = qw( );
, WS_SYSMENU,
, WS_VISIBLE
);# Thin binding to Win32 GUI
use Win32::GUI;
exports everything OK here.
use strict; # Strict checking pragma
good!
use integer;# Computations done using integer arithmetic
why?
use warnings;
excellent!
my $window;
my $ListBox;# Output report listing
sub MainWnCreate;
sub myWindow_Terminate;
sub ReportBox_Terminate;
#--
# MainWnCreate
#--
sub MainWnCreate{
$window = new Win32::GUI::Window(
-name = myWindow,
-title= VAX to PC Realignment,
-left = 300, #0
-top = 200, #0
-width= 320,
-height = 240,
);
$ListBox = $window-AddListbox(
-disabled = 0,
-name = ReportBox,
-pos = [ 100, 40 ],
-size = [ 100, 100 ],
-style = 1024 | WS_BORDER | WS_CAPTION | WS_SYSMENU,
As above, I've no idea what adding caption and sysmenu styles to a child
window does. What window style is 1024?
-title = Report,
-visible = 0
Not needed.
);
} ### MainWnCreate
sub myWindow_Terminate {
print myWindow_Terminate\n;
return -1;
} ### myWindow_Terminate
sub ReportBox_Terminate{
print ReportBox_Terminate\n;
return 1;
}
#--
# Main-
#--
MainWnCreate;
$window-Show();
$ListBox-Show();
Wouldn't be needed if you didn't set the visibility to 0 when creating
the control (child windows are not displayed unless their parents are
visible, hence Win32::GUI creates main windows with -visibility = 0 and
child windows with -visibility = 1 by default. Then you only need to
show/hide the main window.
Win32::GUI::Dialog();
How about this:
#!perl -w
use strict;
use warnings;
use Win32::GUI (); # Don't need any imports, as we don't use them
# Create the main window
my $window = new Win32::GUI::Window(
-name = myWindow,
-title= VAX to PC Realignment,
-pos = [300,200],
-size = [320,240],
);
# add a list box as a child of the main window,
# size it to fit the main window
$window-AddListbox(
-name = ReportBox,
-size = [ $window-ScaleWidth(),
$window-ScaleHeight() ],
);
# show the window, and enter the dialog phase
$window-Show();
Win32::GUI::Dialog();
# done
exit(0);
# on resize of main window, resize listbox to
# fill mainwindow
sub myWindow_Resize {
$window-ReportBox-Resize(
$window-ScaleWidth(),
$window-ScaleHeight(),
);
return 1;
}
# Terminate.
sub myWindow_Terminate {
return -1;
}
Re: [win32gui] [perl-win32-gui-users] RE: [SPAM] - Re: Readonly TextEdit redraw problem. [Was: otther thngs] - Bayesian Filter detected spam
OK, I think that I've narrowed it down. A readonly edit control sends
a WM_CTLCOLORSTATIC message before re-drawing, rather than a
WM_CTLCOLOREDIT message. In the former case the code sets the
background mode to TRANSPARENT, which I think it should not be doing for
an edit control - just not sure what the right change to fix it is :-)
I have also turned up an issue with the -noflicker option, where the
text completely disappears (try adding -noflicker = 1 to the window
creation of your script below). I suspect this is related.
I have raised 2 trackers for these issues:
https://sourceforge.net/tracker/index.php?func=detailaid=1246429group_id=16572atid=116572
https://sourceforge.net/tracker/index.php?func=detailaid=1246431group_id=16572atid=116572
Rob.
Lloyd, Steve wrote:
The following Code demonstrates the problem.
Instructions:
Run the code.
Click on the button.
Use the scroll bar to scroll up.
Notice that the text all runs together.
--
use strict;
use warnings;
use Win32::GUI;
my $MainTitle = Pauto Script Runner;
my $MainWidth=300;
my $MainHeight=300;
my $MainTop=300;
my $MainLeft=300;
our $MainWindow = new Win32::GUI::Window(
-name = MainWindow,
-text = $MainTitle,
-width = $MainWidth,
-height = $MainHeight,
-minsize = [175, 120],
-topmost = 1,
-top= $MainTop,
-left = $MainLeft,
);
our $Test=$MainWindow-AddTextfield(
-name = ABC,
-text = This is is a test ($MainWidth,$MainHeight)\r\n,
-readonly=1,
-multiline=1,
-top=0,
-left=0,
-width=$MainWidth,
-height=$MainHeight-60,
-vscroll=1,
-addstyle = 0x1000, #ES_WantReturn - allows the enter
key to work
);
$MainWindow-AddButton(
-name = MyButton,
-text = ClickMe,
-height = 20,
-pos = [$MainWidth-100,$MainHeight-57 ],
);
$MainWindow-Show();
Win32::GUI::Dialog();
sub MainWindow_Minimize {return 0;}
sub MainWindow_Maximize {return 0;}
sub MainWindow_Terminate {return -1;}
sub MyButton_Click{
my $now=localtime();
my $str=$now\r\nHello This is a test of the emergency broadcast
system and is only a test. Should this cause problems please report it
to the authorities.;
my $mstr=$strx10;
$Test-Append($mstr);
}
exit(0);
--
-Original Message-
From: Robert May [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 27, 2005 11:56 AM
To: Lloyd, Steve
Cc: perl-win32-gui-users@lists.sourceforge.net
Subject: [SPAM] - Re: Readonly TextEdit redraw problem. [Was: otther
thngs] - Bayesian Filter detected spam
Steve,
If you can post a short example that exhibits the behaviour on your
system, then I'd be happy to try it and see if I get the same behaviour
here.
Rob.
Lloyd, Steve wrote:
I have noticed that if scrolling in a Win32::GUI::Textfield set to
readonly does not refresh the text properly.. Has anyone else seen
this? It this something that could be fixed before the next release?
Steve
-Original Message-
From: [EMAIL PROTECTED] on behalf of
Robert May
Sent: Thu 7/21/2005 6:23 PM
To: Frazier, Joe Jr
Cc: perl-win32-gui-users@lists.sourceforge.net
Subject: [SPAM] - Re: [win32gui] RE: [perl-win32-gui-users] Next
release [Was: System Tray problem after upgrade to v1.02 from v1.00] -
Bayesian Filter detected spam
Frazier, Joe Jr wrote:
I would have though that targeting a bug-fix only release for
a month's time might be realistic. I'd like to get the
following done:
- fix as many of the trackers as possible
- get all the current sample code to work properly
- include all the examples from the tutorial (and check that
they all work :-), fixing the tutorial as necessary
- work on the test suite
- get a semi-decent web-page up as our Homepage at SourceForge.
Hey, if possible, can someone come up with an example of using
Win32::GUI with one or more background worker thread(s)?
Here's my threads example that I'm working on - funnily I was just
discussing it off-list.
#!perl -w
use strict;
use warnings;
use Win32::GUI;
use threads;
use Thread::Queue;
# Win32::GUI is not very thread friendly, so ensure the worker thread
# is created before you create any Win32::GUI objects print Boss:
Starting\n; print Boss: creating queues\n;
my $qd = Thread::Queue-new();
my $qu = Thread::Queue-new();
print Boss: creating worker thread\n;
my $t = threads-new(\worker);
my $working = 0; # set by the boss when the worker is working my
$instruction = 1;
my $W = new Win32::GUI::Window (
-pos = [100,100],
-size = [200,200],
-name = MW,
) or die Creating main window;
$W-AddButton (
-text = Execute Thread,
-name = But1,
) or die Creating Button1;
# Timer is used to read results back from worker thread $W-AddTimer(
Tim1, 1000) or die Creating Timer;
$W-Show
[perl-win32-gui-users] ANNOUNCE: New home on the web
I am pleased to announce that Win32::GUI has a new home on the web at: http://perl-win32-gui.sourceforge.net/ There you'll find links to all things Win32::GUI including the latest documentation. Problems/suggestions/corrections to the users mailing list please. Regards, Rob.
Re: [win32gui] Re[2]: [SPAM] - [perl-win32-gui-users] timer do not work - Email found in subject
Сергей Черниенко wrote:
LS Change
LS my $mw = Win32::GUI ...
LS To
LS our $mw = Win32::GUI ...
LS This will allow the timer subroutine to see the $mw object.
That'll make no difference. The subroutine can already see the
lexically scoped variable.
sub CheckDir_Timer {
$mw-Hide() if $mw-IsVisible();
$mw-Show() unless $mw-IsVisible();
return 1;
}
Check your logic here.
If your window is visible, you hide it, then on the next line you show
it again if it's hidden (which it is because you hide it on the previous
line)
try
sub CheckDir_Timer {
if ($mw-IsVisible()) {
$mw-Hide();
}
else {
$mw-Show();
}
return 1;
}
Regards,
Rob.
Re: [win32gui] Re[2]: [SPAM] - [perl-win32-gui-users] timer do not work - Email found in subject
Apologies for the duplication - I should read all my mail before
replying. Oh why can't mail user agents thread properly.
Rob.
Robert May wrote:
Сергей Черниенко wrote:
LS Change
LS my $mw = Win32::GUI ...
LS To
LS our $mw = Win32::GUI ...
LS This will allow the timer subroutine to see the $mw object.
That'll make no difference. The subroutine can already see the
lexically scoped variable.
sub CheckDir_Timer {
$mw-Hide() if $mw-IsVisible();
$mw-Show() unless $mw-IsVisible();
return 1;
}
Check your logic here.
If your window is visible, you hide it, then on the next line you show
it again if it's hidden (which it is because you hide it on the previous
line)
try
sub CheckDir_Timer {
if ($mw-IsVisible()) {
$mw-Hide();
}
else {
$mw-Show();
}
return 1;
}
Regards,
Rob.
---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492opлk
___
Perl-Win32-GUI-Users mailing list
Perl-Win32-GUI-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
Re:[perl-win32-gui-users] timer do not work
Сергей Черниенко wrote: But! Timer do not work as before though I declared $mw as our (not my) (Steve Lloyd advice) and corrected event handler. It's like that handler not executed at all. I have Win32-GUI 1.02, perl 5.8.6 and Windows98SE It works fine here using lexical variables, Win98SE, perl 5.8.7 and 5.6.1, Win98SE Do you have an example of it not working that you can share? Regards, Rob.
Re: [perl-win32-gui-users] Control for Displaying the contents of a text file?
Octavian Rasnita wrote:
my $content;
{
local $/;
open(FILE, $file_path);
open(FILE, $file_path) or die Failed to open $file_path: $!;
*always* check error conditions
$content = FILE;
close FILE;
}
Then insert the $content in the Win32::GUI control you want.
For a Textfield that would be
$textfield-Text($content);
undef $content; # unless you really want the text stored twice
The RichEdit control has a method to load itself from a file.
$richedit-Load($file_path);
[all untested]
Regards,
Rob.
- Original Message -
From: Mark Sutfin [EMAIL PROTECTED]
To: perl-win32-gui-users@lists.sourceforge.net
Sent: Wednesday, August 03, 2005 23:02 PM
Subject: [perl-win32-gui-users] Control for Displaying the contents of a
text file?
Hello,
Newbie has just started experimenting with Win32::GUI. Great stuff. I
see that GetOpenFileName() returns the file I selected from the dialog
box. Which control(s) might easily display the contents of this text
file? I was guessing textfield...? But did not see a method to assign
the content to the control...
TIA,
Mark
Re: [win32gui] RE: [perl-win32-gui-users] Control for Displaying the contents of a text file?
Mark Sutfin wrote: That's what I was asking...but did not see a method to assign the content to the control. Here's what I see available thru the docs.. * Constructor o new Win32::GUI::Textfield(PARENT, %OPTIONS) * Methods o LineFromChar(INDEX) o MaxLength([CHARS]) o Modified([FLAG]) o PasswordChar([CHAR]) o ReadOnly([FLAG]) o ReplaceSel(STRING, [FLAG]) o Select(START, END) o SelectAll() o Selection() o Undo() * Events o Change() o GotFocus() o LostFocus() Where are you looking for the documentation? That looks hideously out of date. Try Here: http://perl-win32-gui.sourceforge.net/docs/Win32/GUI/Textfield.html and see my previous post. [If you are using an old version of Win32::GUI I would thoroughly recommend upgrading to the lastest (v1.02), which some with a local set of documentation] Regards, Rob.
Re: [win32gui] RE: [perl-win32-gui-users] Control for Displaying the contents of a text file?
Mark Sutfin wrote:
I installed 1.02 (5.8.7). I still cannot locate the Text()
method in the Win32::GUI:Textfield entry.
Could it be that I'm so new to this, I didn't understand that
it's listed on the Common Methods entries?
You're absolutely correct.
Is there a beginners win32::gui list? ;)
This is the right place - the community it's big enough for lost of
lists (yet :-)
#!perl -w
use strict;
use warnings;
Always good to have as many warnings as possible
use Win32::GUI;
my $text = defined($ARGV[0]) ? $ARGV[0] : Hello, world;
my $main = Win32::GUI::Window-new(
-name = 'Main',
-text = 'Perl',
-width = 200,
-height = 200
);
my $sb = $main-AddStatusBar();
$sb-Text(This appears in the status bar);
my $font = Win32::GUI::Font-new(
-name = Comic Sans MS,
-size = 24,
);
my $label = $main-AddLabel(
-text = $text,
-font = $font,
-foreground = [255, 0, 0],
);
my $ncw = $main-Width() - $main-ScaleWidth();
my $nch = $main-Height() - $main-ScaleHeight();
my $w = $label-Width() + $ncw;
my $h = $label-Height() + $nch;
my $desk = Win32::GUI::GetDesktopWindow();
my $dw = Win32::GUI::Width($desk);
my $dh = Win32::GUI::Height($desk);
my $x = ($dw - $w) / 2;
my $y = ($dh - $h) / 2;
I think
$main-Center(Win32::GUI::GetDesktopWindow());
can replace all the code you have to calculate where the center is.
$main-Change(-minsize = [$w, $h]);
$main-Move($x, $y);
my $file_path = Win32::GUI::GetOpenFileName(
- directory = c:\\
);
my $content;
{
local $/;
open(FILE, $file_path) or die Failed to open $file_path: $!;
$content = FILE;
close FILE;
}
my $textstuff = Win32::GUI::Textfield-new($main, -multiline = 1);
You need to give the Textfield a size. It (helpfully) initialises with
width and height of 0. So it's there, but you can't see it.
Try
my $textstuff = $main-AddTextField(
-size = [100,100],
-multiline = 1,
-vscroll = 1,
);
$textstuff-Text($content);
undef $content;
$main-Show();
#Win32::GUI::Dialog();
Any reason you have your Dialog() call commented out?
sub Main_Terminate {
-1;
}
sub Main_Resize {
my $w = $main-ScaleWidth();
my $h = $main-ScaleHeight();
my $lw = $label-Width();
my $lh = $label-Height();
$label-Left(int(($w - $lw) / 2));
$label-Top(int(($h - $lh) / 2));
$sb-Move(0, $main-ScaleHeight - $sb-Height);
$sb-Resize($main-ScaleWidth, $sb-Height);
}
Regards,
Rob.
Re: [perl-win32-gui-users] Readonly TextEdit redraw problem
I've just put a fix for this into CVS.
Regards,
Rob.
Robert May wrote:
OK, I think that I've narrowed it down. A readonly edit control sends
a WM_CTLCOLORSTATIC message before re-drawing, rather than a
WM_CTLCOLOREDIT message. In the former case the code sets the
background mode to TRANSPARENT, which I think it should not be doing for
an edit control - just not sure what the right change to fix it is :-)
I have also turned up an issue with the -noflicker option, where the
text completely disappears (try adding -noflicker = 1 to the window
creation of your script below). I suspect this is related.
I have raised 2 trackers for these issues:
https://sourceforge.net/tracker/index.php?func=detailaid=1246429group_id=16572atid=116572
https://sourceforge.net/tracker/index.php?func=detailaid=1246431group_id=16572atid=116572
Rob.
Lloyd, Steve wrote:
The following Code demonstrates the problem.
Instructions:
Run the code.
Click on the button.
Use the scroll bar to scroll up.
Notice that the text all runs together.
--
use strict;
use warnings;
use Win32::GUI;
my $MainTitle = Pauto Script Runner;
my $MainWidth=300;
my $MainHeight=300;
my $MainTop=300;
my $MainLeft=300;
our $MainWindow = new Win32::GUI::Window(
-name = MainWindow,
-text = $MainTitle,
-width = $MainWidth,
-height= $MainHeight,
-minsize = [175, 120],
-topmost = 1,
-top= $MainTop,
-left= $MainLeft,
);
our $Test=$MainWindow-AddTextfield(
-name= ABC,
-text= This is is a test ($MainWidth,$MainHeight)\r\n,
-readonly=1,
-multiline=1,
-top=0,
-left=0,
-width=$MainWidth,
-height=$MainHeight-60,
-vscroll=1,
-addstyle = 0x1000, #ES_WantReturn - allows the enter
key to work
);
$MainWindow-AddButton(
-name = MyButton,
-text = ClickMe,
-height = 20,
-pos = [$MainWidth-100,$MainHeight-57 ],
);
$MainWindow-Show();
Win32::GUI::Dialog();
sub MainWindow_Minimize {return 0;}
sub MainWindow_Maximize {return 0;}
sub MainWindow_Terminate {return -1;}
sub MyButton_Click{
my $now=localtime();
my $str=$now\r\nHello This is a test of the emergency broadcast
system and is only a test. Should this cause problems please report it
to the authorities.;
my $mstr=$strx10;
$Test-Append($mstr);
}
exit(0);
--
-Original Message-
From: Robert May [mailto:[EMAIL PROTECTED] Sent: Wednesday,
July 27, 2005 11:56 AM
To: Lloyd, Steve
Cc: perl-win32-gui-users@lists.sourceforge.net
Subject: [SPAM] - Re: Readonly TextEdit redraw problem. [Was: otther
thngs] - Bayesian Filter detected spam
Steve,
If you can post a short example that exhibits the behaviour on your
system, then I'd be happy to try it and see if I get the same
behaviour here.
Rob.
Lloyd, Steve wrote:
I have noticed that if scrolling in a Win32::GUI::Textfield set to
readonly does not refresh the text properly.. Has anyone else seen
this? It this something that could be fixed before the next release?
Steve
-Original Message-
From: [EMAIL PROTECTED] on behalf of
Robert May
Sent: Thu 7/21/2005 6:23 PM
To: Frazier, Joe Jr
Cc: perl-win32-gui-users@lists.sourceforge.net
Subject: [SPAM] - Re: [win32gui] RE: [perl-win32-gui-users] Next
release [Was: System Tray problem after upgrade to v1.02 from v1.00] -
Bayesian Filter detected spam
Frazier, Joe Jr wrote:
I would have though that targeting a bug-fix only release for
a month's time might be realistic. I'd like to get the following
done:
- fix as many of the trackers as possible
- get all the current sample code to work properly
- include all the examples from the tutorial (and check that they
all work :-), fixing the tutorial as necessary
- work on the test suite
- get a semi-decent web-page up as our Homepage at SourceForge.
Hey, if possible, can someone come up with an example of using
Win32::GUI with one or more background worker thread(s)?
Here's my threads example that I'm working on - funnily I was just
discussing it off-list.
#!perl -w
use strict;
use warnings;
use Win32::GUI;
use threads;
use Thread::Queue;
# Win32::GUI is not very thread friendly, so ensure the worker thread
# is created before you create any Win32::GUI objects print Boss:
Starting\n; print Boss: creating queues\n;
my $qd = Thread::Queue-new();
my $qu = Thread::Queue-new();
print Boss: creating worker thread\n;
my $t = threads-new(\worker);
my $working = 0; # set by the boss when the worker is working my
$instruction = 1;
my $W = new Win32::GUI::Window (
-pos = [100,100],
-size = [200,200],
-name = MW,
) or die Creating main window;
$W-AddButton (
-text = Execute Thread,
-name = But1,
) or die Creating Button1;
# Timer is used to read results back from worker thread $W-AddTimer(
Tim1, 1000) or die Creating Timer;
$W-Show();
Win32::GUI::Dialog();
# tidy up
[perl-win32-gui-users] Mixing OEM and NEM events [Was: working/not working timer]
Сергей Черниенко wrote: [ snipped timer-related stuff ] And does it mean that OEM and NEM can not be mixed? By default a window/control uses the Original/Old Event Model (OEM), where the sub that is called is the -name of the window/control followed by '_' followed by the event name itself. (So for a control with -name = 'ABC', the click event sub is ABC_Click. This sub must be located in package main (the default package). As soon as any New Event Model (NEM) option is given to the constructor, Win32::GUI turns off all OEM subroutine calls. Using NEM allows us to use any sub name we want, from any package. We can event use anonymous subs. If you really want to have both OEM and NEM callbacks existing at the same time, then you can pass -eventmodel = 'both' to the window/control's constructor (other allowed values are 'byname' to force OEM, and 'byref' to force NEM). If you have both event models enabled, then currently the NEM sub gets called first (but don't rely on this behaviour) Personally I find it very confusing having both enabled, and I would consider it 'best practice' to use one or the other. The NEM is far more powerful (and essential if you want to put different bits of your UI code into different packages), but I can see how anyone coming from VB would find the OEM more understandable. Hope this s useful. Rob.
[perl-win32-gui-users] MouseOver and MouseOut Events [Was: The window -backgroud option]
Lloyd, Steve wrote: Rob, Is there a planned date for the next release? Not really. Perhaps the end of the month would be a good target, but I have some travel, so may not get to do a whole lot more between now and then - lets see how things go. Also, many of the common events do not work on the main Window, right? Not that I'm aware of, but I haven't really looked. Like MouseOver and MouseOut... These I have looked at (some time ago) and there's a whole load of jiggery-pokery that surrounds these 2 events and getting them to fire for any window/control. Look on MSDN for WM_MOUSEHOVER, WM_MOUSELEAVE and TrackMouseEvent(). Rob.
[perl-win32-gui-users] gb109.zip
Сергей Черниенко wrote: Hello, perl-win32-gui-users, Can someone give live link to GUI Bulder written by David Hiltz? It's impossible to download it from ftp://ftp.wh.whoi.edu/pub Thanks! ftp://ftp.wh.whoi.edu/pub/gb109.zip works fine from here. I also turned up some stuff on the old mailing list - but this looks very old: http://www.mail-archive.com/[EMAIL PROTECTED]/msg00718.html Have you looked at The GUI Loft? http://user.bahnhof.se/~johanl/perl/Loft/ Regards, Rob.
Re: [win32gui] [perl-win32-gui-users] (no subject)
Сергей Черниенко wrote: Здравствуйте, perl-win32-gui-users, I'm using NotifyIcon object to minimze my app to tray. All works fine but the icon in tray has grey color instead of its real purple. The questions are: 1. What format has to have icon (size, number of colors and so on) From: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/shell/reference/structures/notifyicondata.asp To avoid icon distortion, be aware that notification area icons have different levels of support under different versions of Microsoft Windows. Windows 95, Windows 98, and Microsoft Windows NT 4.0 support icons of up to 4 bits per pixel (BPP). Windows Millennium Edition (Windows Me) and Windows 2000 support icons of a color depth up to the current display mode. Windows XP supports icons of up to 32 BPP. 2. may be I need redraw icon in some way? If yes: how can I do this? Shouldn't be necessary. 3. Where can I find docs about NotifyIcon on microsoft site? Start here: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/shell/reference/functions/shell_notifyicon.asp Regards, Rob.
RE: [perl-win32-gui-users] DC used for customdrawn Toolbar
Kind, Uwe wrote:
Just so I understand what you are trying to do. Do you mean the change in
the menu colour (to blue) when the mouse moves over the menu buttons
I want to 'grey out' the text when $mw loses the focus.
The structures used by a toolbar and header are different
This appears to be key. It looks like the toolbar that uses the new
NMTBCUSTOMDRAW structure (comctl32.dll 4.70) ignores colors you set in
the DC. This behaviour is documented for ListViews ... but it appears
not for toolbars.
Setting the clrText member of the new structure seems to work a treat.
I've tucked this code away to add to Coolbar.pm when I next get back to it.
Regards,
Rob.
#!perl -w
use strict;
use warnings;
use Win32::GUI 1.02;
use Win32::API;
sub I_IMAGENONE() {-2};
sub NM_CUSTOMDRAW() {-12};
sub WM_NOTIFY() {0x4E};
sub CDDS_PREPAINT() {1};
sub CDDS_ITEMPREPAINT() {65537};
sub CDRF_NOTIFYITEMDRAW() {32};
sub CDRF_DODEFAULT() {0};
sub CDRF_NEWFONT(){2};
sub RDW_INVALIDATE() {1};
# Win32::API call that we want, defined the old way for maximum
# backwards compatability with Win32::API
my $CopyMemory =
Win32::API-new(kernel32, RtlMoveMemory, NPI, V)
or die Can't find CopyMemory;
my $mw = Win32::GUI::Window-new(
-name = 'MainWindow',
-text = 'CustomDraw',
-pos = [ 100, 100 ],
-size = [ 300, 350 ],
-onActivate =
sub { $_[0]-Toolbar-Redraw(RDW_INVALIDATE); return 1; },
-onDeactivate =
sub { $_[0]-Toolbar-Redraw(RDW_INVALIDATE); return 1; },
-onTerminate = sub { -1 },
);
my $tb = $mw - AddToolbar(
-name = 'Toolbar',
-nodivider = 1,
-flat = 1,
-list = 1,
);
for ( 0 .. 3 )
{
$tb-AddString(Test $_);
$tb-AddButtons( 1,
I_IMAGENONE,
1000 + $_,
TBSTATE_ENABLED,
TBSTYLE_AUTOSIZE|TBSTYLE_BUTTON|BTNS_SHOWTEXT,
$_ );
}
$tb - Hook ( NM_CUSTOMDRAW, \onCustumDraw );
$mw-Show();
Win32::GUI::Dialog();
exit(0);
sub onCustumDraw
{
my ($object, $wparam, $lparam, $message_type, $message_code ) = @_;
return unless $message_type == WM_NOTIFY;
return unless $message_code == NM_CUSTOMDRAW;
my $pNMTBCD = pack ( 'L!', $lparam );
my $sNMTBCD = unpack( 'P20', $pNMTBCD );
my ($dwDrawStage, $dc ) = unpack ( 'x12IL', $sNMTBCD );
if ( $dwDrawStage == CDDS_PREPAINT ) {
$object-Result(CDRF_NOTIFYITEMDRAW);
}
elsif ($dwDrawStage==CDDS_ITEMPREPAINT) {
if($mw-{-handle} != Win32::GUI::GetForegroundWindow()) {
my $clrText=pack(I,0x808080);
$CopyMemory-Call($lparam+60, $clrText, 4);
}
$object-Result(CDRF_DODEFAULT);
}
else {
$object-Result(CDRF_DODEFAULT);
}
return 0;
}
Re: [perl-win32-gui-users] Trapping ctl- and function keys and invalidating windows
[EMAIL PROTECTED] wrote: Any way to trap control key and function key entries without a dialog window? I'd like to be able to associate functions to keys so that someone can invoke a function by pressing a key, primariliy for debugging. I don't want a submenu. You should investigate Win32::GUI::AcceleratorTable class or look at using the Win32::GUI::Hook() function to catch WM_KEYDOWN Any way of detecting when a window needs to be invalidated? Not sure I understand you. The system automatically invalidates parts of the client window that need redrawing, or your program can invalidate parts that it knows need redrawing. Invalidated regions are re-drawn the next time the window processes a WM_PAINT message - but all this happens in the background. If you can provide a better idea of what you are trying to do (and what doesn't work for you) then we may be able to point you in the right direction. Regards, Rob.
Re: [win32gui] [perl-win32-gui-users] {Spam?} MDIFrame and background Image
Apologies if this is a repeat post, but I did not see the first one come
back from the reflector. I've made the included image a whole lot
smaller in case that was the problem.
Rob.
Robert May wrote:
Daniel Fernandez wrote:
Hello, perl-win32-gui-users,
Anybody knows if it's possible to display a background bitmap image
in a MDIFrame? If it's possible, I will appreciate a short example .
Here's one way of doing it with a regular window. You should be able to
adjust this to work with an MDI frame. (Sorry about the big image)
Regards,
Rob.
#!perl -w
use strict;
use warnings;
use Win32::GUI;
use Win32::GUI::BitmapInline();
# Load our bitmap
#my $bm = Win32::GUI::Bitmap-new(sail.bmp) or die Creating Bitmap;
my $bm = get_bitmap();
# Store the width and height, as we'll use them a lot
my($bmw, $bmh) = ($bm-Info())[0..1];
# create a class without a background brush: this prevents
# defWindowProc erasing the window background, as we want to
# paint it ourselves to avoid flicker
my $class = Win32::GUI::Class-new(
-name = 'noflicker',
-brush = 0,
);
# create a window, using our class. Add style WS_CLIPCHILDEN
# so that any child windows are automatically masked out of
# our window's DC, and then we don't need to worry about drawing
# over them
my $mw = Win32::GUI::Window-new(
-name = ImgWindow,
-title = Background Image,
-pos = [100,100],
-size = [300,200],
-class = $class,
-addstyle = WS_CLIPCHILDREN,
-onPaint = \paint,
-onTerminate = sub {-1},
);
$mw-AddButton(
-name = Button,
-pos = [20,20],
-text = Example Child Window,
);
# Create a memory DC, compatible with our window's
# DC, containing our bitmap. Do this once, here, to speed
# up the painting routine. Use a local block, so that $dc
# goes out of scope, and $dc gets released (could call
# $dc-ReleaseDC() instead).
my $memDC;
{
my $dc = $mw-GetDC();
$memDC = $dc-CreateCompatibleDC();
$memDC-SelectObject($bm);
}
# We need a brush to paint the window background
# with, select a grey one. We don't need to worry
# about freeing stock objects when we're done with them
my $bkBrush = Win32::GUI::GetStockObject(1);
# Show the window and enter the dialog phase.
$mw-Show();
Win32::GUI::Dialog();
exit(0);
# Our window painting routine. To avoid flicker we will
# paint the whole of the window, taking care not to draw any
# pixel more than once.
sub paint
{
my($window, $dc) = @_;
# I will add StretchBlt to the next release so that we can stretch the
# image to fit the window, but it's not there right now.
#$dc-StretchBlt(0, 0, ($window-GetClientRect())[2..3], $memDC, 0, 0,
$bmw, $bmh);
#calculate the image position to center it in the window
my ($ww, $wh) = ($window-GetClientRect())[2..3];
my $l = ($ww - $bmw)/2;
my $t = ($wh - $bmh)/2;
my $r = $l + $bmw;
my $b = $t + $bmh;
# copy the image from the memory DC to the window's DC
$dc-BitBlt($l, $t, $bmw, $bmh, $memDC, 0, 0);
# fill the spaces around the image with our background brush.
# We should probably not draw when it is not necessary (i.e. when
# the image meets the side(s), but we can get away with not checking,
# as the DC is always clipped to the window's client rect.
$dc-FillRect(0, 0, $ww, $t, $bkBrush);
$dc-FillRect(0, $b, $ww, $wh, $bkBrush);
$dc-FillRect(0, $t, $l, $b, $bkBrush);
$dc-FillRect($r, $t, $ww, $b, $bkBrush);
# We've drawn the background, so inform windows that there is nothing
left
# to draw.
$dc-Validate();
# we've processed the message, so return 0.
return 0;
}
sub get_bitmap
{
return Win32::GUI::BitmapInline-new( q(
Qk1gMQAAADYEAAAooG4BAAgAAQAAACotAAATCwAAEwsBAQAAADEx
AAA5OQAhOTkAKTk5ADk5OQAAQkIAGEJCACFCQgApQkIAMUJCADlCQgBCQkIAAEpKAAhKSgAQSkoA
GEpKACFKSgApSkoAMUpKADlKSgBCSkoAAFJSAAhSUgAQUlIAGFJSACFSUgApUlIAMVJSADlSUgBC
UlIASlJSAABaWgAIWloAEFpaABhaWgAhWloAKVpaADFaWgA5WloAQlpaAEpaWgBSWloAAGNjAAhj
YwAQY2MAGGNjACFjYwApY2MAMWNjADljYwBCY2MASmNjAFJjYwBaY2MAAGtrAAhrawAQa2sAGGtr
ACFrawApa2sAMWtrADlrawBCa2sASmtrAFJrawBaa2sAY2trAABzcwAIc3MAEHNzABhzcwAxc3MA
OXNzAEJzcwBKc3MAUnNzAFpzcwBjc3MAa3NzAAB7ewAIe3sAEHt7ADl7ewBCe3sASnt7AFJ7ewBa
e3sAY3t7AGt7ewBze3sAe3t7AACEhAAIhIQASoSEAFKEhABahIQAY4SEAGuEhABzhIQAe4SEAISE
hAAAjIwAY4yMAGuMjABzjIwAe4yMAISMjACMjIwAe5SUAISUlACMlJQAlJSUAHucnACEnJwAjJyc
AJScnACcnJwAjKWlAJSlpQCcpaUApaWlAJytrQClra0Ara2tAKW1tQCttbUAtbW1AK29vQC1vb0A
vb29ALXGxgC9xsYAxs7OAMbW1gDO1tYAc97eAHve3gCE3t4Azt7eAHPn5wB75+cAhOfnAIzn5wCU
5+cAnOfnAKXn5wBK7+8AUu/vAFrv7wBj7+8Aa+/vAHPv7wB77+8AhO/vAIzv7wCU7+8AnO/vAKXv
7wCt7+8AY/f3AGv39wBz9/cAe/f3AIT39wCM9/cAlPf3AJz39wCl9/cArff3ALX39wC99/cAY///
AGv//wBz//8Ae///AIT//wCM//8AlP//AJz//wCl//8Arf//ALX//wC9//8Axv//AM7//wDW//8A
3v//AOf//wDv//8A9///AP///wD///8AAP///wD///8AAP
Re: [win32gui] [perl-win32-gui-users] {Spam?} MDIFrame and background Image
Daniel Fernandez wrote:
Hello, perl-win32-gui-users,
Anybody knows if it's possible to display a background bitmap image in
a MDIFrame? If it's possible, I will appreciate a short example .
Here's one way of doing it with a regular window. You should be able to
adjust this to work with an MDI frame. (Sorry about the big image)
Regards,
Rob.
#!perl -w
use strict;
use warnings;
use Win32::GUI;
use Win32::GUI::BitmapInline();
# Load our bitmap
#my $bm = Win32::GUI::Bitmap-new(sail.bmp) or die Creating Bitmap;
my $bm = get_bitmap();
# Store the width and height, as we'll use them a lot
my($bmw, $bmh) = ($bm-Info())[0..1];
# create a class without a background brush: this prevents
# defWindowProc erasing the window background, as we want to
# paint it ourselves to avoid flicker
my $class = Win32::GUI::Class-new(
-name = 'noflicker',
-brush = 0,
);
# create a window, using our class. Add style WS_CLIPCHILDEN
# so that any child windows are automatically masked out of
# our window's DC, and then we don't need to worry about drawing
# over them
my $mw = Win32::GUI::Window-new(
-name = ImgWindow,
-title = Background Image,
-pos = [100,100],
-size = [550,450],
-class = $class,
-addstyle = WS_CLIPCHILDREN,
-onPaint = \paint,
-onTerminate = sub {-1},
);
$mw-AddButton(
-name = Button,
-pos = [100,100],
-text = Example Child Window,
);
# Create a memory DC, compatible with our window's
# DC, containing our bitmap. Do this once, here, to speed
# up the painting routine. Use a local block, so that $dc
# goes out of scope, and $dc gets released (could call
# $dc-ReleaseDC() instead).
my $memDC;
{
my $dc = $mw-GetDC();
$memDC = $dc-CreateCompatibleDC();
$memDC-SelectObject($bm);
}
# We need a brush to paint the window background
# with, select a grey one. We don't need to worry
# about freeing stock objects when we're done with them
my $bkBrush = Win32::GUI::GetStockObject(1);
# Show the window and enter the dialog phase.
$mw-Show();
Win32::GUI::Dialog();
exit(0);
# Our window painting routine. To avoid flicker we will
# paint the whole of the window, taking care not to draw any
# pixel more than once.
sub paint
{
my($window, $dc) = @_;
# I will add StretchBlt to the next release so that we can stretch the
# image to fit the window, but it's not there right now.
#$dc-StretchBlt(0, 0, ($window-GetClientRect())[2..3], $memDC, 0, 0,
$bmw, $bmh);
#calculate the image position to center it in the window
my ($ww, $wh) = ($window-GetClientRect())[2..3];
my $l = ($ww - $bmw)/2;
my $t = ($wh - $bmh)/2;
my $r = $l + $bmw;
my $b = $t + $bmh;
# copy the image from the memory DC to the window's DC
$dc-BitBlt($l, $t, $bmw, $bmh, $memDC, 0, 0);
# fill the spaces around the image with our background brush.
# We should probably not draw when it is not necessary (i.e. when
# the image meets the side(s), but we can get away with not checking,
# as the DC is always clipped to the window's client rect.
$dc-FillRect(0, 0, $ww, $t, $bkBrush);
$dc-FillRect(0, $b, $ww, $wh, $bkBrush);
$dc-FillRect(0, $t, $l, $b, $bkBrush);
$dc-FillRect($r, $t, $ww, $b, $bkBrush);
# We've drawn the background, so inform windows that there is nothing
left
# to draw.
$dc-Validate();
# we've processed the message, so return 0.
return 0;
}
sub get_bitmap
{
return Win32::GUI::BitmapInline-new( q(
Qk1mpgIAADYEAAAo4AEAAJQBAAABAAgAAQAAADCiAgATCwAAEwsBAQAA
AAEBAQACAgIAAwMDAAQEBAAFBQUABgYGAAcHBwAICAgACQkJAAoKCgALCwsADAwMAA0NDQAODg4A
Dw8PABAQEAAREREAEhISABMTEwAUFBQAFRUVABYWFgAXFxcAGBgYABkZGQAaGhoAGxsbABwcHAAd
HR0AHh4eAB8fHwAgICAAISEhACIiIgAjIyMAJCQkACUlJQAmJiYAJycnACgoKAApKSkAKioqACsr
KwAsLCwALS0tAC4uLgAvLy8AMDAwADExMQAyMjIAMzMzADQ0NAA1NTUANjY2ADc3NwA4ODgAOTk5
ADo6OgA7OzsAPDw8AD09PQA+Pj4APz8/AEBAQABBQUEAQkJCAENDQwBEREQARUVFAEZGRgBHR0cA
SEhIAElJSQBKSkoAS0tLAExMTABNTU0ATk5OAE9PTwBQUFAAUVFRAFJSUgBTU1MAVFRUAFVVVQBW
VlYAV1dXAFhYWABZWVkAWlpaAFtbWwBcXFwAXV1dAF5eXgBfX18AYGBgAGFhYQBiYmIAY2NjAGRk
ZABlZWUAZmZmAGdnZwBoaGgAaWlpAGpqagBra2sAbGxsAG1tbQBubm4Ab29vAHBwcABxcXEAcnJy
AHNzcwB0dHQAdXV1AHZ2dgB3d3cAeHh4AHl5eQB6enoAe3t7AHx8fAB9fX0Afn5+AH9/fwCAgIAA
gYGBAIKCggCDg4MAhISEAIWFhQCGhoYAh4eHAIiIiACJiYkAioqKAIuLiwCMjIwAjY2NAI6OjgCP
j48AkJCQAJGRkQCSkpIAk5OTAJSUlACVlZUAlpaWAJeXlwCYmJgAmZmZAJqamgCbm5sAnJycAJ2d
nQCenp4An5+fAKCgoAChoaEAoqKiAKOjowCkpKQApaWlAKampgCnp6cAqKioAKmpqQCqqqoAq6ur
AKysrACtra0Arq6uAK+vrwCwsLAAsbGxALKysgCzs7MAtLS0ALW1tQC2trYAt7e3ALi4uAC5ubkA
urq6ALu7uwC8vLwAvb29AL6+vgC/v78AwMDAAMHBwQDCwsIAw8PDAMTExADFxcUAxsbGAMfHxwDI
yMgAycnJAMrKygDLy8sAzMzMAM3NzQDOzs4Az8/PANDQ0ADR0dEA0tLSANPT0wDU1NQA1dXVANbW
1gDX19cA2NjYANnZ2QDa2toA29vbANzc3ADd3d0A3t7eAN/f3wDg4OAA4eHhAOLi4gDj4+MA5OTk
[perl-win32-gui-users] Draggable 'window' [Was: MDIFrame and background Image]
Lloyd, Steve wrote: Is there a way using Win32::GUI to create a dragable child window that can be dragged and dropped onto another window like winspy does? Steve Are you referring to the 'Find' window from Windows Spy++? If so, then that's not a draggable window at all: the application changes the cursor, and captures the mouse (see SetCapture()) so that it gets mouse move events for the mouse outside it's window borders. It then hit-tests on each mouse move to find the handle to any window under the mouse, gets the window co-ordinates (GetWindowRect() on the handle found), and then draws the rectangle around the window by drawing into the 'DISPLAY' DC (See CreateDC). Of course, it may do it entirely differently, but that's how I would do it. Regards, Rob.
[perl-win32-gui-users] Re: [win32gui] {Spam?} Re: MDIFrame and background Image
Daniel Fernandez wrote:
Hi,
Sorry by my last mail. I sent you a wrong script. This it's my modified
MDI script with your code. The problem is that the new child window is
not visualized but the activate/deactivate events works when the window
is created.
Is there are any wrong in my code?
I'll appreciate your comments about this.
Best regards.
I think this is close to what you want (this is the first time I've
played with the MDI classes, so there may be better ways). The tricks I
used were:
(1) The class needs to use the MDIFrame message loop, so I added
-widget = MDIFrame to the class definition.
(2) MDIFrame sets WM_CLIPCHILDREN by default, but as the MDIClient
window fill the MDIFrame window, nothing is ever drawn; so I removed
the WM_CLIPCHILDREN from the MDIFrame with
-popsyle = WM_CLIPCHILDREN
(3) Now that we've removed the WM_CLIPCHILDREN from the MDIFrame, when
we draw on the whole of the MDIFrame's client area, we overwrite the
MDIChild windows, causing very nasty flickering, so I extended the
paint() function to clip the MDIChild windows from the MDIFrame's DC
that we are drawing into.
(4) Finally the MDIClient does not invalidate the regions exposed by an
MDIChild when it moves or is terminated, as it assumes that we want it
to paint the background, so I invalidate the regions in explicit
handlers for termination and moving (See NewChild(), -onTerminate
handler for the window and Hook(WM_MOVE ... ).
Really we want to do exactly what I did with a single window in the
MDIClient's WM_PAINT handler. But I can't see any way to get at that
with the current Win32::GUI codebase.
Regards,
Rob.
#!perl -w
#
# MDI sample
#
use strict;
use warnings;
use Win32::GUI;
use Win32::GUI::BitmapInline();
# My child counter for unique name.
my $ChildCount = 0;
my $Window;
# Load our bitmap
#my $bm = Win32::GUI::Bitmap-new(sail.bmp) or die Creating Bitmap;
my $bm = get_bitmap();
# Store the width and height, as we'll use them a lot
my($bmw, $bmh) = ($bm-Info())[0..1];
# create a class without a background brush: this prevents
# defFrameWindowProc erasing the window background, as we want to
# paint it ourselves to avoid flicker
my $class = Win32::GUI::Class-new(
-name = 'noflicker',
-brush = 0,
-widget = MDIFrame, # use the MDIFrame windowproc
);
# Create Main menu.
my $Menu = Win32::GUI::MakeMenu(
File = File,
New = { -name = File_New, -onClick = \NewChild },
-= 0,
Exit= { -name = File_Exit, -onClick = sub { -1; } },
Window = Window,
Next= { -name = Next, -onClick = sub {
$Window-{Client}-Next; } },
Previous= { -name = Prev, -onClick = sub {
$Window-{Client}-Previous; } },
-= 0,
Cascade = { -name = Cascade, -onClick = sub {
$Window-{Client}-Cascade(); 0; } },
Tile Horizontally = { -name = TileH, -onClick = sub
{ $Window-{Client}-Tile(1); } },
Tile Vertically= { -name = TileV, -onClick = sub
{ $Window-{Client}-Tile(0); } },
Help = Help,
About = { -name = About, -onClick = sub { 1; } },
);
# First we create an MDIFrame window.
$Window = new Win32::GUI::MDIFrame (
-title = Win32::GUI MDI Sample,
-left = 100,
-top= 100,
-width = 280,
-height = 280,
-name = Window,
-menu = $Menu,
-class = $class,
-popstyle = WS_CLIPCHILDREN, # So that the MDIClient's window is
not clipped
-onPaint = \paint,
-onTerminate = sub {print Terminate\n; -1}, ) or die Window;
# We add an MDIClient window, This window manage Child Window.
$Window-AddMDIClient(
-name = Client,
-firstchild = 100, # Define Child ID for
menu item
-windowmenu = $Menu-{Window}-{-handle}, # Define Menu Handle
where Add Window Child name
) or die Client;
# Create a memory DC, compatible with our window's
# DC, containing our bitmap. Do this once, here, to speed
# up the painting routine. Use a local block, so that $dc
# goes out of scope, and $dc gets released (could call
# $dc-ReleaseDC() instead).
my $memDC;
{
my $dc = $Window-GetDC();
$memDC = $dc-CreateCompatibleDC();
$memDC-SelectObject($bm);
}
# We need a brush to paint the window background
# with, select a grey one. We don't need to worry
# about freeing stock objects when we're done with them
my $bkBrush = Win32::GUI::GetStockObject(1);
# Show main window and go to event loop
$Window-Show;
Win32::GUI::Dialog();
# We've got some closures on $Window in the
# functions below, which appear to be the cause of
# a 'Can't call Delete .. in global clean up' warning,
# udefining $Window here stops that.
undef $Window;
exit(0);
# Our window painting routine. To avoid flicker we will
# paint the whole of the window, taking care not to draw any
# pixel more than once.
sub paint
{
print Painting...\n;
my($window, $dc) = @_;
# I will add StretchBlt to the next release so that we can stretch
[perl-win32-gui-users] Re: Draggable 'window' [Was: MDIFrame and background Image]
Steven Lloyd wrote:
Rob,
I have got this far but I cannot seem to get SetCapture to allow me to
go outside my window. Any ideas?
Steve,
Please can we keep discussion on-list (unless they are OT) - others may
be able to help, and may like to see the problems being solved.
Read up about SetCapture at:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/windowsuserinterface/userinput/mouseinput/mouseinputreference/mouseinputfunctions/setcapture.asp
You only continue to get mouse move events outside your window if a
mouse button is depressed, so you'll need to catch a mouse down event,
SetCapture(), process mouse moves and then ReleaseCapture() on the mouse
up event (OK, this last step is not strictly necessary, as the system
will do it for you).
I was also wrong about the hit-hest idea - I think you'll need to use
some combination of WindowFromPoint() and ChildWindowFromPoint() - I
haven't looked to see if they're in Win32::GUI or not.
Regards,
Rob.
#!perl -w
# Left-Click on the target image, and drag
use warnings;
use strict;
use Win32::GUI 1.0;
use Win32::GUI::BitmapInline();
my $mw = Win32::GUI::Window-new(
-name = MainWindow,
-title = Win32::GUI Spy++,
-pos = [100,100],
-size = [100,100],
);
my $cursor = get_cursor();
$mw-AddLabel(
-name = Target,
-icon = $cursor,
-notify = 1,
-onMouseDown = \mouseDown,
-onMouseUp = \mouseUp,
-onMouseMove = \mouseMove,
);
$mw-Show();
Win32::GUI::Dialog();
exit(0);
sub mouseDown
{
my $label = shift;
Win32::GUI::SetCursor($cursor);
$label-SetCapture();
return;
}
sub mouseUp
{
my $label = shift;
$label-ReleaseCapture();
return;
}
sub mouseMove
{
my ($label, $x, $y) = @_; # x,y in client co-ordinates
return unless Win32::GUI::GetCapture();
Win32::GUI::SetCursor($cursor);
print Mouse at: $x,$y\n;
return;
}
sub get_cursor
{
return Win32::GUI::BitmapInline-newCursor( q(
AAACAAEAIC8AEAAwAQAAFgAAACggQAEAAQEA
AAAHwAAAGDAAACbIAABQFAAApsoA
AUAFAAECgQACoAqAAqgqgAIBAIACqCqAAqAKgAECgQABQAUAAKbKAABQFAAAJsgAABgwAAAHwAAA
//gg
D///wAf//4gj//8YMf/+ODj//nx8//wMYH/8A4B//AOAf/wDgH/8DGB//nx8//44OP//GDH//4gj
///AB///4Ag///8=
) );
}
[perl-win32-gui-users] Re: [win32gui] {Spam?} Re: MDIFrame and background Image
Daniel Fernandez wrote:
Hi,
I'm trying to implement the StretchBlt function using a call to
gdi32.dll in order to fill the window with the image.
here, I load the dll
my $ApiObj = new Win32::API (gdi32, StretchBlt, PPN, I);
my $ApiObj = new Win32::API (gdi32, StretchBlt, NNN, I)
or die (Can't load StretchBlt);
The src and dest DC parameters are handles to DC's (HDC), not Pointers.
Here, I call the StretchBlt
$ApiObj-Call($dc, 0, 0, $ww, $wh, $memDC, $bmw, $bmh, 13369376);
$ApiObj-Call($dc{-handle}, 0, 0, $ww, $wh, $memDC-{-handle}, 0, 0,
$bmw, $bmh, 13369376);
- You need to get the window's DC handle from the DC object, and pass
that (as Win32 api calls expect Win32 handles, not Perl objects).
- You were missing two parameters from the call
[I've not tested this]
Regards,
Rob.
[perl-win32-gui-users] Re: Debugging Win32::GUI [Was: (no subject)]
[Please always put a descriptive subject line with your mail - if nothing else it helps people searching the archive] Sergey Cherniyenko wrote: How can I turn on debugging in Win32::GUI to get some descriptive output to console. In modules I've seen that can be done. How? There is no specific additional debugging options for Win32::GUI. I always recommend the following: (1) Start your scripts with #!perl -w use strict; use warnings; This gets you the maximum help from perl on potential issues. (2) Always check the return values from object creation - most Win32::GUI object constructors (typically the new() method) return undef on failure. If you are having a specific problem, then try asking here, ideally with a complete (but short) script demonstrating the problem. Regards, Rob.
Re: [win32gui] [perl-win32-gui-users] popup menu for NotifyIcon
Sergey Cherniyenko wrote:
1. On each right click on tray icon I get following warnings
Use of uninitialized value in subroutine entry at D:\perl_projects\exrc1.pl
line 68.
Argument -notifyicons isn't numeric in subroutine entry at
D:\perl_projects\exrc1.pl line 68.
Argument _NotifyIcon100 isn't numeric in subroutine entry at
D:\perl_projects\exrc1.pl line 68.
Argument -notifyicons isn't numeric in subroutine entry at
D:\perl_projects\exrc1.pl line 68.
I broke TrackPopupMenu in the V1.02 release. Please see an earlier
message to this list for work-arounds:
http://sourceforge.net/mailarchive/message.php?msg_id=12416384
2. Popup menu onClick handlers is not called.
You are missing the '-' on your onClick parameter definitions.
This works for me:
#!perl -w
use strict;
use warnings;
use Win32::GUI;
my $mw = Win32::GUI::Window-new(
-name = 'mw',
-size = [400, 400],
-pos = [200, 200],
-title = FormsTest,
-onTerminate = \DoExit,
-onMinimize = \DoHideMe,
) or die Creating mw failed;
my $popupMenu = Win32::GUI::Menu-new(
Options = Options,
ShowMe = {-name = ShowMe, -onClick = \DoShowMe},
HideMe = {-name = HideMe, -onClick = \DoHideMe},
Exit = {-name = Exit, -onClick = \DoExit}
) or die Creating Menu failed;
my $icon_no = Win32::GUI::Icon-new('no!.ico') or die Creating Icon
failed;
my $icon_yes = Win32::GUI::Icon-new('yes!.ico') or die Creating Icon
failed;
my $ni = $mw-AddNotifyIcon(
-icon = $icon_yes,
-id = 100,
-onClick = sub{$mw-Enable(); $mw-Show(); $mw-Restore() if
$mw-IsIconic();},
-onRightClick = \myTrack,
) or die Adding notify icon failed;
$mw-Show();
Win32::GUI::Dialog();
exit(0);
sub DoShowMe {
$mw-Enable() unless $mw-IsEnabled();
$mw-Show() unless $mw-IsVisible();
$mw-Restore() if $mw-IsIconic();
$mw-BringWindowToTop();
$mw-SetActiveWindow();
return 1;
}
sub myTrack {
$mw-Enable();
$mw-TrackPopupMenu($popupMenu-{Options});
return 1;
}
sub DoHideMe {
$mw-Hide() if $mw-IsVisible();
$mw-Disable() if $mw-IsEnabled();
return 1;
}
sub DoExit {
return -1;
}
[perl-win32-gui-users] Re: Draggable 'window'
Steven Lloyd wrote:
MouseMove returns the label, and the x, y coordinates of the mouse, right?
Right - but it gives an unsigned value. This is not usually a problem,
as you don't normally seem mouse move locations outside the client area,
which always has 'small' positive values. The code below contains a
work-around for this issue, and I will look at Jeremy's solution from
the other related thread.
Not wanting to steal your thunder on this one, but I had a few hours on
a plane this-morning, and I came up with a way of doing the drawing that
doesn't need the Redraw/InvalidateRect calls. It also deals with not
drawing over windows that overlap the one you hover the mouse over.
I tried to avoid using Win32::API, but in the end needed a couple of
extra calls to get the full functionality that I was looking for.
Regards,
Rob.
#!perl -w
use warnings;
use strict;
use Win32::GUI;
use Win32::GUI::BitmapInline();
use Win32::API;
# Some constants
sub CW_USEDEFAULT() {0x8000}
sub R2_NOT(){6}
sub PS_INSIDEFRAME(){6}
sub NULL_BRUSH(){5}
sub GWL_STYLE() {-16}
sub CWP_SKIPINVISIBLE() {1}
sub CLR_BLUE() {0xFF}
# Using Win32::API, as GetWindowDC not in Win32::GUI
my $GetWindowDC = Win32::API-new(user32, GetWindowDC, 'N', 'N')
or die Can't load GetWindowDC: $!;
# Note that the prototype of '' is a cheat, and relies on the fact
# that the point structure (2nd argument) that must be passed by value
# can be pushed onto the calling stack as 2 16-bit numbers, rather than
# a single 32-bit struct. Doing it this way avoids having to use
# Win32::API::Struct to define a POINT struct, and using the prototype
# 'NSN'.
my $ChildWindowFromPointEx = Win32::API-new(user32,
ChildWindowFromPointEx, '', 'N')
or die Can't load ChildWindowFromPointEx: $!;
# Some resources that we'll be using a lot; create them once:
my $cursor = get_cursor();
my $blank_cursor = get_cursor2();
my $pen = Win32::GUI::Pen-new(
-style = PS_INSIDEFRAME,
-width = 3,
-color = 0, # pen color is ignored when foreground mix mode is R2_NOT
) or die Creating Pen;
my $null_brush = Win32::GUI::GetStockObject(NULL_BRUSH);
# The window handle of the window that we're over, and have
# drawn a rectangle around. Use 0 to indicate no such window.
my $curHwnd = 0;
# Create out main window
my $mw = Win32::GUI::Window-new(
-name = MainWindow,
-title = Win32::GUI Spy++,
-left = CW_USEDEFAULT,
-size = [215,140],
-resizable = 0,
) or die Creating Main Window failed;
# Instruction label
$mw-AddLabel(
-name = Instructions,
-text = Drag the target over the window you want information about,
-pos = [5,4],
-size = [160, 32],
) or die Creating Instruction label failed;
# Target bitmap label
$mw-AddLabel(
-name = Target,
-pos = [170,4],
-icon = $cursor,
-background = CLR_BLUE,
-notify = 1,
-onMouseDown = \mouseDown,
-onMouseUp = \mouseUp,
-onMouseMove = \mouseMove,
) or die Creating Target Label failed;
# Label and Textfield to report window handle
$mw-AddTextfield(
-name = 'HWND',
-prompt = [ 'Handle', 40 ],
-pos = [5,40],
-size = [160,20],
-readonly = 1,
) or die Creating HWND Field failed;
# Label and Textfield to report window title/text
$mw-AddTextfield(
-name = 'TITLE',
-prompt = [ 'Title', 40 ],
-pos = [5,62],
-size = [160,20],
-readonly = 1,
) or die Creating TITLE field failed;
# Label and Textfield to report window class
$mw-AddTextfield(
-name = 'CLASS',
-prompt = [ 'Class', 40 ],
-pos = [5,84],
-size = [160,20],
-readonly = 1,
) or die Creating CLASS field failed;
# Display the window and enter the dialog phase
$mw-Show();
Win32::GUI::Dialog();
# We're done
exit(0);
##
# Event handlers
##
##
# Target Label Mouse Down handler:
# - Capture the mouse, set the cursor to the target cursor, and remove
# the icon from the label
sub mouseDown{
my $label = shift;
$label-SetCapture();
Win32::GUI::SetCursor($cursor);
$label-SetIcon($blank_cursor);
return;
}
##
# Target Label Mouse Up handler:
# - If the label has captured the mouse (should have done in the
# mouse down handler), then release capture, set the label icon
# and set the fact that we're no longer over a window
# - Force a redraw of all windows, in case we got any of our
# drawing wrong.
sub mouseUp{
return unless Win32::GUI::GetCapture();
my $label = shift;
$label-ReleaseCapture();
$label-SetIcon($cursor);
$curHwnd = 0;
# redraw everything
[perl-win32-gui-users] Re: [Vertical Slider?
Jason P. wrote: Steven Lloyd wrote: I know that a horizontal slider can by created but is there a way to create a vertical slider control using Win32::GUI? Does AddSlider have such an option? Steve Lloyd http://www.basgetti.com -horizontal=0 snatched from Splitter.xs Or possibly, -vertical = 1 See Win32::GUI::Slider docs at http://perl-win32-gui.sourceforge.net/docs/Win32/GUI/Slider.html [Splitters and Sliders aren't the same thing! The XS code for a slider can be found in Trackbar.xs] Rob.
Re: [win32gui] [perl-win32-gui-users] Continued Window Background Color Problems
Brian Fredette wrote: I read in the group there was a bug submitted regarding the setting of window background colors (http://sourceforge.net/tracker/index.php?func=detailaid=1236053group_id=16572atid=116572) I'm still having this problem but the bug tracker says the problem has been fixed. What do I need to do to correct this issue? This is probably a good opportunity to let you all know how I am trying to use the tracker system for bugs and enhancements: (1) If the tracker has been assigned to someone, then that person is (probably) looking at the issue. If the issue is unassigned, then chances are we're not looking at it currently. (2) Once I have a potential fix for an issue, I'm putting the fix into the CVS source tree (so that it stands a chance of running in a few different environments), marking the issue as fixed and lowering the priority. (3) Once we have a release containing the fix, then I'll close the tracker. So, in this specific case, the fact that the tracker is marked as fixed means there is a fix in CVS, but the fact that the tracker is still open means that the fix is not in a release yet. Regards, Rob.
Re: [win32gui] Re: [perl-win32-gui-users] SW_SHOWNA and SW_SHOWNOACTIVATE
Jason P. wrote: Jeremy White wrote: Sometimes it fires the Activate, sometimes it doesnt...odd, and annoying to have it grab the cursor away, if only for brief moments, It can stop you typing at just the right time.. Very interesting example. I checked that the win32-gui show method is passing the correct parameters to the MS API function ShowWindow - and it is, so the problem is not there. The only thing I can think of is when you are manipulating the window one of the methods is somehow performing an implicit activate? From looking at the code both Move() and Resize() use SetWindowPos without setting SWP_NOACTIVATE, so both calls will result in the window being activated. (If I understand the interaction between not using SWP_NOACTIVATE and using SWP_NOZORDER, which isn't exactly clear) http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/windowsuserinterface/windowing/windows/windowreference/windowfunctions/setwindowpos.asp I came accross the AnimateWindow function: That's definitely the way to go from what I have read (although I have never used it) It appears that it is being called when I reset the size and position after hiding, and then again when the forced animation begins collapsing it down. Activate is not called again while it is collapsing, but then it already has active and focus while its doing this operation at high speed. My thoughts are that it is somewhere doing this in the size and or location algorithms. Both I believe. While I have your ear regarding fancy features... Do you know of the method to display those little Tooltip messages that windows uses? I'm not aware of perlTray (that you refer to in your other mail) - do you mean balloon tooltips? The ones that pop up looking like a speech balloon above the taskbar, sometimes with an icon in them? I seem to remember stumbling across some threads discussing this on the list - a search of the list archives might be in order? Regards, Rob.
Re: [win32gui] [perl-win32-gui-users] AddSlider Sample
Steven Lloyd wrote: For what it is worth, here is an example of horizontal and vertical sliders. Feel free to add this to the samples if you would like. Thanks - will do. Note: Min, Max, and Pos do not seem to work when sent as attributes on slider creation but work if set afterward. Any ideas why? I've noticed this too. Simple answer is that they are not supported options for the new() method. If you'd like them added, raise a RFE tracker, and I'll look into it. Regards, Rob.
Re: [win32gui] [perl-win32-gui-users] Tooltip once again
Dominik wrote:
i dont get it.. is there one example how to use a simple tooltip - not
using the -tip = text option but creating a Win32::GUI::Tooltip
object somewhere around?
I am searching a way to display a tracking multiline tooltip from
one of my events ( a hooked WM_HELP after clicking the helpbutton ) at
GetCursorPos coordinates...
Hi Dominik,
I had a look at the tooltip class for the first time this-evening.
After reading all the MSDN docs, I think I've got to grips with them,
but they are pretty complex beasts.
For multi-line tooltips you MUST set a maximum width.
The example attached shows a couple of ways of setting the tools for a
tooltip control and a couple of ways of setting the text. I haven't the
time to look at a tracking example right now but here's the basic principle:
(1) Add the tool to the tooltip control with the TTF_TRACK and
TTF_ABSOLUTE options (-track = 1, -absolute = 1). You won't need to
-subclass = 1 option due to (2) and (3) below.
(2) Your application become responsible for when to display and hide the
tooltip, using the TrackActivate() method.
(3) Your application becomes responsible for setting the tooltip
position with the TrackPosition() method (probably in a mouse move handler)
You can read all about tooltips and their related tools on msdn at:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/commctls/tooltip/reflist.asp
Hope this helps.
Regards,
Rob.
#!perl -w
use strict;
use warnings;
use Win32::GUI;
my $mw = Win32::GUI::Window-new(
-name = MW,
-title = Tooltip test,
-size = [400,300],
) or die Failed to create MW;
my $edit = $mw-AddTextfield(
-name = TF,
-pos = [100,100],
-size= [100, 20],
) or die Failed to create TF;
my $tip = Win32::GUI::Tooltip-new(
$mw,
-name = TT,
-pushexstyle = WS_EX_TOPMOST, # You might get away without this
-onNeedText = \tooltext, # call to get text for tools with
'needtext' option
) or die Failed to create TT;
# You need to set a maximum width to use multi-line
# tooltips. The tip will automatically wrap at this
# width, or you can force a line-break with \r\n
$tip-SetMaxTipWidth(100);
# When adding tools, -subclass = 1 is needed, unless
# you want to have to pass mouse messages to the tooltip
# control yourself.
# Add a tool, specifying id and a client area
# rectangle
$tip-AddTool(
-text = Some long tip that will wrap\r\nMain Window,
-subclass = 1,
-id = 0,
-rect = [ $mw-GetClientRect() ],
);
# Add a tool, specifying a child window, and specifying
# that we'll return the text from a -onNeedText handler
# (required for multi-line tooltips).
$tip-AddTool(
-needtext = 1,
-subclass = 1,
-window = $edit,
);
$mw-Show();
Win32::GUI::Dialog();
exit(0);
# This sub is called when our tooltip needs to get text
# for a tool. The tool is identified by the $idFrom
# parameter, but as we've used both mechanisms for
# specifying the tools in this example (by window handle and
# by rect with an id), then we have no way to tell
# whether $idFrom contains a window handle or an id.
sub tooltext
{
my $self = shift;# perl tooltip object
my $idFrom = shift; # either a window handle or control identifier,
# but we can't tell which!
my $text = Some text\r\nSome more text;
return ($text, 0);
# You need to return a list of a text string
# and your result code, otherwise you stand a good
# chance of causing a crash (try returning just the string)
}
Re: [win32gui] [perl-win32-gui-users] Tooltip once again
Jason P. wrote:
Robert May wrote:
In the example provided, and all my further tests, using the subclass
option provides inaccurate location for the automated placement. Try
moving the window down a ways. You will find you need to expand the window.
It looks like the subclass option is using screen x,y vs where it should
be using window x,y. More likely the conversion was not realized
somewhere in the code, as I doubt anyone did this intentionally.
I noticed this (and the report in your earlier post of the tooltip
window appearing under the textfield), but didn't have time to
investigate yesterday. It turns out that the co-ordinates are bing sent
correctly, but that the control is being created incorrectly as a child
winodow (hence expects its co-ordinates relative to it's parent's client
area) when it should be a top-level owned window. I've raised a
tracker, and will fix in the next release.
And I hate to be a pain, but I can't get my head around how to use the
TrackActivate and TrackPosition methods appropriately.
OK, as I was interested in seeing this work too, here's an example.
There may well be easier ways to achieve this.
Rob.
#!perl -w
use strict;
use warnings;
use Win32::GUI;
sub TME_LEAVE() {2};
sub OFFSET_X() {16};
sub OFFSET_Y() {16};
my $mw = Win32::GUI::Window-new(
-name = MW,
-title = Tracking Tooltip,
-size = [400,300],
-onMouseMove = \displayTooltip,
-onMouseOut = \hideTooltip,
) or die Failed to create MW;
my $tip = Win32::GUI::Tooltip-new(
$mw,
-name = TT,
-pushexstyle = WS_EX_TOPMOST, # You might get away without this
) or die Failed to create TT;
# Add a tool, specifying id and a client area
# rectangle
$tip-AddTool(
-text = ,
-id = 1001,
-rect = [ $mw-GetClientRect() ],
-track = 1,
-absolute = 1,
);
$mw-Show();
Win32::GUI::Dialog();
exit(0);
sub displayTooltip
{
my ($win, $cx, $cy) = @_; # x,y in client co-ordinates
# Take into account that client co-ordinates can be negative,
# the need to do this will go when tracker 1262098 is fixed
$cx -= 65536 if $cx 32767;
$cy -= 65536 if $cy 32767;
# convert pos to screen co-ordinates
my ($sx, $sy) = $win-ClientToScreen($cx, $cy);
# Update the tip text to the co-ordinates of the mouse
$win-{TT}-UpdateTipText(1001,Screen:$sx,$sy Client:$cx,$cy);
# Update tooltip position to an offset from the mouse position
$win-{TT}-TrackPosition($cx + OFFSET_X, $cy + OFFSET_Y);
# TODO: will need to be $sx, $sy when tracker
# 1273134 is fixed
# Show the tooltip
$win-{TT}-TrackActivate(1001,1);
# Set up mouse tracking so we get an onMouseOut event when we
# leave the window
$win-TrackMouse(0, TME_LEAVE);
return;
}
sub hideTooltip
{
my ($win) = @_;
# Hide the tooltip
$win-{TT}-TrackActivate(1001,0);
return;
}
Re: [win32gui] [perl-win32-gui-users] Tooltip once again
Dominik wrote: one question though: is it possible to have the tips being showed also outside of my main-window (f.e. if the mouse is near the windowboarder)? You'll get that with the fix to the creation styles that I just put into CVS. Currently the addition of the WS_CHILD style to the tooltip control results it it getting clipped to its parent window. Without this style it will be a true top-level window and can be drawn anywhere on the screen. If you need it now, and can build from source, then grab the latest code from CVS. If this is not an option, then you'll have to wait for V1.03. Also when working with the WM_HELP msg - there is all the info available inside the passed HELPINFO structure within lParam. things like iCtrlId, hItemHandle, dwContextId and POINT struct with cursor pos So I have to learn pack and unpack on c-structs very soon - your example from the DC used for customdrawn Toolbar discussion put me on that track.. ;) If you think it would be useful to have native support for WM_HELP messages, then please raise an RFE tracker. Good luck! Rob.
Re: [win32gui] [perl-win32-gui-users] Textfield - insert at cursor
The ReplaceSel() method replaces the current selection. If there is no current selection, the replacement text is inserted at the location of the caret. More at: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/commctls/editcontrols/editcontrols.asp The MSDN control overviews always make good reading. For edit control's find it at: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/commctls/editcontrols/editcontrols.asp Regards, Rob. Steven Lloyd wrote: Is there a way with a textfield to insert text at the current cursor position? The cursor may be anywhere in the existing text Thanks, Steve --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ Perl-Win32-GUI-Users mailing list Perl-Win32-GUI-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
Re: [win32gui] [perl-win32-gui-users] Win32::GUI::MessageBox with a timer?
Lloyd, Steve wrote: Does anyone know how I can call Win32::GUI::MessageBox and have it close after a certain number of seconds? Is this possible? Not easily. MessageBoxes use their own internal message loop, so your application doesn't get to see events (including timer ones) while the message box is displayed. If you really wanted to you could probably do something with SetWindowsHookEx() http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/windowsuserinterface/windowing/hooks/hookreference/hookfunctions/setwindowshookex.asp but you'd need to use Win32::API and Win32::API::Callback; it would be easier to implementing your own Modal Dialog to display the message that you're currently using MessageBoxes for. Rob. -- Robert May Win32::GUI, a perl extension for native Win32 applications http://perl-win32-gui.sourceforge.net/
Re: [win32gui] RE: [perl-win32-gui-users] Win32::Gui built-in functions?
Jeremy White wrote: There are quite a few Win32::GUI functions like Win32::GUI::GetOpenFileName that are built in but not listed on http://perl-win32-gui.sourceforge.net http://perl-win32-gui.sourceforge.net/docs/Win32/GUI/Reference/Methods.html Or, evem more precisely: http://perl-win32-gui.sourceforge.net/docs/Win32/GUI/Reference/Methods.html#getopenfilename I hope to have some search capability on the site before long. In the meantime, googling with the added keywords site:perl-win32-gui.sourceforge.net is a pretty good way of finding things: http://www.google.com/search?q=getopenfilename+site%3Aperl-win32-gui.sourceforge.net Regards, Rob.
Re: [perl-win32-gui-users] CVS/Nightly builds?
Antony Baxter wrote: Hello, Is it possible to get hold of nightly builds of Win32::GUI from CVS? Not currently, but it is on my (ever extending) list of things to think about. I don't have VC++6 and am having all sorts of problems building it with VC++7 (and given the warnings in the README, wasn't that confident of it working anyway!). I'd be interested in hearing a bit more about your experience of trying to build with VC++7 - I've successfully built with the freely downloadable version (although you have to jump through some hoops), and haven't had any problems related to the different versions of msvcrt.dll (although I can't claim to have done any extensive testing). I would build it/use it with Cygwin, but I'm unable to compile Win32::GUI::DIBitmap for Cygwin. Sorry, can't help there. As Jez suggests, the build with mingw and Extutils::FakeConfig is relatively straightforward, once you've determined which mingw packages you need - just ensure you install mingw before Extutils::FakeConfig, and install Extutils::FakeConfig from source rather than from the activestate ppm, so that the install builds the perl link libraries that will be needed. Let us know if you need any further help - and failing everything I hope to get around to a new release in the next couple of weeks. Regards, Rob.
Re: [win32gui] [perl-win32-gui-users] Using the Win32::GUI::RichEdit Control
Steven Lloyd wrote: Can anyone show me how to do any of the following in a Win32::GUI::RichEdit Control? - Insert an image No idea, but probably not possible with Richedit V1.0 which Win32::GUI uses by default. IIRC OLE support was a Richedit V2.0 feature. - Bold or underline the selected text RichEdit::SetCharFormat( -bold = 1 -underline = 1 ); Documentation has been added to RichEdit.xs in CVS. http://msdn.microsoft.com/library/en-us/shellcc/platform/commctls/richedit/richeditcontrols/richeditcontrolreference/richeditmessages/em_setparaformat.asp - Center the line or the selected text RichEdit::SetParaFormat( -align = 'center' ); Is the closest I can think of. http://msdn.microsoft.com/library/en-us/shellcc/platform/commctls/richedit/richeditcontrols/richeditcontrolreference/richeditmessages/em_setparaformat.asp - show the cut, copy, paste context menu when text is selected... I think this needs Richedit V2.0 You can try adding -class = 'RichEdit20A' to your constructor. (I can't test this, as I'm at a Win98 box now, and Win98 does not support the context menus for RichEdit/Edit controls at all - I think you need Win2K and higher, but could be wrong) Regards, Rob.
[perl-win32-gui-users] Re: Centering Win32::GUI::GetOpenFileName Dialog Box
Rob wrote:
Does anyone know how I could center my
Win32::GUI::GetOpenFileName dialog
box in my window
Ariel Serbin wrote:
It would be very nice to
be able to have that dialog default to the thumbnail
view.
Brian wrote:
Win32::GUI::GetOpenFileName is a hook into a Windows
system resource, it is not a Win32::GUI object over
which you have control. You (the programmer) can't
size it or position it at all. The system will
position it every time and, to the best of my
knowledge, the system places it exactly where the
user left it the last time they called it up -- with
any program, not just your Win32::GUI application.
Close. GetOpenFileName() is a function that displays a system dialog
(from comdlg32.dll). Other 'common' dialogs are font choosers, color
pickers etc. - you know, all those 'standard' dialogs.
These dialogs are just windows, and if you can get the windows handle to
them, you can manipulate them just like any other window (OK, this is a
big generalisation, but is in, er, general, true).
All the common dialogs also (at the Win32 api level) provide
hooks(callbacks) just for this purpose (for example see the
GetOpenFileName() documentation at
http://msdn.microsoft.com/library/en-us/winui/winui/windowsuserinterface/userinput/commondialogboxlibrary/commondialogboxreference/commondialogboxfunctions/getopenfilename.asp
and look for the description of OFNHookProc). These callbacks are not
supported by Win32::GUI (but could be), and would be the 'correct' way
to do what you are trying to do. However, as with most perl and Win32
api things, TIMTOWTDI (There Is More Than One Way To Do It).
For example, in the code below I take advantage of the fact that when
the dialog is shown, it deactivates the main window; as a result of
this the main window is sent a WM_WINDOWPOSCHANGE message (as it's
z-order changes), and one of the parameters passed in this message is
the handle to the window that is becoming active: the handle to the
dialog - we can then use that to get the size, and set the position of
the dialog. There is one problem that I haven't had the time to solve,
and that's how to modify the logic, so that the dialog doesn't get
forced to be centered on the main window regardless - try dragging it,
and see how it 'snaps' back with this code.
http://msdn.microsoft.com/msdnmag/issues/04/03/CQA/
I haven't tested this, but replacing the moving code below with code to
find the handle to the lsitview (using FindWindow()?), and then using a
SendMessage call, using the values from figure 5 in the link above
should set the view to what you want.
Hope this helps. Please post back if you successfully solve any of the
remaining problems.
Regards,
Rob.
#!perl -w
use strict;
use warnings;
use Win32::GUI;
sub WM_WINDOWPOSCHANGING() {70}
sub SWP_NOACTIVATE() {16}
my $mw = Win32::GUI::Window-new(
-title = GetOpenFileName Test,
-pos = [100,100],
-size = [400,300],
);
$mw-Hook(WM_WINDOWPOSCHANGING, \PosChanging);
$mw-AddButton(
-text= Browse ...,
-pos = [10,10],
-onClick = \Browse,
);
$mw-Show();
Win32::GUI::Dialog();
exit(0);
sub Browse
{
Win32::GUI::GetOpenFileName(
-owner = $mw,
);
return;
}
sub PosChanging
{
my ($object, $wParam, $lParam, $type, $msgcode) = @_;
return unless $type == 0;
return unless $msgcode == WM_WINDOWPOSCHANGING;
# unpack WINDOWPOS structure
#
http://msdn.microsoft.com/library/en-us/winui/winui/windowsuserinterface/windowing/windows/windowreference/windowstructures/windowpos.asp
my($hwnd, $hwndInsertAfter, $x, $y, $cx, $cy, $flags) =
unpack(LLI, unpack(P28, pack(L,$lParam)));
# check that it's us (this is probably not necessary)
return unless $hwnd == $object-{-handle};
# check that the handle in $hwndInsertAfter is for the Open File dialog:
# here I test the window caption, but you might need something more
robust:
return unless Win32::GUI::Text($hwndInsertAfter) eq Open;
# only interested in doing something if we're being de-activated
# for the first time: this test needs enhancing, so that dragging
# the dialog works, and we don't move it back to the center when we
# release the mouse
return unless $flags SWP_NOACTIVATE;
# modify the Dialog (center it on the main window):
my $sx = $mw-Left() + ($mw-Width() -
Win32::GUI::Width($hwndInsertAfter))/2;
my $sy = $mw-Top() + ($mw-Height() -
Win32::GUI::Height($hwndInsertAfter))/2;
Win32::GUI::Move($hwndInsertAfter, $sx, $sy);
# set the view:
# from http://msdn.microsoft.com/msdnmag/issues/04/03/CQA/
# 0x7029Icons
# 0x702BList
# 0x702CDetails
# 0x702DThumbnails
# 0x702ETiles
# Find the listview
Re: [win32gui] Re: [perl-win32-gui-users] Re: Centering Win32::GUI::GetOpenFileName Dialog Box
Ariel Serbin wrote:
1. Win32::GUI::FindWindow only finds top level windows
(which is what it says in the docs.)
The docs are correct! I was thinking of FindWindowEx, which is not in
Win32::GUI.
I had to install
Win32::GuiTest to get the handle of the listview
control in the Open dialog.
There's some code below to show a way of walking the window
hierarchy using GetWindow() - although EnumChildWindows() is safer
according to msdn.
2. The event in that example is fired when the file
open dialog opens, however GuiTest's FindWindowLike
function doesn't seem to be finding the control at
that point. When I click on the dialog, the event
fires again and it finds the control.
It appears that the dialog has not finished initialising the first time
the dialog sends the WM_WINDOWPOSCHANGING message. There is another
message sent by the dialog: WM_ENTERIDLE, which is sent every time the
dialog's message loop finishes processing all the messages in its queue.
By Hook()ing that message, we get to do our processing after
everything is initialised fully.
I've also moved the Hook() call to just before we do the
GetOpenFileName() call, and I UnHook() the message as soon as we see one
- this ensures that we only position the dialog and set the view mode
once each time we display it. (UnHook() causes a warning on my perl
5.8.7, Win32::GUI 1.02 - I raised a tracker for this some time ago). [If
the warnings irritate you, then a similar effect could be achieved with
a global variable set to 0 in the Browse function, and set to 1 in the
Idle function, with a test at the start of the Idle function.]
Regards,
Rob.
#!perl -w
use strict;
use warnings;
use Win32::GUI;
sub WM_WINDOWPOSCHANGING() {70}
sub WM_ENTERIDLE() {289}
sub SWP_NOACTIVATE() {16}
sub MSGF_DIALOGBOX() {0}
my $mw = Win32::GUI::Window-new(
-title = GetOpenFileName Test,
-pos = [100,100],
-size = [400,300],
);
$mw-AddButton(
-text= Browse ...,
-pos = [10,10],
-onClick = \Browse,
);
$mw-Show();
Win32::GUI::Dialog();
exit(0);
sub Browse
{
$mw-Hook(WM_ENTERIDLE, \Idle);
Win32::GUI::GetOpenFileName(
-owner = $mw,
);
return;
}
sub Idle
{
print Idle hook\n;
$mw-UnHook(WM_ENTERIDLE); # ensure this hook doesn't get called again
my ($object, $wParam, $lParam, $type, $msgcode) = @_;
return unless $type == 0;
return unless $msgcode == WM_ENTERIDLE;
# check the message came from a dialog box
return unless $wParam == MSGF_DIALOGBOX;
# check that the dialog window handle in $lParam is for the Open File
dialog:
# here I test the window caption, but you might need something more
robust:
return unless Win32::GUI::Text($lParam) eq Open;
# modify the Dialog (center it on the main window):
my $sx = $mw-Left() + ($mw-Width() - Win32::GUI::Width($lParam))/2;
my $sy = $mw-Top() + ($mw-Height() - Win32::GUI::Height($lParam))/2;
Win32::GUI::Move($lParam, $sx, $sy);
# Walk the child windows of the open dialog to find the
SHELLDLL_DefView window:
my $phwnd = $lParam;
my $mode = GW_CHILD; # Initially find the first child of the dialog
window
while(my $chwnd = Win32::GUI::GetWindow($phwnd, $mode)) {
if (Win32::GUI::GetClassName($chwnd) eq SHELLDLL_DefView) {
# set the view:
# from
http://msdn.microsoft.com/msdnmag/issues/04/03/CQA/
# 0x7029Icons
# 0x702BList
# 0x702CDetails
# 0x702DThumbnails
# 0x702ETiles
Win32::GUI::SendMessage($chwnd, WM_COMMAND, 0x702C, 0);
last; # we found it
}
$mode = GW_HWNDNEXT; # and walk the rest of the dialog's
children
$phwnd = $chwnd;
}
return;
}
[perl-win32-gui-users] Re: Attaching to a window created by some other application
Piotr Kaluski wrote:
Hi,
I am one of developers of Win32::GuiTest library. It is a module for GUI
test automation. I am actually pretty impressed with all the great work
you have done. Using your module should free us from writing some
functions ourselves.
I have one question. My impression is, that your library is object
oriented and it assumes, that a script using it has actually created all
windows it manipulates. Is it possible to attach to a window/control
created by some other application? Say I have a handle of a main window of
Windows calculator. How do I turn it into Win::GUI object?
Firstly I'd like to iterate Jeremy's reply that most of the method calls
in Win32::GUI (and especially the ones that have underlying w32api
calls that operate on handles) are overloaded, so that they can be
called statically with an extra first parameter that is a window handle,
so Win32::GUI is not limited to working with objects that it created
itself. At the bottom is a (rather messy and hastily thrown together)
script that enumerates the windows you have on your desktop, and allows
you to minimise/restore then, showing how this can be done. This usage
is also touched on in Part 1 of the tutorial
(http://perl-win32-gui.sourceforge.net/docs/Win32/GUI/Tutorial/Part1.html#centring_the_window_and_the_text)
It is an interesting time for this conversation to come up, as we have
been touching the subject of testing on the hackers list a few times in
recent months, and if you were to look in the TODO file in CVS you would
see that I added a comment yesterday that I was leaning towards a
Win32::GUI::Test package. I have not discussed my reasoning yet (and my
position is still forming) but I'll try to outline my thinking. Please
bear in mind that I haven't given Win32::GuiTest more than a cursory
glance yet, and that nothing is set in stone.
(1) As a Win32::GUI developer I am primarily looking at a package that
will simplify writing tests for the Win32::GUI distribution. That said,
our users would almost certainly benefit from a well written test
package for testing their own applications.
(2) Whatever package we end up with must be readily usable within the
standard perl test framework: this means being able to write tests that
run under the Test::Harness framework, and can be invoked using 'make
test' and 'prove'.
(3) I'd prefer not to have to make an external package a pre-requsite
for building and testing Win32::GUI - but will continue to consider it
as I have no desire to re-generate good work that has already been done
by someone else. I would be very interested in seeing a list of the
win32api functions that Win32::GuiTest uses, so that we could see how
much we would need to add to Win32::GUI to get the same functionality.
As Ariel points out in his reply there are certainly calls missing from
Win32::GUI - things that I am sure we would need that spring to mind are
EnumWindows, EnumChildWindows and FindWindowEx - but these and others
really should be in Win32::GUI, so I'd have no problems adding them.
So, from a Win32:GUI point of view I would think that building
Win32::Gui::Test on top of the existing Win32::GUI framework makes a lot
of sense. From a Win32::GuiTest point of view I think there needs to be
some thought as to whether having it installable as a separate module,
without Win32::GUI makes sense - as has already been mentioned,
Win32::GUI is not a small download, and may be rather heavy-weight for
someone looking for a test framework to test Win32 paps built in other
environments.
Regards,
Rob.
#!perl -w
use strict;
use warnings;
use Win32::GUI;
my $winInfo;
my $selHwnd = 0;
my $mw = Win32::GUI::DialogBox-new(
-title = $0,
-pos = [100,100],
-size = [300,100],
-helpbutton = 0,
);
my $c = $mw-AddCombobox(
-pos = [10,10],
-size = [$mw-ScaleWidth()-20,100],
-sort = 1,
-vscroll = 1,
-onChange = \Select,
-dropdownlist = 1,
);
$mw-AddButton(
-text= Refresh,
-pos = [10, $mw-ScaleHeight()-30],
-size= [60,20],
-onClick = sub {populateCombo($c); 0;},
);
my $b = $mw-AddButton(
-text= Minimize,
-pos = [$mw-ScaleWidth()-70, $mw-ScaleHeight()-30],
-size= [60,20],
-onClick = \Action,
);
populateCombo($c);
$mw-Show();
Win32::GUI::Dialog();
exit(0);
sub populateCombo
{
my $c = shift;
$selHwnd = 0;
$b-Enable(0);
$winInfo = WindowList();
$c-Clear();
for my $w (keys %$winInfo) {
$c-Add($w);
}
}
sub WindowList
{
my %windows;
# walk all the top level windows (immediate children of desktop):
my $hwnd = Win32::GUI::GetDesktopWindow();
my $mode = GW_CHILD;
while( $hwnd = Win32::GUI::GetWindow($hwnd, $mode) ) {
$mode = GW_HWNDNEXT;
[perl-win32-gui-users] Perl versions earlier than 5.6.1
Is anyone using Win32::GUI with any Perl version earlier than 5.6.1 I am considering officially dropping support for earlier versions, and so this is your chance to tell me if that will cause you problems. Regards, Rob. -- Robert May Win32::GUI, a perl extension for native Win32 applications http://perl-win32-gui.sourceforge.net/
[perl-win32-gui-users] Re: Merging Win32::GUI and Win32::GuiTest
Piotr Kaluski wrote: 1. Win32::GUI team has a look on what is implemented in Win32::GuiTest. Have a look on the manual. It is up to date: http://www.piotrkaluski.com/files/winguitest/docs/index.html . The source code is available at www.sourceforge.net/projects/winguitest. I'll certainly have a look, but it may be a couple of weeks before I get the time to do this. 2. We figure out what is already available and what has to be ported to Win32::GUI (remember about interprocess boundary problems, see the manual, Advanced tutorial). Seems reasonable. 3. Win32::GUI team ads new functions to their module. I think there is a decision to be made between steps 2 and 3. Another possibility would be for the Win32::GuiTest team to take on the responsibility for development of Win32::GUI::Test, possibly even as a separate project, and just use Win32::GUI. It sounds like you don't have much development effort in your group - I'm not sure that we have a whole lot here either. But let's wait and see how much work we think is involved. Just one more think. I believe this discussion is important, since it may have serious impact in both components. Therefore I suggest that we submit all posts to the perl-win32-gui-users@lists.sourceforge.net list and we avoid e-mails sent to individual people directly. It will help others to follow the progress of the discussion. I would suggest moving this discussion to the hackers list which is much more suited for development issues (You will need to subscribe if you have not already). I have set 'Reply-To: [EMAIL PROTECTED]' Regards, Rob.
[perl-win32-gui-users] Re: Attaching to a window created by some other
Jeremy White wrote:
Coincidentally, I've been working on a similar problem and was very
interested
For example:
my $win=Win32::GUI::Window::CreateFromHandle($handle);
$win-Show; #no problem
$win-Hide; #no problem
$win-SomeControl-Show(); #how would we know a control called
'SomeContol' exists?
A control called 'SomeControl' doesn't exist if this is window created
outside Win32::GUI. Navigating the window tree can't be done like this.
You could already do something like this (untested):
my $win = { -handle = 1234 };
bless $win, Win32::GUI::Window; # or other appropriate class
$win-Move( ... ) etc.
You'll need to make sure the you do
$win-{-handle} = undef;
Before $win goes out of scope, to avoid calling the destructor;
although if you're in a different thread to the one that created the
window the DestroyWindow docs say 'A thread cannot use DestroyWindow to
destroy a window created by a different thread' - but don't say what
happens if you try.
Regards,
Rob.
[perl-win32-gui-users] Re: how to get filename of drag-n-dropped file?
Jason P. wrote: Johan Lindstrom wrote: At 12:27 2005-10-11, Pavel Prostine wrote: Hello perl-win32-gui-users is it possible to get name of drag-and-dropped file(s) which I pull from Windows Explorer and drop on Win32-Gui window? See: http://user.bahnhof.se/~johanl/perl/Win32GUI/DragDrop.pm I think (but I'm not sure) that the needed events are present in Win32::GUI nowadays (so you don't need the XS patch), and possibly the methods also. I am fairly certain the XS patch is unneeded as I have not patched my XS :p Just use the PM and have at. Ps- be careful and check the incoming value! The XS patch is not needed, we looked at this on the list sometime back in July. I have created an RFE to add the APIs to Win32::GUI, so that we can do this in the future without Win32::API Regards, Rob.
[perl-win32-gui-users] ANNOUNCE: New Mailing List
There is a new mailing list available: [EMAIL PROTECTED] It is available for anyone to subscribe to, and is a read-only list that provides details of commits made to the Win32-GUI CVS repository. Subscribe at http://sourceforge.net/mail/?group_id=16572 Regards, Rob. -- Robert May Win32::GUI, a perl extension for native Win32 applications http://perl-win32-gui.sourceforge.net/
[perl-win32-gui-users] Web Site Updated
I've just performed an overhaul on the website. (1) All the documentation has moved location. Old URLs should redirect to the new ones. (2) There is a search capability that searches the pages of the site. If it doesn't return what you are looking for, then there is a customised google search available from the search results page - so give that a go. (3) There is a Wiki available. Follow the Wiki link in the navigation menu. There's pretty much no content on it right now, but it's a place where you can make a contribution. Let your fingers do the talking :-) If you use RSS, then you can pick up edits to the wiki from an RSS feed - you'll find the link on the Home page. Otherwise you should recognise it pretty much as before. Please take a look: http://perl-win32-gui.sourceforge.net/ Regards, Rob. -- Robert May Win32::GUI, a perl extension for native Win32 applications http://perl-win32-gui.sourceforge.net/
Re: [win32gui] [perl-win32-gui-users] Treeview CreateDragImage
Jason P. wrote: I have been playing with drag/drop of treeview items and now have a rather slight bit of grievance to clear up: when CreateDragImage is called, it returns the handle, but NOT the actual object. If there is a simple way to create/find the object from the handle, I suppose I could take that route, but others may not be able to make use of this. ** after draft edit** The handle can be used with class methods to create the appropriate actions. All the same, I suppose it might be nice to clarify to other users how this works and/or provide an object for them to work with. I shall provide an example in the near future, as part of a whole. Jason P. There's a demo of this for ListView in the samples folder - I don't remember, but I think I posted it to the list a couple of months back. Regards, Rob. -- Robert May Win32::GUI, a perl extension for native Win32 applications http://perl-win32-gui.sourceforge.net/
Re: [win32gui] [perl-win32-gui-users] Mouse Events Problems
Jason P. wrote: Spawned from [perl-win32-gui-users] How to do While MouseDown, Move Window --- While we're on the subject of these events I'd like to point out that on WinXP SP2/ AS Perl 5.8.7, MRightUp is apparently not firing at all times. If given a fair (say, 1 second) time span, it will indeed fire. If you are fast with your optical mouse, it may not fire at all, leaving you with a constantly stuck down state. Although it RightClick will always fire. Hmm... Anyone else have this problem? Jason P I've not seen it on Win98 or Wink, but don't have XP. Rob. -- Robert May Win32::GUI, a perl extension for native Win32 applications http://perl-win32-gui.sourceforge.net/
Re: [win32gui] RE: [perl-win32-gui-users] Next Release soon
Glenn W Munroe wrote: Rob, I just downloaded the 5.8 PPM from your site. It failed a new dependency check for Test::More. This module is available on CPAN, but not on the ActiveState repository. I had a quick look through the code and couldn't find where it was used; could it be a hangover from some testing you were doing? Is the dependency meant to be there? Is it really necessary? I've a feeling that many people will give up when they can't find the module in the ActiveState repository... Thanks for that spot. I didn't see it as I have Test::More installed - I a bit surprised it's not in the AS repository, but it should be removed from the PPM dependencies, as it's only needed to run the tests if you're building from source. I'll fix it before the real release. Regards, Rob.
Re: [win32gui] [perl-win32-gui-users] TreeView - No DoubleClick Event
Eric Hansen wrote:
Hello,
But I still don't see a Double CLick event for TreeView nodes. This is
greatly needed.
How about this:
#!perl -w
use strict;
use warnings;
use Win32::GUI;
my $mw = Win32::GUI::Window-new(
-title = terminate test,
-pos = [100,100],
-size = [400,300],
);
my $tv = $mw-AddTreeView(
-size = [100,100],
-lines = 1,
-rootlines = 1,
-buttons = 1,
-checkboxes = 0,
-onMouseDblClick = \tvDblClick,
);
my $root = $tv-InsertItem(
-text = Parent,
-indent = 1,
);
$tv-InsertItem(
-parent = $root,
-text = Child 1
);
$tv-InsertItem(
-parent = $root,
-text = Child 2
);
$mw-Show();
Win32::GUI::Dialog();
exit(0);
sub tvDblClick
{
my ($self, $x, $y) = @_; # x,y in client co-ordinates
my $node = $self-HitTest($x,$y);
if($node != 0) {
my %info = $self-GetItem($node);
print Mouse Dbl Click ($node: $info{-text})\n;
}
return;
}
__END__
Regards,
Rob.
--
Robert May
Win32::GUI, a perl extension for native Win32 applications
http://perl-win32-gui.sourceforge.net/
Re: [perl-win32-gui-users] NotifyIcons with Balloon Tips (Win2k/XP -not-9x)
Jason,
Thanks for the code. If this is something that you'd like to see added,
then please raise a RFE at
https://sourceforge.net/tracker/?group_id=16572atid=366572
We'll need to do something to prevent these options killing Win9x boxes,
but I'll be happy to have a look for a future release.
Rob.
Jason P. wrote:
I found this in my draft box from a month or so ago, and thought those
involved in the upcoming release might be interested (or not) in seeing it.
Jason P.
-Original Message-
I cant be perfectly sure of the definition of the NOTIFYICONDATA
structure in place on the sources as of 1.02, but I believe the ability
for the NIF_INFO flag to take effect is not there. That would mean the
the szInfo / szInfoTitle / dwInfoFlags / [uTimeout/uVersion] are not
implemented.
I believe [I can't be sure because I haven't done any XS coding before]
that the following additions to GUI_Options.cpp [circa line 910 as of
1.02 release source] will enable this use after the NOTIFYICONDATA is
updated.
=
} else if(strncmp(option, -balloon, 8) == 0) { //begin
addition
next_i = i + 1;
SwitchBit(nid-uFlags, NIF_INFO, 1);
} else if(strncmp(option, -btinfo, 10) == 0) {
next_i = i + 1;
strcpy(nid-szInfo, SvPV_nolen(ST(next_i)));
SwitchBit(nid-uFlags, NIF_INFO, 1);
} else if(strncmp(option, -bttitle, 10) == 0) {
next_i = i + 1;
strcpy(nid-szInfoTitle, SvPV_nolen(ST(next_i)));
SwitchBit(nid-uFlags, NIF_INFO, 1);
} else if(strncmp(option, -bttimeout, 10) == 0) {
next_i = i + 1;
nid-uTimeout = (UINT) SvIV(ST(next_i));
} else if(strncmp(option, -bticon, 10) == 0) {
next_i = i + 1;
nid-dwInfoFlags = SvIV(ST(next_i));
} //end addition
=
It is possible that MinGW and/or Cygwin dont support the additions in
shell32.dll version 5+. And it is also obviously an issue that these
features would be useless for Win9x boxes.
The structure as per MSDN:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/shell/reference/structures/notifyicondata.asp
---
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
___
Perl-Win32-GUI-Users mailing list
Perl-Win32-GUI-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
http://perl-win32-gui.sourceforge.net/
Re: [win32gui] [perl-win32-gui-users] Toolbar style contants
Chris Wearn wrote: Hi All, Have just downgraded and recompiled latest Win32-GUI from CVS using VC6. Now I get an error can't find TBSTYLE_EX_MIXEDBUTTONS in package blah blah The same if I run the demo toolbar.pl that Rob May posted to the group when experimenting with all the options. Is this something that is missing from Win32-GUI? How do I get around this... use constant or something. Cheers Chris Hi Chris, Do you have a short example that exhibits the problem? I can't duplicate it: #!perl -w use strict; use warnings; use Win32::GUI; print Win32::GUI version: $Win32::GUI::VERSION\n; print Constant TBSTYLE_EX_MIXEDBUTTONS = , TBSTYLE_EX_MIXEDBUTTONS, \n; exit(0); Produces (the same for both Perl 5.6.1 and 5.8.7): C:\WINDOWS\Desktopperl tbstyle.pl Win32::GUI version: 1.0202 Constant TBSTYLE_EX_MIXEDBUTTONS = 8 Does TBSTYLE_EX_MIXEDBUTTONS have a definition in your commctrl.h file? Regards, Rob.
Re: [win32gui] RE: [perl-win32-gui-users] Next Release soon
changes to the timer code that Reini made when he put his tests together, but I can't immediately see anything that would cause this. Typically when I see errors like that it turns out to be a mis-spelled method call or window name, but if that was the case I would expect it to fail in 1.01_01 too. If you can't get a short example to exhibit this problem, can you post the exact error message that you're getting. Rob. -- Robert May Win32::GUI, a perl extension for native Win32 applications http://perl-win32-gui.sourceforge.net/ --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information ___ Perl-Win32-GUI-Users mailing list Perl-Win32-GUI-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users http://perl-win32-gui.sourceforge.net/
Re: [win32gui] [perl-win32-gui-users] Toolbar style contants
Chris Wearn wrote:
Hi Rob,
Have checked my commctrl.h file and it is dated 1998 and stated as being
v1.2
The includes are directly from installing VS98 and SP6
The header file IS missing TBSTYLE_EX_MIXEDBUTTONS. If I define it:
#define TBSTYLE_EX_MIXEDBUTTONS 0x0008 and re-compile, it then
protests that it is missing BTNS_SHOWTEXT.
Clearly the commctrl.h file is out of date. I was under the impression
you were using the same compiler. Can the include headers from .NET be
used. If not how do you update the headers (and what other resources
need to be updated).
I am indeed using the VC 6 compiler, but I am pointing it at the header
files from the latest Platform SDK.
The latest SDK can be downloaded from MS at:
http://www.microsoft.com/downloads/details.aspx?FamilyId=A55B6B43-E24F-4EA3-A93E-40C0EC4F68E5displaylang=en
I downloaded the ISO image (~400MB) and burned a CD, but there are other
options - see links on the page.
You then need to set up your environment variables (INCLUDE and LIB) to
point to the correct SDK directories before the VC98 directories.
I tried the Win32api includes from MinGW, however BTNS_SHOWTEXT was not
found in commctrl.h from MinGW either.
What version of MinGW headers? Latest is 3.2 (look in w32api.h to find
your current version), and that has it defined.
An example that exhibits this is the toolbar.pl script you sent me
(attached).
There are 2 ways to deal with this:
(1) Upgrade to the latest headers
(2) Add code like
#ifndef
#define Y
#endif
to GUI.h. My preference would be not to bloat GUI.h
(3) Add code like
sub () {Y}
to the start of your script - although you might have to turn off
warnings to avoid message about redefinition of function calls (untested)
I think Jez is in the same boat, as he couldn't run the script either,
the other day without the same error.
I know from previous discussions with Jez that he's using quite an old
MinGW build.
Regards,
Rob.
--
Robert May
Win32::GUI, a perl extension for native Win32 applications
http://perl-win32-gui.sourceforge.net/
Re: [win32gui] [perl-win32-gui-users] Extened windows style
[EMAIL PROTECTED] wrote: I'm trying to create a window that will show up on the right side of my screen and always be visible. $MainWin = new Win32::GUI::Window( -name = MainWin, -pos = [1240,0], -size = [40,990], -maxsize = [40,990], -minsize = [40,990], -pushexstyle = WS_EX_TOPMOST WS_EX_TOOLWINDOW, You probably mean -pushstyle = WS_EX_TOPMOST | WS_EX_TOOLWINDOW, although -topmost = 1, -toolwindow = 1, is easier. ); The problem I'm having is that when I maximize the window of any other application it has part of it hidden by this window, usually the scroll bar. Is there an option to set so that anytime I maximize another window it will take up the entire screen minus this window? I'm sure there is, but don't know how myself. Perhaps someone else can shed some light? Regards, Rob. -- Robert May Win32::GUI, a perl extension for native Win32 applications http://perl-win32-gui.sourceforge.net/
Re: [perl-win32-gui-users] Toolbar style contants
Chris Wearn wrote: What version of the Platform SDK are you using Rob? Win2003 sp1, downloaded in June of this year. I do remember having to play with removing a few of the new SDK tools (nmake for example) as the new ones don't play well with W98, but I'm afraid that I don't have any notes on anything else I may have done. If you post the error messages you are getting I may be able to help further. Regards, Rob.
Re: [perl-win32-gui-users] Help Required in installing Win32-GUI
Pavan Rao wrote: I have downloaded Win32-GUI-1.02.tar file from cpan.org http://cpan.org website.I am trying to install this and i am not able install it its giving an error message.Could any one of you tell the excat steps to install this successfully.I am using 5.8.7.813 version of perl. As Jeremy already said, the easiest way to install this is using PPM: For Perl 5.8 there is a binary distribution of V1.02 in the Activestate (default) PPM repository. Otherwise there are binary distribution available from our website at http://perl-win32-gui.sourceforge.net If you really want to build from source (and it's not that hard), then have you followed the instructions in the README that comes with the distribution? Is so, which step fails? What is the error message that you get? A little more detail and we'll be able to help you. Good luck, let us know how you get on. Regards, Rob. -- Robert May Win32::GUI, a perl extension for native Win32 applications http://perl-win32-gui.sourceforge.net/
[perl-win32-gui-users] Re: Next Release soon
Glenn W Munroe wrote: I just downloaded the 5.8 PPM from your site. It failed a new dependency check for Test::More. This module is available on CPAN, but not on the ActiveState repository. I had a quick look through the code and couldn't find where it was used; could it be a hangover from some testing you were doing? Is the dependency meant to be there? Is it really necessary? I've a feeling that many people will give up when they can't find the module in the ActiveState repository... [snip] I hit another more worrying problem: I have a large-ish program, which uses a number of timers. With 1.02_02 I get an error whenever any one of the timers tries to fire (Can't locate auto/tmList.al in @INC...). I have fixed both of these issues (I think). You can find PPMs (Perl 5.6 and 5.8) at http://www.robmay.me.uk/win32gui/ These PPMs are labeled as version V1.02_03, and reflect the current CVS code-base. You should consider them beta software (i.e. they may not work properly), but I have been using the 5.8 code for some time now with no problems. If you are so inclined, then download and give it a spin. Feedback to this list please. Regards, Rob. -- Robert May Win32::GUI, a perl extension for native Win32 applications http://perl-win32-gui.sourceforge.net/
Re: [win32gui] Re: [perl-win32-gui-users] TK to Win32-GUI, Win32-GUI to TK utilities
Glenn Linderman wrote: Eric Hansen: Can someone provide me with the TK to Win32-GUI, Win32-GUI to TK utilities? I don't know of any such, do you? I'm assuming you mean source code translators... Ditto. If such tools do exist, then they've evaded my googling. I'd be interested in seeing such tools if anyone finds them. Rob. -- Robert May Win32::GUI, a perl extension for native Win32 applications http://perl-win32-gui.sourceforge.net/
[perl-win32-gui-users] Re: Control Resize
Johan Lindstrom wrote:
At 16:54 2005-11-17, Glenn W Munroe wrote:
The main window of my current project comprises a Grid control and a
TreeView, in a Windows Explorer-like layout. I would like to provide
the option of being able to resize the two controls by
click-and-dragging the area between the two. Does anyone have any tips
on how to do this? I tried adding a -resizable = 1 option to the
TreeView, but that would have been too easy! (It didn't work, of
course). I imagine it makes use of the MouseOver et al. events, but
the documentation is a bit thin on those events. Do I have to put
another control (a 1-pixel-wide button perhaps?) between the two to
get at the events? As usual, an example would be worth a thousand words…
Use the Splitter control.
You beat me to it!
Perl Oasis uses this for an example:
http://user.bahnhof.se/~johanl/perl/Oasis/download.html
For a smaller and more focused example, download The GUI Loft
http://user.bahnhof.se/~johanl/perl/Loft/
and look at the Demo/FileDisplay(manual_resize) example. The purpose of
that demo is exactly what you're after.
For the record, here's a short example that shows it working with 2
Textfield controls.
Regards,
Rob.
#!perl -w
use strict;
use warnings;
use Win32::GUI;
my $mw = Win32::GUI::Window-new(
-title = Splitter Test,
-pos = [100,100],
-size = [500,400],
-onResize = \main_resize,
);
$mw-AddTextfield(
-name = TF1,
-multiline = 1,
-width = 200,
);
$mw-AddSplitter(
-name = SP,
-left = 200,
-width = 2,
-onRelease = \do_splitter,
);
$mw-AddTextfield(
-name = TF2,
-multiline = 1,
-left = 200 + $mw-SP-Width(),
);
$mw-Show();
Win32::GUI::Dialog();
exit(0);
# NEM splitter event gets 2 parameters. The first (as always)
# is the window object the wvwnt came from - in this case the
# splitter window; The second depends on the splitter orientation:
# if horzontal it is the top coordinate; if vertical it is
# the left coordinate. (coordinates relative to the parent's
# client area)
# The splitter window is moved by the splitter object, so you only
# have to re-position your other windows
sub do_splitter
{
my ($splitter, $coord) = @_;
$mw-TF1-Width($coord);
$mw-TF2-Move($coord+$mw-SP-Width(), 0);
$mw-TF2-Resize($mw-ScaleWidth()-$mw-SP-Width(),
$mw-ScaleHeight());
}
sub main_resize
{
my $self = shift;
$mw-TF1-Height($self-ScaleHeight());
$mw-SP-Height($self-ScaleHeight());
$mw-TF2-Resize($mw-ScaleWidth()-$self-TF1-Width()-$mw-SP-Width(),
$mw-ScaleHeight());
}
__END__
--
Robert May
Win32::GUI, a perl extension for native Win32 applications
http://perl-win32-gui.sourceforge.net/
Re: [win32gui] RE: [perl-win32-gui-users] DIBitmap odd resize behaviour with TIFFs?
Jeremy White wrote: Just a general follow up - we (everyone involved with Win32-GUI) now maintain DIBitmap (as well as AxWindow, Grid and Scintilla). DIBitmap currently uses FreeImage 3.5.1, with the latest version being 3.8.0 - see http://freeimage.sourceforge.net/ There seems to be quite a few changes between the two versions which may, or may not fix your issue. Ideally we need a DIBitmap Champion who's role would be to maintain and enhance DIBitmap (the same goes for Laurent's other modules). If anyone is interested, the source is available at http://cvs.sourceforge.net/viewcvs.py/perl-win32-gui/ If anyone is interested in championing DIBitmap, then please get in touch with Jeremy or me. [EMAIL PROTECTED] Thanks, Rob. -- Robert May Win32::GUI, a perl extension for native Win32 applications http://perl-win32-gui.sourceforge.net/
[perl-win32-gui-users] Re: Splitter control [DC bug?]
I raised tracker 1363141 for this. Thanks for the report.
Rob.
Plum, Jason wrote:
Hey all,
Ariel Serbin and I have notice something strange occurring with the
splitter demo, and specifically the splitter control itself.
Run the script attached, a previous post contained it. Then, drag the
splitter to the left a short distance, then back to the right and equal
amount. You’ll notice that there is a nasty artifact showing up on the
screen. Of course when your test in the text field overlaps this
artifact, it is resolved within the relative area of the text [Rob and
all may know the proper names, but unfortunately I’m not that in depth].
I believe it has something to with the underlying DC objects that are
drawing the splitter control, but am fully aware that I don’t have the
understanding to fix this.
WinXP SP2, AS 5.8.7, Win32-GUI 1.02 and Win32-GUI 1.02_03 this occurs.
Jason P.
Note: For ease of replicable visibility, we’ve widened the splitter
control in the code below.
--CODE—
#!perl -w
use strict;
use warnings;
use Win32::GUI;
my $mw = Win32::GUI::Window-new(
-title = Splitter Test,
-pos = [100,100],
-size = [500,400],
-onResize = \main_resize,
);
$mw-AddTextfield(
-name = TF1,
-multiline = 1,
-width = 200,
);
$mw-AddSplitter(
-name = SP,
-left = 200,
-width = 10, #FATTY
-onRelease = \do_splitter,
);
$mw-AddTextfield(
-name = TF2,
-multiline = 1,
-left = 200 + $mw-SP-Width(),
);
$mw-Show();
Win32::GUI::Dialog();
exit(0);
# NEM splitter event gets 2 parameters. The first (as always)
# is the window object the wvwnt came from - in this case the
# splitter window; The second depends on the splitter orientation:
# if horzontal it is the top coordinate; if vertical it is
# the left coordinate. (coordinates relative to the parent's
# client area)
# The splitter window is moved by the splitter object, so you only
# have to re-position your other windows
sub do_splitter {
my ($splitter, $coord) = @_;
$mw-TF1-Width($coord);
$mw-TF2-Move($coord+$mw-SP-Width(), 0);
$mw-TF2-Resize($mw-ScaleWidth()-$mw-SP-Width(),
$mw-ScaleHeight());
}
sub main_resize
{
my $self = shift;
$mw-TF1-Height($self-ScaleHeight());
$mw-SP-Height($self-ScaleHeight());
$mw-TF2-Resize($mw-ScaleWidth()-$self-TF1-Width()-$mw-SP-Width(),
$mw-ScaleHeight());
}
__END__
