[perl-win32-gui-users] Timers?
I guess this list is new, and the archive not accessible yet, so my apologies if my question has been asked before. I've just "discovered" Win32::GUI, and think it is just great to be able to write Windows GUI programs using perl. So I had a couple applications in mind, and started writing! It seems that Win32::GUI is quite strong enough to handle the first one completely, although I've not yet finished the complete program, I've finished most of the user interface. The other one needs to do some background monitoring, in addition to supporting a user interface. To do that, it seems like a timer would be the documented metaphor for doing such monitoring using the Win32::GUI package. I attempted to initiate a timer, and got an error about "Your vendor hasn't supplied a timer...", so either I must have done something wrong (quite possible) or Timer maybe isn't supported yet in Win32::GUI? Does someone know for sure if Timer is supported? Does someone have some code that illustrates a working Timer? Maybe I just went about it all wrong. -- Glenn = Even if you're on the right track, you'll get run over if you just sit there. -- Will Rogers
[perl-win32-gui-users] Fork?
Hi, I'm interested to know if there are any "best practices" for communicating between two perl-forked threads when one of the threads is running Win32::GUI::Dialog. Is there a way for the non-gui threads to send a Windows event to the gui thread? And how would the gui thread receive it? Or is there some other way that should be used by the gui thread to poll the status of the other thread? Is non-blocking I/O the right way to do that, on a pipe? -- Glenn = Even if you're on the right track, you'll get run over if you just sit there. -- Will Rogers
Re: [perl-win32-gui-users] Fork?
Tom Allebrandi wrote: > With regards to fork() and Win32::GUI > > I have been playing with this as well, and while I have not arrived at a > "best practices" I have arrived at a baseline that works. Basically, I fork > the gui thread and then send window messages to it, or, call the appropriate > function on the window object I want to manipulate in a "classless" way. Now this is a clever idea. I think that for the particular application I am working on, that this technique, or a variation, might suffice. Even without Timer to do polling. > For example, if you had created a progress bar control, you would normally > call it using > > $progressControl->somefunction(); > > that is > > $progressControl->SetPos($amount); > > As it turns out, and I don't know if Aldo intended for it to work this way, > if you have a handle to the control, you can also call the routine in the > "classless" way by doing > > GUI::ProgressBar::SetPos($progressControlHandle,$amount)); Well, I suspect it was intended to work that way, because it is documented (see the tutorial for how to eliminate the console window) that the methods can be called on any window, using the classless technique. Now a window created by one thread's Win32::GUI is, to another thread, simply one of "any" windows. But I hadn't put that information together that way, so I appreciate your helping to overcome my mental block. > The latter is the way I talk to the controls from the thread that is not > running Win32::GUI::Dialog. > > Right now, I am locating the window handle for the dialog itself using > GUI:FindWindow() in the non-gui thread. I'm not happy with this approach, > and am looking at other solutions as well. Sure. I wonder what would happen if a widget (progressbar or whatever) were created before the fork, if the class handles would be active for both after the fork? Of course, only the thread that called Win32::GUI::Dialog would see the messages and act on them... but that's precisely the desired behavior. Not sure what all sorts of timing/data race conditions doing that sort of thing would produce, but I may experiment with it some. > Amine Moulay Ramdane's Win32::MemMap package > (http://www.generation.net/~aminer/Perl/) looks like the right solution for > this, at least for me, but I had a problem with it when I tried to use it > and ran out of time to mess with it. I know he recently posted an updated > version, I need to pull that down and see if it still has the same problem. > > My initial need was to not have to use GUI::FindWindow() to locate the > dialog and controls. My thought was to serialize a hash in the gui thread > and pass it back to the non gui thread via shared memory - which > Win32::MemMap provides, and unserialize on the non gui side. > > You can probably do something similar with pipes, but for some reason, I > thought that the shared memory approach looked better. Shared memory vs. pipes vs. files even -- I'm indifferent to the bulk-data communication channel. But the thing that had me stumped was how to get the GUI process to "wake up and smell the roses" based on some outside event that doesn't manifest itself as a window message to one of the window processes... and you've relieved me of that mental block. So, a general communication mechanism can likely be created, at worst by creating a special widget in the GUI to which events can be posted from a thread which has the responsibility of monitoring the non-GUI world. Shucks, speaking of shared memory, one could even have a hidden text widget (or two) into which the data of interest gets sent. Shared memory may be fastest, of course. > I suspect that I've rambled on enough for one day. I've included in this > message a script for a progress bar that runs in a thread by itself taking > positioning commands from another thread. > > Oh, by the way, in response to another message on the list today, I think > Win32::MemMap has a timer implementation in it. But is that timer integrated into Win32::GUI? Is it clear how well it would interact with Win32::GUI? I'll be taking a look at MemMap. Thanks for your response. -- Glenn = Even if you're on the right track, you'll get run over if you just sit there. -- Will Rogers
Re: [perl-win32-gui-users] Fork?
Eric Bennett wrote: > On Wed, 28 Feb 2001, Tom Allebrandi wrote: > > > As it turns out, and I don't know if Aldo intended for it to work this way, > > if you have a handle to the control, you can also call the routine in the > > "classless" way by doing > > > > GUI::ProgressBar::SetPos($progressControlHandle,$amount)); > > > > The latter is the way I talk to the controls from the thread that is not > > running Win32::GUI::Dialog. > > What advantage does this give you? The -> form searches the @ISA class > hierarchy but once it finds the function the two forms are equivilent. > Is there something about use of threads which forbids object syntax? The > object form is safer and seems cleaner to me. The object syntax requires an object handle. It isn't clear to me how to obtain an object handle for a window created in one thread/process that can be used in a different thread/process. Perhaps, but I haven't experimented yet, if the two processes are the result of a fork after the object handle is obtained, that it would work to a certain degree, but perhaps not. The non-object syntax can be used by any thread/process on any window to which it can obtain a Windows window handle. Including windows created by Win32::GUI. Hnece the non-object syntax is more powerful. -- Glenn = Even if you're on the right track, you'll get run over if you just sit there. -- Will Rogers
Re: [perl-win32-gui-users] Fork?
Tom Allebrandi wrote: > The problem here I think is that what we are commonly referring to as a > "thread", isn't. It must be viewed as if it is a separate process. Well, from Windows point of view, it is a thread. From Perl's point of view, it is a process. The Perl interpreter is busily keeping the data separate between the two threads (I'm not sure I understand the complete technique of the magic that does that, but I'm sure it can be made to work because the Perl language doesn't expose "real" addresses (much)). On the other hand, the (Unix) model for "fork" is that the multiple processes (threads on Perl for Windows) start off with identical data/variables/file handles. And the Windows model for "windows" is that the windows are owned by a process (not a thread), and can be accessed by any thread that has the window handle. (And in fact, because Windows was developed on DOS, the windows are even a bit visible to other processes, but that doesn't concern us here.) So, I earlier alluded to some experimentation I was going to try... read on. > If you create an object in one "thread" (process), it does not exist in the > other "thread" (process). I can't see any way to use the object syntax on an > object that was not created in my "thread" (process). Maybe I missed > something along the way. By creating the Win32::GUI objects before forking, both the parent and child threads get copies (?) of the object variables. Because of the nature of Windows, the embedded Window handles inside both copies of the object variables are equally usable. Because of the (present) nature of Win32::GUI, whereby most of the parameter data is pumped into Win32 API parameters, and most of the return values are obtained by calling Win32 APIs to obtain it, I have shown experimentally that it is possible to use the Win32::GUI object references from both a parent and a child thread. Now it is important to remember that Windows only delivers window messages to the first thread of a program, so in the Perl "fork" environment, this gets translated to only the parent process of a group of Perl-forked processes can successfully run Win32::GUI::Dialog (Yep, I tried it the other way first, figuring that the parent could more easily monitor the child process for death, since fork returns the child pid, and waitpid works that way--but it just hung, and the windows never appeared). However, the child can use the object references created by Win32::GUI to access the "IsEnabled", "IsVisible" attributes of the window widgets, and they are dynamically updated (not cached in the object). The child can access the current selection from combo boxes. The child can enable and disable widgets, and the display gets updated appropriately. This is quite adequate for my application, which now can do its "long" operations in the child "process", and keep the GUI window "active" (except that certain parts get disabled during "long" operations). Thanks again, Tom, for broadening my outlook regarding Win32::GUI. Perhaps I've now returned the favor? -- Glenn = Even if you're on the right track, you'll get run over if you just sit there. -- Will Rogers
[perl-win32-gui-users] Textfield question
Hi, I'm a Perl expert, but a Windows novice. I'm using the .558 version of Win32::GUI, and having great success for the most part. There are some rough edges, and some apparently missing pieces, but no showstoppers so far, to achieve what I need. I created a Textfield as $help_text = $neww -> AddTextfield ( -name => 'help_text', -text => "This is not very\r\nhelpful, yet.", -multiline => 1, -readonly => 1, -vscroll => 1, -top => $lastbottom, -left => 0, -width => 600, -height => 190, ); The -vscroll doesn't seem to have any affect. When I later $help_text -> Text ( $long_string ); and use a string that is longer than fits in the Textfield, I expected, but did not get, a vertical scroll bar on the right of the Text field. Any easy way to make that happen? Or must I limit my help text to the available space? I tried using RichEdit instead, but it doesn't seem to honor -readonly, and doesn't display a scrollbar either. Although it did do scrolling of sorts, via the up & down cursor keys... but it seemed to only scroll in "whole field size" jumps, not line at a time. Going back to the Textfield, I tried clicking on it and using the up & down cursor keys, but no joy. If there is no easy way, does someone have sample code for the hard way? -- Glenn = Even if you're on the right track, you'll get run over if you just sit there. -- Will Rogers
Re: [perl-win32-gui-users] Textfield question
Pete, Thanks for the idea. I added your suggestion, minus the WS_HSCROLL (I want wrapping to take effect). It does produce a scroll bar. It removes the effect of -readonly, but since I never look at the resulting text, and refresh it on the next display, that isn't terribly problematical. Perhaps I'll diddle around and find something that turns -readonly back on. Perhaps another -style flag? Peter Eisengrein wrote: > Not sure if the -style flag works on textfields but it does on RichEdits and > that might be what's missing. Try adding this to your Textfield hash: > > -style => WS_CHILD | WS_VISIBLE | WS_VSCROLL | WS_HSCROLL > | ES_LEFT | ES_MULTILINE, > > -Pete > > -Original Message- > From: Glenn Linderman [mailto:[EMAIL PROTECTED] > Sent: Wednesday, March 07, 2001 12:31 PM > To: perl-win32-gui-users@lists.sourceforge.net > Subject: [perl-win32-gui-users] Textfield question > > Hi, > > I'm a Perl expert, but a Windows novice. I'm using the .558 version of > Win32::GUI, and having great success for the most part. There are some > rough > edges, and some apparently missing pieces, but no showstoppers so far, to > achieve what I need. > > I created a Textfield as > > $help_text = $neww -> AddTextfield ( > -name => 'help_text', > -text => "This is not very\r\nhelpful, yet.", > -multiline => 1, -readonly => 1, -vscroll => 1, > -top => $lastbottom, -left => 0, -width => 600, -height => 190, > ); > > The -vscroll doesn't seem to have any affect. When I later > > $help_text -> Text ( $long_string ); > > and use a string that is longer than fits in the Textfield, I expected, but > did not get, a vertical scroll bar on the right of the Text field. Any easy > way to make that happen? Or must I limit my help text to the available > space? > > I tried using RichEdit instead, but it doesn't seem to honor -readonly, and > doesn't display a scrollbar either. Although it did do scrolling of sorts, > via the up & down cursor keys... but it seemed to only scroll in "whole > field > size" jumps, not line at a time. Going back to the Textfield, I tried > clicking on it and using the up & down cursor keys, but no joy. > > If there is no easy way, does someone have sample code for the hard way? > > -- > Glenn > = > Even if you're on the right track, > you'll get run over if you just sit there. >-- Will Rogers > > ___ > Perl-Win32-GUI-Users mailing list > Perl-Win32-GUI-Users@lists.sourceforge.net > http://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users > > ___ > Perl-Win32-GUI-Users mailing list > Perl-Win32-GUI-Users@lists.sourceforge.net > http://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users -- Glenn = Even if you're on the right track, you'll get run over if you just sit there. -- Will Rogers
Re: [perl-win32-gui-users] use of Pos method
"Moore, Larry" wrote:
> ->Select() doesn't work, I tried it, because $updown1 and $updown2 are
> UpDown objects and Pos is the method for this object. If I comment out the
> two lines which set the Pos, then the program dies immediately.
I suspect this latter death is caused by the lack of an appropriate return
value. Event subs return -1/0/1 to result in death/no action/default action
respectively.
When you comment out Pos, the return value is $sel, which is -1 if nothing is
selected
I haven't played with UpDown yet, I'm interested to watch future responses in
this thread.
>
>
> Larry
>
> -Original Message-
> From: Peter Eisengrein [mailto:[EMAIL PROTECTED]
> Sent: Thursday, March 08, 2001 2:34 PM
> To: 'perl-win32-gui-users@lists.sourceforge.net'
> Subject: RE: [perl-win32-gui-users] use of Pos method
>
> Do you want ->Pos() or ->Select()? I suspect you probably want the latter.
>
> -Original Message-
> From: Moore, Larry [mailto:[EMAIL PROTECTED]
> Sent: Thursday, March 08, 2001 1:49 PM
> To: 'perl-win32-gui-users@lists.sourceforge.net'
> Subject: [perl-win32-gui-users] use of Pos method
>
> I have two listboxes each as the Buddy to an UpDown object.
>
> I want to synchronize the selected item for the two listboxes.
>
> I use two click event subroutines to allow selection in the list, as well as
> two scroll events. I get an error message saying that the Pos method is not
> available in my click subs, but after responding ok to these two messages,
> one for each sub, my code seems to perform as I expect. What am I doing
> wrong? Here is the code:
>
> sub ud1_Scroll {
> geo_codes_Click();
> }
>
> sub ud2_Scroll {
> geo_names_Click();
> }
>
> sub geo_codes_Click {
> $sel = $geo_codes->SelectedItem();
> $updown2->Pos($sel);
> }
>
> sub geo_names_Click {
> $sel = $geo_names->SelectedItem();
> $updown1->Pos($sel);
> }
>
> Tks,
> Larry
>
> ___
> Perl-Win32-GUI-Users mailing list
> Perl-Win32-GUI-Users@lists.sourceforge.net
> http://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
>
> ___
> Perl-Win32-GUI-Users mailing list
> Perl-Win32-GUI-Users@lists.sourceforge.net
> http://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
>
> ___
> Perl-Win32-GUI-Users mailing list
> Perl-Win32-GUI-Users@lists.sourceforge.net
> http://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
--
Glenn
=
Even if you're on the right track,
you'll get run over if you just sit there.
-- Will Rogers
[perl-win32-gui-users] Bug in Textfield scrolling
Hi, Once I actually got 0.0.558 installed (no clue what version ActiveState's ppm gets by default) a number of things started working better for me. (no surprise there, I suspect). However, I note that scrolling doesn't work in Textfield items... the top/bottom line of text doesn't get erased during the scroll, and the new line overwrites it. This is pretty consistent for most ways you can scroll, except that clicking in the empty area of a scrollbar to scroll down actually works. Perhaps doing that to scroll up would also work, if I had enough data to have a whole page worth the scroll up to. Fortunately, scrolling seems to work in RichEdit, so I switched. I'm sure there is a performance penalty for switching to RichEdit, but an a GHz machine, it isn't noticable. -- Glenn = Even if you're on the right track, you'll get run over if you just sit there. -- Will Rogers
Re: [perl-win32-gui-users] icons for every occasion
I have some answers, but I don't know for sure what your questions are. It would help if you use well-defined terminology. Someone may be more knowledgable about Windows than me, and provide better answers, but here's what I know. christopher sagayam wrote: > Is it possible to create different icons for different occasions for the > same win32 gui script.. Yes. But you have to detect the occasions yourself. > if so please give me sample code Don't have sample code. > The occasions are > > 1. In the desktop ( as shortcut) Windows properties allows you to choose any icon for any shortcut, whether it is related to the launch program or not. Create the shortcut, pop up the properties window, shortcut tab, "Change icon". From the docs it looks like the Win32::Shortcut package could also be used to achieve that same end. > 2. When it is minimized on the bottom bar Whatever the "bottom bar" is? I assume you mean the Windows task bar (although you use that term later, to maybe mean something else?) This is the same icon as is used for the window itself, when the window is open. The task entry is visible in the task bar when the window is open, as well as when it is minimized. You can change the icons when you get a "_Minimize" event if you want, and change it again on "_Maximize" or "_Resize", or "_Activate" events, which may achieve your goals, but would not give a consistent icon in the task bar for the duration of the program, as is typical for windows programs. > 3 when the window is open Just call $my_window -> SetIcon with appropriate parameters > 4 When the window is made a small icon on the Task bar Again, this isn't clear. Perhaps you mean in the "system tray"? In which case you would use the Win32::GUI::NotifyIcon features. > 5 When the script file is seen under windows explorer file listing The icon here is derived from the program that is used to "open" the script file by default. You may have to make an extra copy of perl and change its default icon to achieve this one. You'd also have to rename your script files for which you want a "different than the perl icon" icon, to have a unique extension, to which you define the association to the extra copy of perl. > if I have 5 different icon images how to insert them into the code > apprpriately ? > > chris > > ___ > Perl-Win32-GUI-Users mailing list > Perl-Win32-GUI-Users@lists.sourceforge.net > http://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users > > ___ > Perl-Win32-GUI-Users mailing list > Perl-Win32-GUI-Users@lists.sourceforge.net > http://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users -- Glenn = Even if you're on the right track, you'll get run over if you just sit there. -- Will Rogers
[perl-win32-gui-users] Windows newbie question
Hi, I've got another "newbie" question about Windows programming. I wrote a nice Win32::GUI program that launches itself from the Startup folder into the system tray, using NotifyIcon, and then pops open by clicking on it, etc. However, I don't know how to make the program cooperate with Windows Shutdown. Without any special (event?) handling, when I initiate a shutdown from the start menu (in Win98, at least) I get a dialog box informing me that I must shut this program down before I can shut down windows. And then, when I click OK to that, I get another informing me that Windows doesn't know how to shut down this program, do I want to Wait, End Task, or Cancel?. So I pressed End Task and it shutdown, but clearly that isn't the right process. The right process would not include either dialog box. How do I get rid of them? -- Glenn = Even if you're on the right track, you'll get run over if you just sit there. -- Will Rogers
Re: [perl-win32-gui-users] localtime($file->{'mtime'}) problem
Jeremy,
I can't see that jb's code does much different than yours. I think the real
problem is a basic Perl issue that you have missed: "-M $file" (or, apparently,
"$file->{'mtime'}", with which I have no experience) returns the timestamp of
$file as a difference between the actual timestamp and the start time of the
perl session.
Therefore, most files that existed before you started your script will have
negative values for "-M $file".
Knowing that the Unix and Perl clocks start in 1970, it would seem that "69" is
probably a result of a negative number being passed to localtime, which is
consistent with the way "-M $file" works.
You might want to add in $^T before converting to a text date. Note that even
the Perl 5 Pocket Reference documents this. However, perhaps the documentation
for "$file->{'mtime'}" is not clear, I've not looked at it.
[EMAIL PROTECTED] wrote:
> Jeremy,
>
> While we are willing to help, your questions are more appropriate for the
> Perl-Win32-Users mailing list. The Perl-Win32-GUI mailing list is
> specifically for the Win32::GUI module. You can sign up for the
> Perl-Win32-Users mailing list using the following link:
> http://mailarchive.activestate.com
>
> Someone posted the following code for handling dates and I've found it very
> useful.
>
> sub get_date {
> # Define arrays for the day of the week and month of the year.
> @days =
> ('Sunday','Monday','Tuesday','Wednesday','Thursday','Friday','Saturday');
> @months =
> ('January','February','March','April','May','June','July','August','Septembe
> r','October','November','December');
> # Get the current time and format the hour, minutes and seconds. Add
> # 1900 to the year to get the full 4 digit year.
> ($sec,$min,$hour,$mday,$mon,$year,$wday) =
> (localtime(time))[0,1,2,3,4,5,6];
> $time = sprintf("%02d:%02d:%02d",$hour,$min,$sec);
> $year += 1900;
> # Format the date.
> $date = "$days[$wday], $months[$mon] $mday, $year at $time";
> }
>
> jb
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of
> Jeremy Aiyadurai
> Sent: Wednesday, April 04, 2001 12:57 AM
> To: perl-win32-gui-users@lists.sourceforge.net
> Subject: [perl-win32-gui-users] localtime($file->{'mtime'}) problem
>
> hi
>
> i am having a problem getting proper modified time dates of files when
> using the win32:Internet ftp list, or the standard directory listing
>
> i do this
> ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) =
> localtime($file->{'mtime'});
>
> then for each file i do something like this
>
> print "$year/$mon/$mday $file->{'name'});
>
> for every file, i end up getting a modified date of 69/11/31 thefile
>
> eg;
>
> 69 - 11 - 31 bbsetup.exe144152 bytes
> 69 - 11 - 31 clients.pl 29 bytes
>
> ___
> Perl-Win32-GUI-Users mailing list
> Perl-Win32-GUI-Users@lists.sourceforge.net
> http://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
>
> ___
> Perl-Win32-GUI-Users mailing list
> Perl-Win32-GUI-Users@lists.sourceforge.net
> http://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
>
> _
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
>
> ___
> Perl-Win32-GUI-Users mailing list
> Perl-Win32-GUI-Users@lists.sourceforge.net
> http://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
--
Glenn
=
Even if you're on the right track,
you'll get run over if you just sit there.
-- Will Rogers
Re: [perl-win32-gui-users] Driving windows applications.
Win32::GuiTest might do the trick for you. Certainly it can send keystrokes to other windows. SSGT Steven Swenson wrote: > > Can Win32::Gui be used to automate another windows application? > > I need to be able to supply keystrokes to another application and check > check boxes make selections in list boxes and radio buttons as well.. > > Anyone have a simple example of such a script? If Win32::GUI is not the > right place can you suggest another module that may help? I have heard of > Win32::Setupsup but PPM won't install it. I am using perl win32 5.6. > > This is perl, v5.6.1 built for MSWin32-x86-multi-thread > (with 1 registered patch, see perl -V for more detail) > > Copyright 1987-2001, Larry Wall > > Binary build 626 provided by ActiveState Tool Corp. > http://www.ActiveState.com > Built 01:31:15 May 2 2001 > > ___ > Perl-Win32-GUI-Users mailing list > Perl-Win32-GUI-Users@lists.sourceforge.net > http://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users -- Glenn = Due to the current economic situation, the light at the end of the tunnel will be turned off until further notice.
Re: [perl-win32-gui-users] Taskbar & perl2exe -gui crash
Indeed, this works. I've long wondered about a way to do it, and I've now
incorporated this into my (only) Win32::GUI program. I am planning to write
some more Win32::GUI programs soon. It seems, though, that this solution isn't
completely general. While I don't personally use it anymore, I recall MS Office
had an optional taskbar that could be docked similarly to the Windows taskbar.
And some laptops have "power management toolbars". etc.
Does anyone know of a more general technique for avoiding all the
toolbars/taskbars that might nibble away at the edges of the desktop?
"Piske, Harald" wrote:
> $_ = Win32::GUI::FindWindow ("Shell_TrayWnd", "");
> @_ = Win32::GUI::GetWindowRect ($_);
>
> $width = $_[2] - $_[0];
> $height = $_[3] - $_[1];
>
> tested on Win2k and Win98. Interestingly, the position of the taskbar is
> slightly off the screen (-2).
>
> Note that the taskbar can be moved to each of the four window edges (eight
> on dual-screen, which would look like off the desktop), so don't put your
> program fixed at (0,0). I have mine upright at the left side instead of flat
> at the bottom. If it takes up less of the vertical extend, which programs
> use for status bars, tool bars, menu bars and so on. Take web browsers for
> instance. Web pages are usually longer than the screen height but less wide
> than the screen width.
>
> Have fun,
> Harald
>
> | -Original Message-
> | From: Webmaster CZ [mailto:[EMAIL PROTECTED]
> | Sent: Wednesday, May 23, 2001 12:51
> | To: perl-win32-gui-users@lists.sourceforge.net
> | Subject: [perl-win32-gui-users] Taskbar & perl2exe -gui crash
> |
> |
> | Hi !
> |
> | I have two problems:
> |
> | a)
> | My program start in maximal width & height with this code:
> |
> | -Code
> | $screensize= Win32::GUI::GetDesktopWindow();
> | $screensize_width = Win32::GUI::Width($screensize);
> | $screensize_height = Win32::GUI::Height($screensize);
> | -Code
> |
> | The problem is, that i must subtract the size of the Taskbar...
> | so how can i read the size (height) of it
> |
> |
> | b)
> | If i compile my program with perl2exe and "-gui", then the
> | program crash on exit ever: the "exit code" are:
> |
> | ---Code---
> | sub Window_Terminate {
> | return -1;
> | }
> |
> | sub Exit_Click {
> | return -1;
> | }
> | Code-
> |
> | Any idea ???
> |
> |
> |
> | cu
> | Thorsten Sommer
> |
> |
> | ___
> | Perl-Win32-GUI-Users mailing list
> | Perl-Win32-GUI-Users@lists.sourceforge.net
> | http://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
> |
>
> ___
> Perl-Win32-GUI-Users mailing list
> Perl-Win32-GUI-Users@lists.sourceforge.net
> http://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
--
Glenn
=
Due to the current economic situation, the light at the
end of the tunnel will be turned off until further notice.
Re: [perl-win32-gui-users] Taskbar & perl2exe -gui crash
By "more general", I was looking for "all toolbars that are docked to the edge
of the screen".
I'm pretty much a Windows-idiot, although pretty good at programming generic
Perl, so I'm still stumbling over the Windows terminology.
So how do you tell if a windows is "topmost"? Maybe "all toolbars that are
docked to the edge of the screen" is somewhat equivalent to "all topmost windows
that abut an edge of the screen and are really long and thin" ??? Maybe "abut
an edge" means within "0 to -5 pixels" of the edge ??? Maybe "really long" in
that means at least 90% of the dimension of the srceen" ??? I'm not sure how
some of those toolbars interact in the corners, to know if 90% is right, or if
maybe one should find all the "topmost" windows that "abut an edge" and then
iterate several times looking for those that "cover 100% of the remaining space"
???
How do non-perl programs do it? How does "maximize" know how to leave the
toolbars visible? Is there a Windows call to figure that out?
"Piske, Harald" wrote:
> More general ... hm. What do you mean? All the topmost windows? I think the
> problem is too varied for a general solution. If you don't know the class
> names of the windows you want to find the coordinates of, how do you know
> which ones to choose? Well, you might go and take all the windows that are
> topmost, but that includes error messages and the task manager and who knows
> what else, so you might not find any space on the desktop for yourself.
>
> Maybe you want to have an ini-file stating the names of windows that may be
> present and if they are, consider their boundaries. See below for a small
> loop to display all the classnames.
>
> $_ = $Main->GetWindow (GW_HWNDLAST);
> do {
> print Win32::GUI::GetClassName ($_), "\n"
> if Win32::GUI::IsVisible ($_);
> } while $_ = Win32::GUI::GetWindow ($_, GW_HWNDPREV);
>
> I have a demo-script at www.fairymails.com/perl/, alone.pl, which uses a
> loop like this not to get the names of windows, but simply hide them -
> including the task bar - to claim 100% of the desktop.
>
> -Original Message-
> From: Glenn Linderman [mailto:[EMAIL PROTECTED]
> Sent: Samstag, 26. Mai 2001 13:54
> To: perl-win32-gui-users@lists.sourceforge.net
> Subject: Re: [perl-win32-gui-users] Taskbar & perl2exe -gui crash
>
> Indeed, this works. I've long wondered about a way to do it, and I've now
> incorporated this into my (only) Win32::GUI program. I am planning to write
> some more Win32::GUI programs soon. It seems, though, that this solution
> isn't
> completely general. While I don't personally use it anymore, I recall MS
> Office
> had an optional taskbar that could be docked similarly to the Windows
> taskbar.
> And some laptops have "power management toolbars". etc.
>
> Does anyone know of a more general technique for avoiding all the
> toolbars/taskbars that might nibble away at the edges of the desktop?
>
> ___
> Perl-Win32-GUI-Users mailing list
> Perl-Win32-GUI-Users@lists.sourceforge.net
> http://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
--
Glenn
=
Due to the current economic situation, the light at the
end of the tunnel will be turned off until further notice.
Re: [perl-win32-gui-users] Taskbar & perl2exe -gui crash
"Piske, Harald" wrote:
> I'm impressed - here's somebody who knows how to translate general ideas
> into formal terminology.
Thanks for the attaboy. It was just what I needed to inspire further
research...
> I don't have a solution at hand but with what you
> say, you should be able to figure it out. I'm not aware of any ready-made
> windoze function to give you the "effective desktop client area after
> accounting for taskbars", but that does not mean there is none. I'm not
> really at home in the win ref manuals.
I am. Now. Post research :) Research is below for the interested. Next
research project is to figure out how to use Win32::API well enough to benefit
from the research...
> Just one more note: my wife has a toolbar on her computer that is nothing
> but a small collection of buttons. Looks like it was invented before Win98
> came along with it's quick-launch thingy. That is only around 10% of the
> screen width and just one row of icons high.
I've seen some of those. Not too concerned about them, either.
Here's the relevant pieces of the results of the research through MSDN:
BOOL SystemParametersInfo(
UINT uiAction, // system parameter to query or set
UINT uiParam, // depends on action to be taken
PVOID pvParam, // depends on action to be taken
UINT fWinIni // user profile update flag
);
when uiAction == SPI_GETWORKAREA
Retrieves the size of the work area on the primary display monitor. The work
area is the portion of the screen not obscured by the system taskbar or by
application desktop toolbars. The pvParam parameter must point to a RECT
structure that receives the coordinates of the work area, expressed in virtual
screen coordinates.
To get the work area of a monitor other than the primary display monitor, call
the GetMonitorInfo function.
RECT
The RECT structure defines the coordinates of the upper-left and lower-right
corners of a rectangle.
typedef struct _RECT {
LONG left;
LONG top;
LONG right;
LONG bottom;
} RECT;
Members
left Specifies the x-coordinate of the upper-left corner of the rectangle.
topSpecifies the y-coordinate of the upper-left corner of the rectangle.
right Specifies the x-coordinate of the lower-right corner of the rectangle.
bottom Specifies the y-coordinate of the lower-right corner of the rectangle.
Remarks
When RECT is passed to the FillRect function, the rectangle is filled up to, but
not including, the right column and bottom row of pixels. This structure is
identical to the RECTL structure.
So it looks like the C/C++ code for this would go approximately like:
RECT workarea;
BOOL ret;
ret = SystemParametersInfo ( SPI_GETWORKAREA, 0, & workarea, 0 );
if ( ! ret )
{ ... GetLastError ...
}
// workarea can be determined from workarea.left, workarea.top, etc.
--
Glenn
=
Due to the current economic situation, the light at the
end of the tunnel will be turned off until further notice.
Re: [perl-win32-gui-users] Avoiding the Taskbars
OK, here's sample Perl/Win32::GUI/Win32::API code for positioning windows on the
desktop while avoiding any/all Windows "appbars" and the Windows "taskbar"
(which
was the first appbar, and still seems to be a bit special among appbars). If
you
don't like my "negative number means right or bottom" stuff, just take it out :)
Thanks to Harald for the kernel knowledge that got me started, and the attaboy
along
the way.
This code attempts to keep the full window visible, so if/when you want to allow
part of the windows to float off-screen, or under the taskbars, well, don't use
this
code, or modify it appropriately.
#
sub make_get_work_area
{ my $spi;
$spi = new Win32::API ( 'user32', 'SystemParametersInfo',
[ 'I', 'I', 'P', 'I' ], 'I' );
return $spi;
}
#
sub call_get_work_area
{ my ( $spi ) = @_;
my ( $rect ) = pack ( "", 0, 0, 0, 0 );
my ( $ret ) = $spi -> Call ( 48, 0, $rect, 0 );
unless ( $ret )
{
}
return unpack ( "", $rect );
}
#
{ my $spi;
sub working_area
{ my ( $winx, $winy, $winw, $winh ) = @_; # proposed position, actual size
# If no parameters are passed in, this function returns the working area
# of the desktop, ( left, top, right, bottom ). If parameters are passed
# in, it returns the "best" ( left, top, width, height ) position for the
# specified window, starting with the proposed position, adjusting it so
# that as much as possible of the window will be visible, and further
# adjusting it so that the top left corner of the window will be visible.
# Negative positions are interpreted as "bottom" or "right", as appropriate.
# first, obtain the non-toolbar area of the desktop.
$spi = & make_get_work_area () unless $spi;
print "$spi\n";
my ( @limits );
@limits = & call_get_work_area ( $spi );
print "limits: @limits\n";
# limits returned unless all parameters supplied
return @limits unless defined $winx && defined $winy
&& defined $winw && defined $winh;
print "before adjustments: x=$winx y=$winy w=$winw h=$winh\n";
$winy = $limits [ 3 ] - $winh
if $winy < 0 || $winy + $winh > $limits [ 3 ];
$winx = $limits [ 2 ] - $winw
if $winx < 0 || $winx + $winw > $limits [ 2 ];
$winy = $limits [ 1 ] if $winy < $limits [ 1 ];
$winx = $limits [ 0 ] if $winx < $limits [ 0 ];
print "x=$winx y=$winy w=$winw h=$winh\n";
return ( $winx, $winy, $winw, $winh );
}
}
#
Glenn Linderman wrote:
> "Piske, Harald" wrote:
>
> > I'm impressed - here's somebody who knows how to translate general ideas
> > into formal terminology.
>
> Thanks for the attaboy. It was just what I needed to inspire further
> research...
>
> > I don't have a solution at hand but with what you
> > say, you should be able to figure it out. I'm not aware of any ready-made
> > windoze function to give you the "effective desktop client area after
> > accounting for taskbars", but that does not mean there is none. I'm not
> > really at home in the win ref manuals.
>
> I am. Now. Post research :) Research is below for the interested. Next
> research project is to figure out how to use Win32::API well enough to benefit
> from the research...
>
> > Just one more note: my wife has a toolbar on her computer that is nothing
> > but a small collection of buttons. Looks like it was invented before Win98
> > came along with it's quick-launch thingy. That is only around 10% of the
> > screen width and just one row of icons high.
>
> I've seen some of those. Not too concerned about them, either.
>
> Here's the relevant pieces of the results of the research through MSDN:
>
> BOOL SystemParametersInfo(
> UINT uiAction, // system parameter to query or set
> UINT uiParam, // depends on action to be taken
> PVOID pvParam, // depends on action to be taken
> UINT fWinIni // user profile update flag
> );
>
> when uiAction == SPI_GETWORKAREA
>
> Retrieves the size of the work area on the primary display monitor. The work
> area is the portion of the screen not obscured by the system taskbar or by
> application desktop toolbars. The pvParam parameter must point to a RECT
> structure that receives the coordinates of the work area, expressed in virtual
> screen coordinates.
>
> To get the work area of a monitor other than the primary display monitor, call
> the Get
Re: [perl-win32-gui-users] Show In Taskbar
Johan Lindstrom wrote: > This was discussed some time ago on the list. What we figured out then was > that creating a window with a -parent => $winParent will make the new > window a child window. It will stay on top of the parent window and it will > not be displayed in the task bar. > > I'm not sure how to do it without having a window already, but maybe it's > possible to make it a child of e.g. the desktop hwind or something else. > Just a thought. Well, one can make a trash window and use it as a parent for what would otherwise be your first window. Then you can discard it, as it has served its purpose. Additional windows you create can use the first window as the parent. Perhaps the desktop could be used, if there was a way to get its handle into a Win32::GUI::Window object. -- Glenn = Due to the current economic situation, the light at the end of the tunnel will be turned off until further notice.
Re: [perl-win32-gui-users] Show In Taskbar
Yes, yes, that gets a windows handle, but not a Win32::GUI::Window object containing the handle, which seems to be the only thing -parent will accept. Attempting to pass $desktop (as defined below) to -parent results in a crash on my machine. Aldo Calpini wrote: > Glenn Linderman wrote: > > Perhaps the desktop could be used, if there was a way to get its handle > > into a Win32::GUI::Window object. > > my $desktop = Win32::GUI::GetDesktopWindow(); > > cheers, > Aldo > > __END__ > $_=q,just perl,,s, , another ,,s,$, hacker,,print; > > ___ > Perl-Win32-GUI-Users mailing list > Perl-Win32-GUI-Users@lists.sourceforge.net > http://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users -- Glenn = Due to the current economic situation, the light at the end of the tunnel will be turned off until further notice.
[perl-win32-gui-users] BringWindowToTop doesn't
Hi,
So I've got this code, and it doesn't bring the window to the top. I
can see that each time I click on the notify icon that the code gets
executed, both because the print statement fires, and the window
redraws. But the window stays behind other windows, in spite of the
BringWindowToTop call. It does that with or without the Hide/Show
sequence, and with or with a Disable/Enable sequence wrapped around the
BringWindowToTop. ActivePerl 5.6.1 build 626, Win32::GUI 0.0.558. What
trick am I missing?
I'm quite willing to throw all this away, and use whatever works... this
is just what sounded like should work from the documentation.
I should note that $mw is using the "parent window" trick to avoid being
on the task bar. I further note that sufficient Alt-Tab keystrokes do
eventually raise the window to the top.
sub notify_icon_Click
{ if ( $mw -> IsVisible ())
{ print "Bring Main to Top\n";
$mw -> Hide ();
$mw -> BringWindowToTop ();
$mw -> Show ();
}
}
--
Glenn
=
Due to the current economic situation, the light at the
end of the tunnel will be turned off until further notice.
Re: [perl-win32-gui-users] BringWindowToTop doesn't
Thanks, Harald. Once again, you've busted me out of the mental box I was in.
Your program so clearly works, one would wonder why mine doesn't. The
difference is in the fact that I'm calling BringWindowToTop from a Notify icon
click (which was clear from the sample code I provided), and you are not. Why
this should be different is apparently due to the choice of the Windows
designers in implementing the System Tray icon business.
Clicking on a window, or a sub-item in a window, as is done to reach the Belly
button in your code, "activates" your Main window, and gives it the keyboard
focus. Then, with the application already being activated, the
BringWindowToTop function is sufficient to raise the other window from whatever
depths it is in!
Clicking on a System Tray icon apparently doesn't activate the application
windows, just passes the click message in to the app. So then, if the result
of the click is that the application wants to come to the foreground, it has to
activate itself! Seems Win32::GUI doesn't provide that capability: it
documents GetFocus and GetActiveWindow, but doesn't document SetFocus or
SetActiveWindow!
Poking around in gui.xs reveals that it has a SetFocus, but not a
SetActiveWindow. So I made a SetActiveWindow out of Win32::API. However, it
still doesn't do the trick. Now, even though I SetFocus, SetActiveWindow,
BringWindowToTop, and Show the window, it still doesn't come to the front when
I click the Notify Icon.
This is on NT 4 sp 6, by the way.
"Piske, Harald" wrote:
> Works with me ... I have two windows, one button in the first window brings
> the other to top. Complete code snippet attached for you to check if it
> works with you and figure out the differences to yours. Oh, and I only
> checked on Win2k.
>
> Have fun,
> Harald
>
> > -Original Message-
> > From: Glenn Linderman [mailto:[EMAIL PROTECTED]
> > Sent: Mittwoch, 6. Juni 2001 18:25
> > To: Win32::GUI
> > Subject: [perl-win32-gui-users] BringWindowToTop doesn't
> >
> >
> > Hi,
> >
> > So I've got this code, and it doesn't bring the window to the top. I
> > can see that each time I click on the notify icon that the code gets
> > executed, both because the print statement fires, and the window
> > redraws. But the window stays behind other windows, in spite of the
> > BringWindowToTop call. It does that with or without the Hide/Show
> > sequence, and with or with a Disable/Enable sequence wrapped
> > around the
> > BringWindowToTop. ActivePerl 5.6.1 build 626, Win32::GUI
> > 0.0.558. What
> > trick am I missing?
> >
> > I'm quite willing to throw all this away, and use whatever
> > works... this
> > is just what sounded like should work from the documentation.
> >
> > I should note that $mw is using the "parent window" trick to
> > avoid being
> > on the task bar. I further note that sufficient Alt-Tab keystrokes do
> > eventually raise the window to the top.
> >
> > sub notify_icon_Click
> > { if ( $mw -> IsVisible ())
> > { print "Bring Main to Top\n";
> > $mw -> Hide ();
> > $mw -> BringWindowToTop ();
> > $mw -> Show ();
> > }
> > }
> >
> > --
> > Glenn
> > =
> > Due to the current economic situation, the light at the
> > end of the tunnel will be turned off until further notice.
> >
> >
> >
> > ___
> > Perl-Win32-GUI-Users mailing list
> > Perl-Win32-GUI-Users@lists.sourceforge.net
> > http://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
> >
>
>
>
>X.PLName: X.PL
>Type: Perl Program (application/x-perl)
--
Glenn
=
Due to the current economic situation, the light at the
end of the tunnel will be turned off until further notice.
Re: [perl-win32-gui-users] BringWindowToTop doesn't
Thanks so much. That does it for me too. SetForegroundWindow is the key
API for this functionality.
Side note TWIMC: the Windows API is clearly too big, with too many ways to
do the wrong thing, but that make it sound like it is the right thing.
Focused searching can easily lead down the wrong trail, and there is
insufficient cross-referencing among similar sounding topics. Not your
fault, but sure doesn't make it easy to learn the Windows API.
Peter Eisengrein wrote:
> I've used SetForegroundWindow() from a NotifyIcon and that works on NT4.
>
> sub ni_Click
> {
> if ($Window->IsVisible)
> {
> $Window->Hide();
> }
> else
> {
> $Window->Show();
> $Window->SetForegroundWindow();
> }
>
> return 0;
> }
>
> > -Original Message-
> > From: Piske, Harald [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, June 06, 2001 10:12 PM
> > To: 'perl-win32-gui-users@lists.sourceforge.net'
> > Subject: RE: [perl-win32-gui-users] BringWindowToTop doesn't
> >
> >
> > Works with me ... I have two windows, one button in the first
> > window brings
> > the other to top. Complete code snippet attached for you to
> > check if it
> > works with you and figure out the differences to yours. Oh, and I only
> > checked on Win2k.
> >
> > Have fun,
> > Harald
> >
> > > -Original Message-
> > > From: Glenn Linderman [mailto:[EMAIL PROTECTED]
> > > Sent: Mittwoch, 6. Juni 2001 18:25
> > > To: Win32::GUI
> > > Subject: [perl-win32-gui-users] BringWindowToTop doesn't
> > >
> > >
> > > Hi,
> > >
> > > So I've got this code, and it doesn't bring the window to
> > the top. I
> > > can see that each time I click on the notify icon that the code gets
> > > executed, both because the print statement fires, and the window
> > > redraws. But the window stays behind other windows, in spite of the
> > > BringWindowToTop call. It does that with or without the Hide/Show
> > > sequence, and with or with a Disable/Enable sequence wrapped
> > > around the
> > > BringWindowToTop. ActivePerl 5.6.1 build 626, Win32::GUI
> > > 0.0.558. What
> > > trick am I missing?
> > >
> > > I'm quite willing to throw all this away, and use whatever
> > > works... this
> > > is just what sounded like should work from the documentation.
> > >
> > > I should note that $mw is using the "parent window" trick to
> > > avoid being
> > > on the task bar. I further note that sufficient Alt-Tab
> > keystrokes do
> > > eventually raise the window to the top.
> > >
> > > sub notify_icon_Click
> > > { if ( $mw -> IsVisible ())
> > > { print "Bring Main to Top\n";
> > > $mw -> Hide ();
> > > $mw -> BringWindowToTop ();
> > > $mw -> Show ();
> > > }
> > > }
> > >
> > > --
> > > Glenn
> > > =
> > > Due to the current economic situation, the light at the
> > > end of the tunnel will be turned off until further notice.
> > >
> > >
> > >
> > > ___
> > > Perl-Win32-GUI-Users mailing list
> > > Perl-Win32-GUI-Users@lists.sourceforge.net
> > > http://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
> > >
> >
> >
>
> ___
> Perl-Win32-GUI-Users mailing list
> Perl-Win32-GUI-Users@lists.sourceforge.net
> http://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
--
Glenn
=
Due to the current economic situation, the light at the
end of the tunnel will be turned off until further notice.
Re: [perl-win32-gui-users] BringWindowToTop doesn't
"Piske, Harald" wrote: > I certainly agree, although complexity seems to be unavoidable with > flexibility. My approach is to really fight for the time to go over ALL the > functions once briefly, so that when I need a certain functionality, I have > a better chance to vaguely remember where there was something. Sure, if you can learn a little about everything, that's great. But a focused search leads to many dead ends. It would be extremely helpful, for example, if things like BringWindowToTop were documented to do only what they actually do, which appears to be to manipulate only windows within a particular application, rather than system wide. There is no cross-reference to the similar functions needed to do the equivalent system wide operation, and no clue that the operation only applies to a single application. Certainly flexibility results in complexity. But there could be one API for the functionality, with a flag to indicate if the operation pertains to the widgets in a window, the windows of an application, or the applications on the system. > MSDN itself > takes some getting used to and the first few days I was simply drowning in > information overload. But at the end of the day, all the information is in > there and if you just took a walk through all of the garden, you might > remember where you saw a particular flower before. It doesn't matter if all of the information is in there: if you can't find it using reasonable search methods, it isn't good enough. On the other hand, MSDN 6 is certainly a bit better than MSDN 5. I never could figure out enough from 5 to want to learn Windows, with 6, it started to seem possible, but there are still plenty of roadblocks. > On second thought, I'd like to speak of cacti rather than flowers ;-) Yes, stop and smell the cholla :) -- Glenn = Due to the current economic situation, the light at the end of the tunnel will be turned off until further notice.
Re: [perl-win32-gui-users] BringWindowToTop doesn't
Does anyone have sample code to create a pop-up menu for a Notify Icon's
right click? That seems to be the current rage for System Tray icons? I've
got a few other enhancements to make, and then I'll be looking that
direction.
I'm speculating that on click detection, you'd position and show a window
that contains nothing but a menu item... but there's a lot of details to
address to get that right, if it can even be done.
Peter Eisengrein wrote:
> I've used SetForegroundWindow() from a NotifyIcon and that works on NT4.
>
> sub ni_Click
> {
> if ($Window->IsVisible)
> {
> $Window->Hide();
> }
> else
> {
> $Window->Show();
> $Window->SetForegroundWindow();
> }
>
> return 0;
> }
>
> > -Original Message-
> > From: Piske, Harald [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, June 06, 2001 10:12 PM
> > To: 'perl-win32-gui-users@lists.sourceforge.net'
> > Subject: RE: [perl-win32-gui-users] BringWindowToTop doesn't
> >
> >
> > Works with me ... I have two windows, one button in the first
> > window brings
> > the other to top. Complete code snippet attached for you to
> > check if it
> > works with you and figure out the differences to yours. Oh, and I only
> > checked on Win2k.
> >
> > Have fun,
> > Harald
> >
> > > -Original Message-
> > > From: Glenn Linderman [mailto:[EMAIL PROTECTED]
> > > Sent: Mittwoch, 6. Juni 2001 18:25
> > > To: Win32::GUI
> > > Subject: [perl-win32-gui-users] BringWindowToTop doesn't
> > >
> > >
> > > Hi,
> > >
> > > So I've got this code, and it doesn't bring the window to
> > the top. I
> > > can see that each time I click on the notify icon that the code gets
> > > executed, both because the print statement fires, and the window
> > > redraws. But the window stays behind other windows, in spite of the
> > > BringWindowToTop call. It does that with or without the Hide/Show
> > > sequence, and with or with a Disable/Enable sequence wrapped
> > > around the
> > > BringWindowToTop. ActivePerl 5.6.1 build 626, Win32::GUI
> > > 0.0.558. What
> > > trick am I missing?
> > >
> > > I'm quite willing to throw all this away, and use whatever
> > > works... this
> > > is just what sounded like should work from the documentation.
> > >
> > > I should note that $mw is using the "parent window" trick to
> > > avoid being
> > > on the task bar. I further note that sufficient Alt-Tab
> > keystrokes do
> > > eventually raise the window to the top.
> > >
> > > sub notify_icon_Click
> > > { if ( $mw -> IsVisible ())
> > > { print "Bring Main to Top\n";
> > > $mw -> Hide ();
> > > $mw -> BringWindowToTop ();
> > > $mw -> Show ();
> > > }
> > > }
> > >
> > > --
> > > Glenn
> > > =
> > > Due to the current economic situation, the light at the
> > > end of the tunnel will be turned off until further notice.
> > >
> > >
> > >
> > > ___
> > > Perl-Win32-GUI-Users mailing list
> > > Perl-Win32-GUI-Users@lists.sourceforge.net
> > > http://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
> > >
> >
> >
>
> ___
> Perl-Win32-GUI-Users mailing list
> Perl-Win32-GUI-Users@lists.sourceforge.net
> http://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
--
Glenn
=
Due to the current economic situation, the light at the
end of the tunnel will be turned off until further notice.
Re: [perl-win32-gui-users] Popup window
My, oh my, now I've got menus in windows, and menus by popups! Amazing what an
example will do. Thanks. Now I have to populate their _Click routines!
"Piske, Harald" wrote:
> Note: I took the liberty of changing the subject, since this is not about
> BringWindowToTop anymore.
>
> About the popup menu, see trail "Re; Popup menu", posting by Jonathan
> Southwick on April 2nd, 2001. Apparently, Ludvig af Klinteberg subsequently
> managed to use the code for a tray icon.
> Quote:
>
> # define popup menu for listview
> my $PopupMenu = new Win32::GUI::Menu(
> "Item Properties" => "ItemProp",
> ">&Properties" => "ItemProperties",
> );
>
> # get right-click in listview
> sub DataView_RightClick {
>my($X, $Y) = Win32::GUI::GetCursorPos();
>
>$MainWindow->TrackPopupMenu($PopupMenu->{ItemProp},$X, $Y);
> }
>
> # clicked on particular menu item in popup menu
> sub ItemProperties_Click {
>## code you want to process;
> }
>
> Thanks, Jonathan
> Have fun
> Harald
>
> > -Original Message-
> > From: Glenn Linderman [mailto:[EMAIL PROTECTED]
> > Sent: Donnerstag, 7. Juni 2001 17:33
> > To: perl-win32-gui-users@lists.sourceforge.net
> > Subject: Re: [perl-win32-gui-users] BringWindowToTop doesn't
> >
> >
> > Does anyone have sample code to create a pop-up menu for a
> > Notify Icon's
> > right click? That seems to be the current rage for System
> > Tray icons? I've
> > got a few other enhancements to make, and then I'll be looking that
> > direction.
> >
> > I'm speculating that on click detection, you'd position and
> > show a window
> > that contains nothing but a menu item... but there's a lot of
> > details to
> > address to get that right, if it can even be done.
> >
> > Peter Eisengrein wrote:
> >
> > > I've used SetForegroundWindow() from a NotifyIcon and that
> > works on NT4.
> > >
> > > sub ni_Click
> > > {
> > > if ($Window->IsVisible)
> > > {
> > > $Window->Hide();
> > > }
> > > else
> > > {
> > > $Window->Show();
> > > $Window->SetForegroundWindow();
> > > }
> > >
> > > return 0;
> > > }
> > >
> > > > -Original Message-
> > > > From: Piske, Harald [mailto:[EMAIL PROTECTED]
> > > > Sent: Wednesday, June 06, 2001 10:12 PM
> > > > To: 'perl-win32-gui-users@lists.sourceforge.net'
> > > > Subject: RE: [perl-win32-gui-users] BringWindowToTop doesn't
> > > >
> > > >
> > > > Works with me ... I have two windows, one button in the first
> > > > window brings
> > > > the other to top. Complete code snippet attached for you to
> > > > check if it
> > > > works with you and figure out the differences to yours.
> > Oh, and I only
> > > > checked on Win2k.
> > > >
> > > > Have fun,
> > > > Harald
> > > >
> > > > > -Original Message-
> > > > > From: Glenn Linderman [mailto:[EMAIL PROTECTED]
> > > > > Sent: Mittwoch, 6. Juni 2001 18:25
> > > > > To: Win32::GUI
> > > > > Subject: [perl-win32-gui-users] BringWindowToTop doesn't
> > > > >
> > > > >
> > > > > Hi,
> > > > >
> > > > > So I've got this code, and it doesn't bring the window to
> > > > the top. I
> > > > > can see that each time I click on the notify icon that
> > the code gets
> > > > > executed, both because the print statement fires, and the window
> > > > > redraws. But the window stays behind other windows, in
> > spite of the
> > > > > BringWindowToTop call. It does that with or without
> > the Hide/Show
> > > > > sequence, and with or with a Disable/Enable sequence wrapped
> > > > > around the
> > > > > BringWindowToTop. ActivePerl 5.6.1 build 626, Win32::GUI
> > > > > 0.0.558. What
> > > > > trick am I missing?
> > > > >
> > > > > I'm quite willing to throw all this away, and use whatever
> > > > > works... this
> > > > > is just what sounded like should work from the docume
[perl-win32-gui-users] Menus
Hi, Is there a difference between Win 9x and NT for putting a menu on a window using Win32::GUI? I added a bunch of menus to my application, and they show up fine on NT, but they don't appear at all on Win 98. In fact, at first they caused perl to crash on Win 98... but upgrading to build 626 seems to have cured the bad memory reference, but the menus don't appear. Curiously, the floating menu that I added to my NotifyIcon does appear on Win98. Here's my menu definition, in case there is something obviously wrong with it my $mmenu = new Win32::GUI::Menu ( "&File" => "FileMenu", ">New &Location" => "NewLoc", ">New &ISP" => "NewISP", ">New &Phone Number" => "NewNum", ">-" => 0, ">E&xit" => "ExitNow", "&Edit" => "EditMenu", ">Edit Selected &Location" => "EditLoc", ">Edit Selected &ISP" => "EditISP", ">Edit Selected &Phone Number" => "EditNum", "&Options" => "OptMenu", "&Dialing" => "DialMenu", ">&Dial" => "DialNow", ">&Hangup" => "HangupNow", ">&Launch Email" => "LaunchNow", "&Help" => "HelpMenu", ">&Help Text" => "HelpNow", ">&About" => "AboutNow", ">-" => 0, ">Show &Debug Window" => "DebugNow", ); $smenu = new Win32::GUI::Menu ( "&Dialing" => "sDialMenu", ">&Dial" => "sDialNow", ">&Hangup" => "sHangupNow", ">&Launch Email" => "sLaunchNow", ">-" => 0, ">&Bring to Front" => "sForeground", ); -- Glenn = Due to the current economic situation, the light at the end of the tunnel will be turned off until further notice.
Re: [perl-win32-gui-users] Disable menu item?
$Window->Menu -> {'SortNot'} -> Enabled ( 0 );
Peter Eisengrein wrote:
> How can you disable (grey-out) an item in a menu? I don't see anything in
> the docs and it has ignored everything I have tried, including the obvious:
>
> $Window->Menu->{MenuItem}->Disable();
>
> ___
> Perl-Win32-GUI-Users mailing list
> Perl-Win32-GUI-Users@lists.sourceforge.net
> http://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
--
Glenn
=
Due to the current economic situation, the light at the
end of the tunnel will be turned off until further notice.
Re: [perl-win32-gui-users] Updating a window.
If, by "without human intervention" and "periodically", you mean that there is
no GUI event which triggers the need to update the status bar text, then the
answer to your question depends on what does trigger the need to update the
status bar text.
If "periodically" is truely the answer, that you want to wake up periodically,
and execute some code to determine what the status bar text should currently
be, then perhaps the Win32::GUI::Timer is what you are looking for.
Louis Bohm wrote:
> I am sure this is a really stupid question. But how do I update things in
> the window I create WITHOUT human intervention.
>
> Here is what I have for a script:
> use Win32::GUI;
> $main = Win32::GUI::Window->new(
>-name => 'Main',
>-width => 100,
>-height => 100,
>-text => 'Louis',
> );
> $main->AddLabel(
>-name => "Louis",
>-text => "Hello World 1"
> );
> $sb=$main->AddStatusBar(
>-name => "Status"
> );
> $sb->Text("Some data");
> $main->Show();
> Win32::GUI::Window();
>
> sub Main_Terminate {
> -1;
> }
>
> sub Main_Resize {
> $sb->Move(0, $main->ScaleHeight - $sb->Height);
> $sb->Resize($main->ScaleWidth, $sb->Height);
> }
>
> Now what I would like to do it periodically update the text in the status
> bar with out the user getting involved.
>
> Thanks,
> Louis
>
> --
> ¤¤º°`°º¤ø,¸¸,ø¤º°`°º¤øø¤º°`°º¤ø,¸¸,ø¤º°`°º¤øø¤º°`°º¤
> ¤°`°Lightbridge, Inc
> ¤°`°67 South Bedford St.
> ¤°`°Burlington MA 01832
> ¤°`°781.359.4795 mailto:[EMAIL PROTECTED]
> ¤°`°http://www.lightbridge.com
> ¤¤º°`°º¤ø,¸¸,ø¤º°`°º¤øø¤º°`°º¤ø,¸¸,ø¤º°`°º¤øø¤º°`°º¤
>
> ___
> Perl-Win32-GUI-Users mailing list
> Perl-Win32-GUI-Users@lists.sourceforge.net
> http://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
--
Glenn
=
Due to the current economic situation, the light at the
end of the tunnel will be turned off until further notice.
Re: [perl-win32-gui-users] DoEvents
Useful for the case when you want to do things that are not window
driven, and don't want to fork them into a separate process. Then the
GUI becomes less responsive (because you are doing something else
sometimes), but, as long as the chunks of something else are not too big,
it need not become too unresponsive. So then you can interrupt your
things that are not window driven to respond to the user's events.
$keep_running = 1;
while ($keep_running) {
Win32::GUI::DoEvents;
do something_else;
}
[EMAIL PROTECTED] wrote:
> IN the documentation, I find this about DoEvents:
>
> Just like Dialog(), but returns when there are no more events to
> process.
>
> So does that mean that if you leave your window alone, control will
> return to the script? So to keep your script from exiting as soon as
> you stop clicking buttons, etc. you'd have to do something like this:
>
> $keep_running = 1;
>
> Win32::GUI::DoEvents while ($keep_running);
>
> and then do something in one of your events that changes
> $keep_running. So wouldn't it be easier just to use Dialog and have
> that event return -1? I guess what I'm really asking here is, what
> are the pros and cons of DoEvents over Dialog? And if someone could
> provide an example of a script that uses DoEvents, that would be
> good.
>
> ___
> Perl-Win32-GUI-Users mailing list
> Perl-Win32-GUI-Users@lists.sourceforge.net
> http://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
--
Glenn
=
Due to the current economic situation, the light at the
end of the tunnel will be turned off until further notice.
Re: [perl-win32-gui-users] Menus
That was a good clue, Andrew, and I've done some more analysis. Indeed, if I throw in some $mw -> Show (), and some Win32::GUI::DoEvents () into my initialization routines, I get some extra interesting data. I'm not sure yet what all it means, or why it happens. Here's my added knowledge: Indeed, the menu shows up when initially created. Then I add a bunch of widgets, and it takes more space than my initial size. So I Resize and Move the window. This seems to work fine. Then I Hide and Disable the window, do lots of other setup (theoretically, none of it applies to the main window, but an alternate window gets fully initialized, displayed briefly, and then Hide and Disable. Then, eventually, back to the main window, and we Enable and Show it, and when we do, in the next of my debug Show calls, the menu doesn't get redrawn--the area where the menu should be is left with the desktop displayed there. That's kind of like a hole in the window. Then, because I'm afraid some user might have adjusted the toolbars to cover part of my window, I recheck that, to potentially change the postition. So I go through the motions of a Resize and Move again, and on the next Show after the Resize, the hole where the menu should have been gets filled in with the stuff that should be below the menu... i.e. that stuff gets "moved up", apparently because the menu is now gone. The real question is, Where, oh where did my menu go? Oh where, oh where can it be? I guess I'll be debugging by removing code until I can make the behavior disappear, if I can. Any clues would be appreciated. Andrew Kincaid wrote: > Using your exact code on a Windows 95B and a Windows 98SE machine running > Activestate Perl v.5.6.1.626 and Win32::GUI 0.0.558, I added the following > lines to the end of your code: > > $W = new Win32::GUI::Window( > -title=> "Title Here", > -left => 100, > -top => 100, > -width=> 400, > -height => 400, > -style=> WS_OVERLAPPEDWINDOW, > -menu => $mmenu, > -name => "Window", > ); > $W->Show(); > Win32::GUI::Dialog(); > > and it ran fine. I also used -menu => $smenu and it worked fine as well. > I'm not sure what to say unless you want to send more or all of your code. > > Andrew Kincaid > Lead PC Systems Specialist, IS&T > Georgia State University > [EMAIL PROTECTED] > > >>> [EMAIL PROTECTED] 06/19/01 09:07PM >>> > Hi, > > Is there a difference between Win 9x and NT for putting a menu on a > window using Win32::GUI? > > I added a bunch of menus to my application, and they show up fine on NT, > but they don't appear at all on Win 98. In fact, at first they caused > perl to crash on Win 98... but upgrading to build 626 seems to have > cured the bad memory reference, but the menus don't appear. > > Curiously, the floating menu that I added to my NotifyIcon does appear > on Win98. > > Here's my menu definition, in case there is something obviously wrong > with it > > my $mmenu = new Win32::GUI::Menu ( > "&File" => "FileMenu", > ">New &Location" => "NewLoc", > ">New &ISP" => "NewISP", > ">New &Phone Number" => "NewNum", > ">-" => 0, > ">E&xit" => "ExitNow", > "&Edit" => "EditMenu", > ">Edit Selected &Location" => "EditLoc", > ">Edit Selected &ISP" => "EditISP", > ">Edit Selected &Phone Number" => "EditNum", > "&Options" => "OptMenu", > "&Dialing" => "DialMenu", > ">&Dial" => "DialNow", > ">&Hangup" => "HangupNow", > ">&Launch Email" => "LaunchNow", > "&Help" => "HelpMenu", > ">&Help Text" => "HelpNow", > ">&About" => "AboutNow", > ">-" => 0, > ">Show &Debug Window" => "DebugNow", > ); > > $smenu = new Win32::GUI::Menu ( > "&Dialing" => "sDialMenu", > ">&Dial" => "sDialNow", > ">&Hangup" => "sHangupNow", > ">&Launch Email" => "sLaunchNow", > ">-" => 0, > ">&Bring to Front" => "sForeground", > ); > > -- > Glenn > = > Due to the current economic situation, the light at the > end of the tunnel will be turned off until further notice. > > ___ > Perl-Win32-GUI-Users mailing list > Perl-Win32-GUI-Users@lists.sourceforge.net > http://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users > > ___ > Perl-Win32-GUI-Users mailing list > Perl-Win32-GUI-Users@lists.sourceforge.net > http://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users -- Glenn = Due to the current economic situation, the light at the end of the tunnel will be turned off until further notice.
Re: [perl-win32-gui-users] Menus
Sorry to followup my own post, but here is a surprising symptom, and some thoughts on the matter. During the debugging session described below, I discovered some unexpected behavior that meant that each time I Resized my windows, I wound up with the size of the window from the previous attempt to resize. So I was delayed by one Resize. By the nature of the application, this wasn't a problem, as I don't actually Resize often, and usually the actual size stays the same. But I fixed it anyway, and then got a modified behavior from my windows. With the debugging code disabled, and a lot of stuff done while the window is not visible before calling Win32::GUI::Dialog, when my main window now "appears" for the first time, it is missing its menu. In its place is the leftovers from whatever is behind the menu; the menu doesn't get drawn, and the area where the menu should be doesn't get drawn! The really bizarre effect came into play when I attempted (on Win9x, this all works fine on NT, remember) to use the application. I clicked a button in my script that launched a program, and a menu got drawn on my window But the really, really strange part was that it was the menu from the program I launched (not written using perl or Win32::GUI), not the menu that should belong to the window. This makes me speculate that perhaps menus are handled in some bizarre global manner on Win9x, and that the sequence of things is very important, and that Win32::GUI gets it slightly wrong??? I have two windows in my application, and when I started playing with menus, I only added menus to the main window (so far), and not to the other window. But the sequence of events in my program is to initialize a junk window (which goes away, to avoid my main window being in the task bar), then to initialize the main window (with the junk window as a parent), then to discard the junk window, then to add all the widgets to the main window, then to resize and move it to where it belongs, to display it briefly, and then to hide and disable it while I initialize a dialog window, add lots of widgets to it, resize and move it, display it briefly, and then hide it. Then I enable the main window, show it, and call Win32::GUI::Dialog. However, in debugging, I was able to produce the same effect without even creating the dialog window, but otherwise following the same sequence. While I'm not ready to share this code with the world, if any one would like to look at it that has more Windows knowledge than I, I could share it with a few. The next time the window is moved or resized by the user to a different location or size, the window will redraw, repositioning everything as if the window never had a menu, which was the state I used to initially see due to the above mentioned unexpected resize behavior... thus making me think the menu had never shown up, when it fact it had, and then had been deleted (behind my back as far as I can tell), and everything moved up a few pixels (yes, it was blank at the bottom). So why is my menu disappearing? I suppose I could try putting it back, with AddMenu? I haven't found an example of that, does it work? But while that might work around the problem, I must still wonder what memory gets corrupted when the menu disappears, and what negative effects that might have on the stability of Win9x (since that isn't very stable in the first place, I don't want to make it worse with my program). === Original message === That was a good clue, Andrew, and I've done some more analysis. Indeed, if I throw in some $mw -> Show (), and some Win32::GUI::DoEvents () into my initialization routines, I get some extra interesting data. I'm not sure yet what all it means, or why it happens. Here's my added knowledge: Indeed, the menu shows up when initially created. Then I add a bunch of widgets, and it takes more space than my initial size. So I Resize and Move the window. This seems to work fine. Then I Hide and Disable the window, do lots of other setup (theoretically, none of it applies to the main window, but an alternate window gets fully initialized, displayed briefly, and then Hide and Disable. Then, eventually, back to the main window, and we Enable and Show it, and when we do, in the next of my debug Show calls, the menu doesn't get redrawn--the area where the menu should be is left with the desktop displayed there. That's kind of like a hole in the window. Then, because I'm afraid some user might have adjusted the toolbars to cover part of my window, I recheck that, to potentially change the postition. So I go through the motions of a Resize and Move again, and on the next Show after the Resize, the hole where the menu should have been gets filled in with the stuff that should be below the menu... i.e. that stuff gets "moved up", apparently because the menu is now gone. The real question is, Where, oh where did my menu go? Oh where, oh where can it be? I guess I'll be debugging by removing co
Re: [perl-win32-gui-users] Help - Placing an ICON on the top leftof the window
Why would you ask how NOT TO USE Win32::GUI on a Win32::GUI list?
The purpose of the list, and the knowledge base of the participants is how TO
USE Win32::GUI.
Anything you can do using Win32::GUI can be done without using Win32::GUI. Just
create your own equivalent to the functionality, using Win32::API, or your own C
language DLL.
Perhaps you are under the impression that this list was for users of ANY perl on
Windows GUI facility? Really, it is specific to Win32::GUI. If you are a TK
user, you might get better help from a TK specific group, or a TK on Windows
specific group (if there is one).
Amin Aleali wrote:
> Thank you for that. But is there a way not to use Win32::GUI
>
> I looked around and found the following from
> http://www.cpan.org/authors/id/C/CL/CLAIRD/ptkFAQ.html#A10.20
>
> 10.20. How do I replace the default window icon?
>
> The following works with .BMP and .GIF files. The author would
> welcome an explanation of how to use Windows .ICO files.
>
> use Tk;
> my $mw = tkinit();
> $mw->idletasks;
> my $icon = $mw->Photo(-file => 'myicon.gif');
> $mw->iconimage($icon);
> MainLoop;
>
> I modified my code as the following be to up with the new style
>
> use Tk;
> $main = new MainWindow (-title => 'Control Center' );
> $icon = $main->Photo(-file => 'myicon.gif');
> $main->iconimage($icon);
>
> yet I still see the "tk" icon the top left hand corner. Anyone has any idea
> what is missing?
>
> Thank you in advance
>
> 've used Michaelangelo to create icons. To add the icon:
>
> # create the icon handler.
> $icon = new Win32::GUI::Icon($SETTINGS->{files}->{gui_win_icon});
>
> # create a window class for our window.
> $hwnd_class = new Win32::GUI::Class( -name => "SomeNameOf Class",
> -icon => $icon
>);
>
> --
> Morbus Iff ( softcore vulcan porn rulez )
> http://www.disobey.com/ && http://www.gamegrene.com/
> please me: http://www.amazon.com/exec/obidos/wishlist/25USVJDH68554
> icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
>
> -Original Message-
> From: Amin Aleali
> Sent: Tuesday, October 30, 2001 1:08 PM
> To: 'perl-win32-gui-users@lists.sourceforge.net'
> Subject: [perl-win32-gui-users] Help - Placing an ICON on the top left
> of the window
>
> I am sure that this question has been asked before but sadly I cannot find
> it in the archives.
>
> I need to replace the "TK" icon on the top left corner with one of my own.
> If anyone has any suggestions or code clip to point me to the right
> direction I would utterly appreciated.
>
> -A
>
> ___
> 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 mailing list
> Perl-Win32-GUI-Users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
--
Glenn
=
Due to the current economic situation, the light at the
end of the tunnel will be turned off until further notice.
Re: [perl-win32-gui-users] Capture shutdown
I'd sure like to see this capability (even if not this exact code) in a future
release...
Win32 GUI seems to deal better with shutdown on WinNT/2K than 9x.
Sean Healy wrote:
> I have not been successful. PeekMessage doesn't seem to work at all, and
> all I could get GetMessage to catch were menu clicks (my application has a
> NotifyIcon, but I never call Show on the main window). To solve my original
> problem, I simply have my application write to file each time a setting
> changes. An inelegant and inefficient solution, but it works.
>
> I think if something like the following were to be added to the main message
> loop in GUI.xs (perhaps between case WM_SYSCOMMAND and case WM_SIZE), it
> would work.
>
> case WM_QUERYENDSESSION:
> if(GetObjectName(NOTXSCALL hwnd, Name)) {
> /*
> * (@)EVENT:Shutdown()
> * Sent when Windows is about to shut down.
> * (@)APPLIES_TO:Window, DialogBox
> */
> strcat(Name, "_Shutdown");
> PerlResult = DoEvent_Generic(NOTXSCALL Name);
> }
> break;
>
> Then {WindowName}_Shutdown would be called whenever Windows is about to shut
> down. According to what I was able to discover, if an application returns
> false, Windows stops the shutdown process. So returning 1 or 0 should work
> as expected; I believe returning -1 from your sub would end the Dialog
> phase, but that Win32::GUI would then return a 1, so Windows would shut
> down.
>
> If anyone wants to test this out (I do not have a compiler), that would be
> nice. Perhaps it could be included in the next release if it works. Then,
> again, it's only really useful for something that runs during the entire
> Windows session, like my application or a daemon, so perhaps it's not really
> necessary.
>
> _
> Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
>
> ___
> Perl-Win32-GUI-Users mailing list
> Perl-Win32-GUI-Users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
--
Glenn
=
Due to the current economic situation, the light at the
end of the tunnel will be turned off until further notice.
[perl-win32-gui-users] display images--sample code?
Hi, ImageMagick for Windows seems to be missing display routines, as the supplied display utility is X based... or did I miss a key point of their documentation? Win32::GUI seems to be able to do something with Bitmaps, but it is not particularly clear just what, or how. ImageMagick can do lots of nice conversions of whatever graphic format to BMP format, if that is what Win32::GUI::Bitmap needs. I'd like to conquer the functionality of loading a file with ImageMagick, and then using Win32::GUI to display it. Loading the file seems to be straightforward: use Image::Magick; $image = Image::Magick -> new; $errstr = $image -> Read ( $filename ); How can I get from there, to a window that displays the data? Do I have to $errstr = $image -> Write ( 'xxx.bmp' ); as it appears that the Win32::GUI::Bitmap call requires a filename? use Win32::GUI; $bitmap = new Win32::GUI::Bitmap ( 'xxx.bmp' ); or is there a way to avoid the intermediate file? Using the TBD Create method? Or maybe Win32::GUI::BitmapInline? Although this seems to create its own intermediate file. And then, having somehow or another a $bitmap reference, how do I display it in a window? I see one possibility of $main_window -> AddLabel ( -name => bitmap, -bitmap => $bitmap ); Are there any pros or cons of using Labels vs Buttons vs ??? And do you need to specify the exact size of the bitmap as the size of the label? Or do you need to leave room for borders, and other stuff? Some of this will probably become clear as I start to experiment. If there are any scaling capabilities, it'd be nice to know about them, I didn't find any the first pass through. On the other hand, I fear that none of that will allow me to add scroll bars to the bitmap, so that I can display a portion of a bigger than screen image. I fear I'll have to dive into Win32::GUI::DC to do some of this... I've been avoiding that so far... but this seems oriented to line art, rather than bitmap art... Any advice, guidance, or sample code that I could look at for this, before I bang a hole in a wall with my head, and then find out it was the wrong wall!!! would be welcomed. Mostly I'm dealing with monochrome bitmaps, if that simplifies things, but they can get quite large, and scaling and scrolling are requirements to get the job done. -- Glenn = Due to the current economic situation, the light at the end of the tunnel will be turned off until further notice.
Re: SOLVED!! Re: [perl-win32-gui-users] This code runs onW2000, but not W98...???
And here's another fellow that is extremely happy that Mark had this problem, and that someone knew the answer. So while I was gone for a few weeks around Christmas, this is the best present I've gotten from the list upon my return! The only response I got when I described the same problem some months back (maybe a whole year by now) was that Aldo doesn't use W98. Clearly our collective knowledge has been increased since then! And discussions like this do help understanding, in my opinion, even if we aren't expecting fixes. I look forward to fixing my application soon, to keep its menus working on W98 now. I'm hoping that someday we might here a bit about the new, revamped Win32::GUI, also. Mark Wilkinson wrote: > "Piske, Harald" wrote: > > > Guys ... it's Christmas :-) This group has always been a tremendous source > > for solutions. > > indeed it has! > > > I understand there is a solution to the problem that was > > posted. I fail to see the point in going back and forth about what might > > have been a better idea some time ago. > > The intent was to explore this quirky behavior in its entirety and determine > exactly *why* it behaves the way it does, so that others who look through > archives of this group will be able to identify the solution if they have > similar but non-identical problems to the one I reported. The > solution/workaround *is* straightforward, but only if you know the problem > exists, and why it works the way it does. I spent three days trying to work > out > why my code didn't function, and I want to both warn others about this > potential > pitfall, as well as understand *why* the behavior exists so that I can avoid > meeting it again in the future. As you will notice, I received a response > indicating a similar behavior with Bitmap objects in Label controls... a > non-identical situation that I can now avoid because I (and others) have been > warned... so these conversations are a good thing! > > Certainly, as an open-source developer myself, have several active mailing > lists and bug lists for my larger projects. I find these kinds of > conversations > *very* helpful as I go about improving my own products, so I am not ashamed to > hash-out problems I find with other modules.. not to be cruel, but to be > constructive and helpful to the author! I know that I put a hell of a lot of > work into my own code, and I want people to find it straightfoward and > clear... > I think all OS authors want that... > > > Happy holidays everyone > > Hope you had a nice evening in Europe, mine's yet to come > > Merry Christmas to you all! > > Mark > > ___ > Perl-Win32-GUI-Users mailing list > Perl-Win32-GUI-Users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users -- Glenn = Due to the current economic situation, the light at the end of the tunnel will be turned off until further notice.
[perl-win32-gui-users] Bitmaps in Win32::GUI [perl-win32-gui-users]
Hi, Attached is a test program, to help figure out some of the capabilities of Win32::GUI with regard to bitmapped graphics. I've had some basic success, but a failure I can't live with has cropped up: Success-- either a Label or a Button allows a BMP file to be loaded into it, via Win32::GUI::Bitmap. The attached code does this (you'll need a bitmap file; mine is monochrome, B&W, 1 bpp, stored in .tif format) Failure-- Seems like ImageMagick "accidentally" inverts the color when converting from .tif to .bmp ... and that ImageMagick's Negate operation doesn't have any effect on .bmp files !!! Failure-- there seems to be no way to control the colors: white turns out grey. Lots of -foreground and -background options don't seem to help. Advice welcome. -- Glenn = Due to the current economic situation, the light at the end of the tunnel will be turned off until further notice. temp.pl Description: Perl program
[perl-win32-gui-users] use Win32; use Win32::GUI;
Maybe everyone else already knew this, but I didn't: The sequence use Win32; use Win32::GUI; produces lots of redefinition warnings from the exporter, it appears, but the sequence use Win32::GUI; use Win32; does not. Clearly the workaround is simple. But I'm curious how Win32 is smarter than Win32::GUI in the way exporter is used or invoked. I'd rather not figure that out myself, as it isn't really important to me, if someone already has figured it out and can explain it in simple terms. -- Glenn = Due to the current economic situation, the light at the end of the tunnel will be turned off until further notice.
[perl-win32-gui-users] Re: Sending text to other windows with Win32::GUI
Careful... you get more than one process doing the append thing, and you'll lose some of the appends, if they happen concurrently. Unless you have a separate control for each process to use. Scott Campbell wrote: > > It would appear that the Perl gods have found favor with you. > This works like a charm. Very impressive. > > Thank you so much for the help. > Scott > > Scott Campbell > Senior Software Developer > Somix Technologies > (207) 324-8805 > http://www.somix.com > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Johan Lindstrom > Sent: Thursday, January 24, 2002 10:29 AM > To: [EMAIL PROTECTED]; > perl-win32-gui-users@lists.sourceforge.net > Subject: RE: Sending text to other windows with Win32::GUI > > At 09:25 2002-01-24 -0500, Scott Campbell wrote: > >Yes, this is very simple and works! Thank you. > >My one wish is that whenever text is sent to the main gui window, it > >would append it on, and not overwrite the current text already in the > >window. But I don't see a simple way to do this. > > Try this (untested): > Win32::GUI::Text( $hwind, Win32::GUI::Text($hwind) . $text ); > > Why does that work? (if it works :) > $win->Text() returns the text. > > /J > > -- --- -- -- -- -- - - - > Johan LindströmSourcerer @ Boss Casinos [EMAIL PROTECTED] > > Latest bookmark: "Managing IMAP Chapter 9 Cyrus System Adminis..." > http://www.oreilly.com/catalog/mimap/chapter/ch09.html > > ___ > Perl-Win32-Users mailing list > [EMAIL PROTECTED] > http://listserv.ActiveState.com/mailman/listinfo/perl-win32-users > > ___ > Perl-Win32-Users mailing list > [EMAIL PROTECTED] > http://listserv.ActiveState.com/mailman/listinfo/perl-win32-users -- Glenn = Due to the current economic situation, the light at the end of the tunnel will be turned off until further notice.
Re: [perl-win32-gui-users] Re: Tooltip Feature and Win32::GUI thoughts
Eric, Perhaps you could share those direct communications from Aldo with people that maintain Win32::GUI FAQ lists these days? Or the list at large? Perhaps some of it could get incorporated into the FAQ or into some other documentation? Like others, I'm starting to wonder if there is any active development of Win32::GUI happening. As I'm considering doing a fairly major Win32::GUI application soon, I'm a bit nervous about the level of support that might be available, should I run into a serious limitation. Eric Hansen wrote: > > Peter, > > what type of problems are you having exactly? I developed a fully > functional, complete application system of programs and menus at work with > Win32::GUI (including Win32::ODBC) using advanced features of ListViews, > ListBoxes, TextBoxes, Windows, DialogBoxes, etc. back in 1999. There may > be some undocumented features I can help you with that I received from Aldo > thru direct communication with him back then. I'll try to help anyway. > > Eric > Dallas, Texas USA > > >>> "Peter Köller" <[EMAIL PROTECTED]> 02/19/02 12:57AM >>> > Hello all Win32::GUI Users! > > Yes, I would like the Tooltip Feature, too. > > But, I think bug fixes are more interesting. I am working on a big > Win32::GUI app and stepped into some serious bugs. I spend more time looking > for Win32::GUI workarounds than for the app development. This isn't > productive any more. > > Peter > > > -Ursprüngliche Nachricht- > > Von: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] Auftrag von > > Eric Hansen > > Gesendet am: Montag, 18. Februar 2002 16:17 > > An: perl-win32-gui-users@lists.sourceforge.net > > Betreff: [perl-win32-gui-users] Re: Perl-Win32-GUI-Users digest, Vol 1 > > #328 - 2 msgs > > > > We should all really push for this feature to be fully > > implemented. I have often wanted it myself to put context > > sensitive help in my applications. > > > > Eric > > Dallas, Texas USA > > > > >>> [EMAIL PROTECTED] 02/17/02 > > 02:14PM >>> > > Send Perl-Win32-GUI-Users mailing list submissions to > > perl-win32-gui-users@lists.sourceforge.net > > > > To subscribe or unsubscribe via the World Wide Web, visit > > https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users > > or, via email, send a message with subject or body 'help' to > > [EMAIL PROTECTED] > > > > You can reach the person managing the list at > > [EMAIL PROTECTED] > > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of Perl-Win32-GUI-Users digest..." > > > > > > Today's Topics: > > > >1. Tool Tips (Chris Wearn) > >2. Re: Tool Tips (Marcus) > > > > --__--__-- > > > > Message: 1 > > From: "Chris Wearn" <[EMAIL PROTECTED]> > > To: > > Date: Sun, 17 Feb 2002 13:23:16 +0800 > > Subject: [perl-win32-gui-users] Tool Tips > > > > Hello All, > > > > I have now exhausted most combinations of things that seem > > logical, however > > I still can't get the tool tips to work. > > > > What Objects can I place it on. I'm trying to get a tip to appear on > > buttons. > > > > # Create Button object - SetCWD > > $btnSetCWD = $MainWin->AddButton( > >-name=> "btnSetCWD", > >-text=> "Set", > >-width => 80, > >-height => 23, > >-left=> 516, > >-top => 260, > >-tabstop => 1, > >-font=> $Font, > >-tooltips=> 1, > > ); > > > > # Create Tooltip object > > $ttipSetCWD = new Win32::GUI::Tooltip( > > -parent => $btnSetCWD, > > -name => "ttipSetCWD", > > -text => "Text to display as tooltip", > > ); > > > > I have scoured the net for any examples but have not found a > > worked example > > and the Win32::GUI docs are not expansive enough for me to figure it out > > (read dumb!). > > > > Has anyone else managed to get this to work? > > > > Chris > > > > > > > > --__--__-- > > > > Message: 2 > > Date: Sun, 17 Feb 2002 18:29:04 +0100 > > From: "Marcus" <[EMAIL PROTECTED]> > > To: perl-win32-gui-users@lists.sourceforge.net > > Subject: Re: [perl-win32-gui-users] Tool Tips > > > > On 17.02.02 at 13:23 Chris Wearn wrote: > > >I have now exhausted most combinations of things that seem logical, > > however > > >I still can't get the tool tips to work. > > > > afaik, tool tips are not yet implemented. I also spent a lot of time on > > them because the manual gives the impression of tool tips being > > available. The only implemented tool tip is the one that comes with the > > system tray icon. > > > > I'd be glad to learn otherwise though. > > > > Marcus > > > > > > > > > > > > --__--__-- > > > > ___ > > Perl-Win32-GUI-Users mailing list > > Perl-Win32-GUI-Users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users > > > > > > End of Perl-Win32-GUI-Users Digest > > > > > > ___ > > Perl-Win32-GUI
[perl-win32-gui-users] multiline menu items
Hi, I have an application where I'd like to have a multi-line menu item. I've seen that in programs, where the first line of the menu item has text in the normal position, and the subsequent line(s) are further indented, and when your mouse approaches/leaves the first or last line, all of them change background color at once to show that the whole multi-line item is selected/deselected. Is this possible with Win32::GUI::Menu and/or Win23::GUI::MenuItem ??? -- Glenn = Remember, 84.3% of all statistics are made up on the spot.
Re: [perl-win32-gui-users] Win32::GUI Release 0.0.665
Now I've downloaded and compiled the new version. Boy was I surprised! I ran an existing application, and it looked quite different in layout, but upon careful inspection, and knowing how the code was written, it appears that everything that is different is a result of exactly one thing: $font = Win32::GUI::Font->new ( -name => "Times New Roman", -size => 18, ); The above line was fiddled with by trial and error using version 558, to get the size font that I wanted. I was rather surprised at the time that the size, if expressed in points, turned out to be so small on my screen. But I was so busy learning other stuff, that I just ignored that issue but now it has come back to haunt me! Using version 665, the font used probably _is_ 18 points... at least it looks the same as what Word Perfect calls 18 points for that same font! So I guess this is an improvement, except that it would be nice to know if there is a scale factor that can be applied, so that an application could choose the same size font in either version of Win32::GUI. Other than the font size issue, and the resulting effects on widget layout, my forking Win32::GUI application seems to still be functional. -- Glenn = Remember, 84.3% of all statistics are made up on the spot.
Re: [perl-win32-gui-users] Win32::GUI Release 0.0.665
> At Thursday, 28 February 2002, Glenn wrote: > > >Now I've downloaded and compiled the new version. Boy was I surprised! jean bosco muzatsinda wrote: > > Hi, > How did you proceed to download and compile? > I'm knew to this matter of things ( win32::GUI)and I'm experiencing > some problems. > Thanks, > > Jean Although this was a private message (inappropriate) I'm replying back to the list, because there may be a number of others that have never compiled Win32::GUI, that now suddenly have the desire to. It was my first time to ever compile a perl module, but really, it isn't too hard when things are set up right, I guess, and it seems that Aldo has things set up right. The following is what I did to download and compile: Download: used web browser, went to http://data.perl.it/, found the link for the source ( http://dada.perl.it/Win32-GUI-0.0.665.tar.gz ), and fetched it to my local hard drive, I used d:\. Using cmd.exe, I Then "gunzip Win32-GUI-0.0.665.tar.gz" Then "tar xvf Win32-GUI-0.0.665.tar" Then "cd d:\Win32-GUI-0.0.665" I used my favorite text editor, emacs, to look around. It appears that although the code has been enhanced and restructured into multiple source files, that the documentation has not yet been enhanced in any way, and also not the sample code. Then I had to experiment to see how to compile. Since I'm using ActiveState's perl, which is reportedly compiled using MS VC, I figured I'd need to get that on my path. And I remembered that when I had installed MS VC, it had told me about a batch file that can put it on the path (doesn't need to be on the path when you use the MS IDE). And I remembered seeing, over and over again on various perl lists, the comment that when using MS VC, you have to use "nmake" instead of "make". And the theoretical process for installing modules is documented as the sequence of commands: perl makefile.pl make make install So I wrote the following batch file: call "c:\program files\microsoft visual studio\vc98\bin\vcvars32.bat" perl makefile.pl nmake nmake install Upon executing it from the command line prompt, where my current directory was d:\Win32-GUI-0.0.665, it seemed to do the trick. I then attempted to run a couple scripts for which I had already set up shortcuts, and lo and behold! they used the new version of Win32::GUI ! With the surprise reported earlier. -- Glenn = Remember, 84.3% of all statistics are made up on the spot.
Re: [perl-win32-gui-users] Win32::GUI Release 0.0.665
Glenn Linderman wrote: > > Now I've downloaded and compiled the new version. Boy was I surprised! Here's another surprise: When moving the cursor to the edges and corners for resizing things, the cursor doesn't change to the "usual" double-headed arrows which provide feedback to the user that they are in the right position for resizing. Resizing still works, but it is awkward because of the expectation from other programs and earlier versions of Win32::GUI that the cursor should change shape for that event. -- Glenn = Remember, 84.3% of all statistics are made up on the spot.
Re: [perl-win32-gui-users] Win32::GUI Release 0.0.665
Aldo Calpini wrote: > > Frazier, Joe Jr wrote: > > > but I still don't know what to do when you just say use Win32::GUI ;-) > > > > Use old style by default. This avoids users > > having to change thier code until they are ready to totally update thier > > code. > > yes, this is sure. by default the old style is used, the problem is when you > don't use it and put an -events option on something. maybe I should > process -events options *only* if you said: > > use Win32::GUI Event_Model => 'byref'; Seems like it would be possible to "merge" the old and new styles, if, when a new window or control is defined, a search of the compiled namespace would be done, and all functions defined at that time that match the "window or control name followed by underscore followed by event name" naming convention could be implicitly included into the -event list (unless they were already defined explicitly with a -event or -onEvent parameter). This would allow a gradual migration path from old to new model, for most typical Win32::GUI programs. Programs that use eval to define new methods to handle new events for new windows or controls wouldn't benefit as greatly, but the (few) places where those evals are done could be converted into Change ( -event ) calls. -- Glenn = Remember, 84.3% of all statistics are made up on the spot.
Re: [perl-win32-gui-users] Win32::GUI Release 0.0.665
Aldo Calpini wrote:
>
> arguments to -events can be:
> - a subroutine name (string)
> - a reference (eg. \&)
> - an anonymous sub (eg. sub { .. })
Both of the following items prevent me from porting certain Win32::GUI
applications to the New Event Model.
There doesn't seem to be a way to...
1) discover the code ref for an event handler, in case you want to wrap
it in a more powerful handler, or chain the handlers, when using layered
or modular software techniques. Something like the following could be a
possible interface:
$coderef = $mw->GetEventHandler ( "Terminate" );
2) execute an event handler. Something like the following could be the
interface:
$mw->CallEventHandler ( "Terminate", @pass_through_parameters );
The handler itself would then be called with the window/control name as
its first parameter, followed with the @pass_through_parameters. The
handler's return value would be returned from CallEventHandler, but it
would generally be discarded in cases like this I suspect.
Clearly (1) is more powerful than (2), since if you can discover the
code ref, then you could clearly execute it... but (2) could be
convenient syntactic sugar for recoding cases like (old style event
model) shutting down all windows when the main window is closed:
sub Main_Terminate
{ # print "Main_Terminate\n";
& LB_Terminate ();
& PR_Terminate ();
& ED_Terminate ();
return -1;
}
--
Glenn
=
Remember, 84.3% of all statistics are made up on the spot.
Re: [perl-win32-gui-users] Centering a window
Jeremy Blonde wrote:
>
> Here's how I'm doing it. The code is borrowed from someone else, perhaps
> Aldo's examples.
>
> $SCR_WIDTH = Win32::GUI::GetSystemMetrics(0);
> $SCR_HEIGHT = Win32::GUI::GetSystemMetrics(1);
>
> $WIDTH = 350;# Window Width
> $HEIGHT = 250;# Window Height
>
> $LEFT = ($SCR_WIDTH/2) - ($WIDTH}/2);
> $TOP = ($SCR_HEIGHT/2) - ($HEIGHT}/2);
>
> jb
Here's another way to do it. The above code centers on the physical
window; the following code on the "logical" window after subtracting the
taskbar, application toolbars, etc. Neither the above nor the below
code is adequate for multiple monitor support, as both assume the
primary display monitor.
#
sub get_work_area; # version 2002/03/22
{ my ( $gSystemParametersInfo );
sub get_work_area
{ unless ( defined $gSystemParametersInfo )
{ $gSystemParametersInfo = new Win32::API ( 'user32',
'SystemParametersInfo',
[ 'I', 'I', 'P', 'I' ], 'I' );
}
my ( $rect ) = pack ( "", 0, 0, 0, 0 );
$gSystemParametersInfo->Call ( 48, 0, $rect, 0 );
return unpack ( "", $rect );
}
}
#
( $left, $top, $right, $bottom ) = & call_get_work_area ();
$winwid = 600;
$winheight = 400;
$mw = Win32::GUI::Window->new ( -name => 'mw', -text => 'application',
-width => $winwid, -height => winheight,
-left => $left + ( $right - $left - $winwid ) / 2,
-top => $top + ( $bottom - $top - $winheight ) / 2 );
--
Glenn
=
Remember, 84.3% of all statistics are made up on the spot.
Re: [perl-win32-gui-users] system tray, notifyicon and stuff
When you hide the window, also disable it. When you want to make the window usable again, enable it and show it. This will make the whatever-it-is-you-call-it disappear from the task bar while it is minimized, but appear when the window is visible. If you never want it to appear, make a parent window for your current main window, and then eliminate the parent window. Then you never get a whatever-it-is-you-call-it in the task bar whether the window is minimized or not. [EMAIL PROTECTED] wrote: > > hi. i've added a notify icon to sit in the system tray when a window is > minimised. what i'd like to try and do is make the > whatever-it-is-you-call-it disappear from the task bar. i figured it would > probably have something to do with window styles, if anything, but i can't > find anything about it in msdn. any ideas? > > thanx in advance > > ___ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > > ___ > Perl-Win32-GUI-Users mailing list > Perl-Win32-GUI-Users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users -- Glenn = Remember, 84.3% of all statistics are made up on the spot.
[perl-win32-gui-users] Win32::GUI and Perl 5.8
Hi, I'm trying to build Win32-GUI-0.0.665 for Perl 5.8 (ActiveState build 804), and I get a bunch of unresolved external symbols, mostly to do with ImageList stuff (actual messages below). Anyone know what I'm doing wrong, here in the middle of the night? Using MSVC++ 6.0, is that still OK? I've accidentally been off this list since Sept 19, 2002, due to a physical move to a new residence in a different state, and haven't had time until now to figure out why, or to do any upgrades, etc. Please tell me I don't have to go back to Perl 5.6 (not that I've figured out what is new and wonderful in Perl 5.8 yet, I just don't want to have to go through the motions to recreate the older environment, knowing I'll just have to move forward someday). I did read through the subject lines of the messages I'd missed in the archives and the only reference I saw to Perl 5.8 was looking for a PPM (and hey, that would be a nice workaround for the moment, but it went unanswered as far as I could see). So does that mean few Win32::GUI-ers have upgraded, or that they've had no problems when they did? errors from make: link -out:blib\arch\auto\Win32\GUI\GUI.dll -dll -nologo -nodefaultlib -release -libpath:"D:\Perl\lib\CORE" -machine:x86 GUI.obj GUI_Constants.obj GUI_Helpers.obj GUI_Options.obj GUI_MessageLoops.obj GUI_Events.obj Animation.obj Bitmap.obj DC.obj Font.obj ImageList.obj Label.obj Listbox.obj ListView.obj NotifyIcon.obj Rebar.obj RichEdit.obj Splitter.obj TabStrip.obj Textfield.obj Toolbar.obj TreeView.obj GUI.res D:\Perl\lib\CORE\perl58.lib oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib netapi32.lib uuid.lib wsock32.lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib msvcrt.lib -def:GUI.def Creating library blib\arch\auto\Win32\GUI\GUI.lib and object blib\arch\auto\Win32\GUI\GUI.exp GUI.obj : error LNK2001: unresolved external symbol [EMAIL PROTECTED] GUI.obj : error LNK2001: unresolved external symbol [EMAIL PROTECTED] ImageList.obj : error LNK2001: unresolved external symbol [EMAIL PROTECTED] ImageList.obj : error LNK2001: unresolved external symbol [EMAIL PROTECTED] ImageList.obj : error LNK2001: unresolved external symbol [EMAIL PROTECTED] ImageList.obj : error LNK2001: unresolved external symbol [EMAIL PROTECTED] ImageList.obj : error LNK2001: unresolved external symbol [EMAIL PROTECTED] ImageList.obj : error LNK2001: unresolved external symbol [EMAIL PROTECTED] ImageList.obj : error LNK2001: unresolved external symbol [EMAIL PROTECTED] ImageList.obj : error LNK2001: unresolved external symbol [EMAIL PROTECTED] ImageList.obj : error LNK2001: unresolved external symbol [EMAIL PROTECTED] ImageList.obj : error LNK2001: unresolved external symbol [EMAIL PROTECTED] blib\arch\auto\Win32\GUI\GUI.dll : fatal error LNK1120: 12 unresolved externals -- Glenn = Not everything that is counted counts, and not everything that counts can be counted. -- A. Einstein
[perl-win32-gui-users] Re: repeating keystrokes in Win32::GUI Textfield
I just had a user that upgraded to WinXP report this same thing on a program I wrote, that works fine on Win2K. Using Win32::GUI 0.0.668, and Perl 5.6 or 5.6.1 (I'm using 5.8 now, but I'm not sure which version of Perl the user is running). I have no clue why this would happen, nor am I desirous of upgrading to XP to find out why help! Sounds like there must be some interaction between Win32::GUI and WinXP (I don't use Win32::GUI::Loft in that program) that is causing keystrokes to be seen twice. Daniel Quinlan wrote: I'm using Win32::GUI and Win32::GUI::Loft using Perl Dev Kit 5.0 on Windows XP Home. The problem I'm experiencing is with a Textfield element. When running the program, 90% of the keystrokes I type into the textfield (including backspace keystrokes) are repeated twice. The effect is visible as you type, so my guess is that the program is related to my use of Win32::GUI or Win32::GUI::Loft, but I haven't changed any Loft options for the textfield other than the name and the initial text. My Checkbox elements and a RichEdit element work fine. Any ideas? Dan ___ Perl-Win32-Users mailing list [EMAIL PROTECTED] To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs -- Glenn = Not everything that is counted counts, and not everything that counts can be counted. -- A. Einstein
Re: [perl-win32-gui-users] Re: repeating keystrokes in Win32::GUI Textfield
Sean Healy wrote: I just had a user that upgraded to WinXP report this same thing on a program I wrote, that works fine on Win2K. Using Win32::GUI 0.0.668, and Perl 5.6 or 5.6.1 (I'm using 5.8 now, but I'm not sure which version of Perl the user is running). I have no clue why this would happen, nor am I desirous of upgrading to XP to find out why help! Sounds like there must be some interaction between Win32::GUI and WinXP (I don't use Win32::GUI::Loft in that program) that is causing keystrokes to be seen twice. Daniel Quinlan wrote: I'm using Win32::GUI and Win32::GUI::Loft using Perl Dev Kit 5.0 on Windows XP Home. The problem I'm experiencing is with a Textfield element. When running the program, 90% of the keystrokes I type into the textfield (including backspace keystrokes) are repeated twice. The effect is visible as you type, so my guess is that the program is related to my use of Win32::GUI or Win32::GUI::Loft, but I haven't changed any Loft options for the textfield other than the name and the initial text. My Checkbox elements and a RichEdit element work fine. Any ideas? Dan -- Glenn In the past, when I've had a loop that's expecially long, I've placed a Win32::GUI::DoEvents call inside it so the window doesn't appear to be be hanging. I've noticed this effect when such a loop is going. Do you by chance have a loop with DoEvents in it? (The WinXP thing may be simply a coincidence.) Indeed I do have such a loop precisely in the area in which my user complained. Seems like the WinXP thing can't be completely coincidental, but may not be the root cause I guess I'd better upgrade my "GUIprompt" window to be a full-fledged window, although if I recall, that is going to be annoying, to structure the events appropriately. Daniel -- do you have a DoEvents loop too? -- Glenn = Not everything that is counted counts, and not everything that counts can be counted. -- A. Einstein
[perl-win32-gui-users] Bug in Win32::GUI 0.0.665 ???
Hi, I have a program that uses Win32::GUI, and in several places, it uses a DoEvents loop, and text boxes processed by that DoEvents loop seem to result in doubled characters. I don't recall that happening in earlier versions of Win32::GUI, does anyone else? So I recompiled Win32::GUI with several of the debug #defines in place, and started reading Win32::GUI code. I've not been a creater of Windows programs before Win32::GUI, so I'm not real familiar with the Windows API, but it is documented, sort of. So I figure debugging this will be a good learning experience to get me somewhat familiar with the Windows API, intensely familiar with Win32::GUI, somewhat familiar with XS, and perhaps able to contribute to its development. So first I had to figure out the message loop(s), since that is where all the action happens first. I notice that there is a discrepancy between the message handling in Win32::GUI::Dialog vs Win32::GUI::DoEvents vs Win32::GUI::DoModal. The message handling logic flow in all three procedures is very similar (and perhaps should be abstracted into a single procedure for ease of maintenance... maybe it wasn't because this is XS? I don't speak XS well, either) I notice that the logic flow includes 3 local variables: perlud, fIsDialog, and acc, that I wish to discuss here. Before setting perlud, fIsDialog and acc are both set to zero. After calculated perlud, if it validates, then fIsDialog is extracted from the dwPlStyle field. In DoEvents alone, the acc variable is also set in this block. In Dialog and DoModal, the local variable "acc" is not set, hence being left at NULL. However, the logic after that, identical in all three places, has two tests for (acc != NULL) which will never be true in Dialog or DoModal. It would appear that this could be a reason for accelerator keys not functioning in many circumstances? Or is it just extraneous code, and a bug in DoEvents? N.B. It seems that the code in Win32::GUI 0.0.558 was more complex (also checking a -accel key) for calculating the local variable "acc", but it did exist in both of them. DoModal didn't exist in 558, of course. -- Glenn = Not everything that is counted counts, and not everything that counts can be counted. -- A. Einstein
[perl-win32-gui-users] More on accelerators
Hi, Re: Win32::GUI 0.0.665 It appears that the code to implement accelerators doesn't even exist for the New Event Model. A DoEvent_NEM_Acc function is mentioned in some commented out code, but the function doesn't exist in the distributed source code. -- Glenn = Not everything that is counted counts, and not everything that counts can be counted. -- A. Einstein
[perl-win32-gui-users] Even more on accelerators
Hi,
Am I really confused, or are accelerators really, really broken? Some
reasonings that have led me to the conclusion accelerators are really,
really broken include:
(1) Win32::GUI::AcceleratorTable pushes a global variable $id for each
of the keystrokes in the accelerator table, resulting in any accelerated
keystroke for that table having the same "cmd" value of $id ... whatever
it happens to be at the time of the call. It would be extremely hard to
distinguish between keystrokes, when the WM_COMMAND message is received,
the cmd field is what gets supplied to identify the accelarator's
command, so any of the keystrokes would seem to do the same thing
but, read on...
(2) Win32::GUI::AcceleratorTable seems to keep a global counter of how
many accelerators have ever been defined, which gets incremented in the
loop but not used. Perhaps this is the value that should be pushed
instead of the global variable $id...
(3) The destruction of a global variable $Win32::GUI::AcceleratorTable
if it exists, seems to be just a misleading activity, probably leftover
code. It seems to imply that there can only be one accelerator table
defined, but in fact, $Win32::GUI::AcceleratorTable is never set, only
destroyed.
(4) When the WM_COMMAND comes in, the command code is known, and the
accelerator table could be looked up via perlud.hAcc from the current
active window. However, insteald the command code is looked up in the
otherwise unreferenced hash "Win32::GUI::Accelerators". It would seem
that the lookup process would first need to discover the perlcs{-accel}
value, to find the hash in which the accelerators were defined, and then
look in that hash to find the actual name of the command that is assigned.
(5) This is all based on command names, so it seems that there is no
code to support the New Event Model.
--
Glenn
=
Not everything that is counted counts,
and not everything that counts can be counted.
-- A. Einstein
[perl-win32-gui-users] PeekMessage, keyboard, DoEvents
Hi, So it seems to be the case that DoEvents loops and keyboard events don't do to well together... producing double characters while typing... almost all of the time. DoEvents uses PeekMessage to obtain its events, of course, whereas Dialog uses GetMessage. I don't recall this problem occurring on Win32::GUI 0.0.558 -- can anyone confirm that it did? If not, it seems to be related to Win32::GUI 0.0.665, perhaps. But I can't see any significant code differences in the DoEvents loop that would affect it in this manner. Then I get to wondering... the program in which I use DoEvents was written a couple years ago, and maybe I was using WinNT 4.0 SP3 then, and my users were on Win98. Now I'm using Win2K SP3, and my users have upgraded to WinXP, and were both able to produce the problem. So maybe it is a bug introduced in Win2K and not yet fixed in XP either, in the PeekMessage code? Thinking along those lines, and reading about how Get/PeekMessage worked back in the days they were last documented, which seems to be around the transition from Win3.1 to Win95, it sounds as if Get/PeekMessage uses some sort of timestamp based technique for determining the validity of messages. So maybe with fast processors these days, we can execute a whole loop of code, and get back before the clock ticks? Even, perhaps, the fairly high resolution one that surely must be used for Get/PeekMessage? So I added a call to sleep in the DoEvents code, conditional on it being a WM_CHAR, WM_KEYDOWN, or WM_KEYUP message, and was able to affect the percentage of keys that were duplicated in normal typing. So perhaps it is somewhat timing related. But if it were a Win2K/XP problem, you'd think it would show up in other programs that use PeekMessage loops. Anyone ever hear about that? Anyway, I never saw the effect when I was originally creating this program, so it seems that the problem has been created via a change to Win32::GUI or Windows itself. I've now read lots of Windows documentation and added a fair bit of extra debugging printfs to the Win32::GUI code, without finding anything obvious that is done wrong in Win32::GUI's DoEvents loop (regarding character duplication... in other emails I've revealed lots of missing code for Accelerator Keys), so I'm kind of at the end of my ideas regarding this. I did all the above testing on Win2K SP3, Perl 5.8.1 build 802, Win32::GUI 0.0.665, Althon 950 MHz. This morning I tested my same script on Win98 (1st edition), Perl 5.6.1 build 633, Win32::GUI 0.0.665, Pentium II 233 MHz. Same results. These are the only two machines I can easily test on. Anyone have some other ideas of things to try? -- Glenn = Not everything that is counted counts, and not everything that counts can be counted. -- A. Einstein
Re: [perl-win32-gui-users] PeekMessage, keyboard, DoEvents
Glenn Linderman wrote:
Anyone have some other ideas of things to try?
Sorry for following up my own post, but no one else did
Seems like if the problem were PeekMessage it would be possible to cause
problems
replacing the GetMessage call inside Win32::GUI::Dialog with
PeekMessage, so I replaced it with the following loop:
while ( ! ( stayhere = PeekMessage(&msg, hwnd, 0, 0, PM_REMOVE)))
{ WaitMessage();
}
But text entry fields are rock solid under this version of Dialog
too, but still produce duplicate characters under DoEvents. So there
must be something strange about DoEvents... or something it calls...
--
Glenn
=
Not everything that is counted counts,
and not everything that counts can be counted.
-- A. Einstein
Re: [perl-win32-gui-users] PeekMessage, keyboard, DoEvents
Glenn Linderman wrote: Sorry for following up my own post, but no one else did So then I thought maybe I was on to something when I discovered that Dialog uses ENTER; SAVETMPS; ... FREETMPS; LEAVE; but DoEvents doesn't. Well, I tried adding that, and it didn't help a bit. At least not with the double character problem. It does make you wonder if the above sequence is really necessary in Dialog, if it isn't necessary in DoEvents; or contrariwise, if it should be in DoEvents to solve some other problem besides the double character problems. Not being an XS expert, I couldn't say. I sort of barely grasp that it is something to do with variable lifetime scoping, but haven't figured out everything in perlguts yet, so can't yet draw broad inferences as to the potential impact of extra or missing scoping directives. -- Glenn = Not everything that is counted counts, and not everything that counts can be counted. -- A. Einstein
Re: [perl-win32-gui-users] Convert DEC RGB to HEX
On approximately 3/10/2003 3:56 AM, came the following characters from the keyboard of Dean Lennox: From the win32 gui example colors.gpl $color = GUI::ChooseColor(-owner => $w); Any idea how I can convert the decimal RGB value, $color to the HTML HEX format ? ie: selecting the colour green returns 65280 How do I convert this to the HTML HEX value: #00FF00 ? $color = 65280; # or $color = GUI::ChooseColor(-owner => $w); $html_hex = sprintf ( '#%06.6x', $color ); print $html_hex -- Glenn = If the grass is greener on the other side of the fence, try taking better care of your own side. -- Unknown
Re: [perl-win32-gui-users] Unresponsive Window
On approximately 3/31/2003 2:59 PM, came the following characters from
the keyboard of [EMAIL PROTECTED]:
Hello,
I have a script that gives the user options of which application to run on
a server from a drop down box, then when they pick the option and hit an
execute button the script opens a socket connection to a server on the
network. The server on the network than runs the application and sends
periodic updates back to the client (ex. Stage 1 complete, Stage 2
complete, etc..., Finished). These updates are printed out on a rich edit
field. When the execute button is clicked and the socket connection is
created the window becomes unresponsive except when a message comes back
from the server and is put on the rich edit field. For instance when I hit
execute I get a message back pretty quickly that the connection is made and
the server has started the application and is on stage 1. However, it
takes about 5 minutes for stage 1 to complete and during that time you
can't minimize the window, move it, or anything else. And if you go to
another app on the computer (IE, Word, email) and then back to the window
it won't refresh until another message comes back from the server. This is
a very annoying bug. Is there a way around this.
You can use a "DoEvents" loop... or you can use fork(). When you use
fork(), it is necessary for the parent to process the windows, and the
child to do the other activities. If the windows are created before the
fork(), it is possible for the child to see, access, and update the
window components, but not for it to respond to window messages. That
might be enough for your application, or you might need to define some
hidden "widgets" to be used for communication between parent and child.
I was thinking of using
fork() to call the socket connection that way technically it's running on
its own and the window remains responsive. I haven't used fork before and
I get two problems, the window is still unresponsive waiting for the server
to reply, and when I execute an app a second time I get a memory error
message but the program still runs and the window is updated as long as I
don't click "OK" to terminate the program from the error window. either
I'm doing something wrong or fork doesn't work with Win32::GUI (usually
when things don't work it's because I'm doing something wrong).
I have an application using fork() that doesn't get a memory error
message, so that is probably a function of your application, rather than
being endemic to Win32::GUI and fork().
Anyone
have a way to make this work. I checked the archives and it seems some
people have managed to get fork to work but they didn't post the code to
show how it's done. Also if there is a way to get this to work without
using fork even better. Eventually I will convert the script to an
executable using PerlApp from Activestate and I'm not sure how well fork
works with that.
Also is it possible to make a Rich Edit Field read only? I don't want the
user to be able to add, edit, or delete anything. I just want the
application itself to add text to the field.
Thanks,
Joe
Here are the relevant parts of the code:
#==
sub XButton_Click {
$MainWin->XButton->Disable();
$apppicked = $applist[$Appdropdown->SelectedItem];
print "Execute button clicked, got data: $apppicked\n";
CallServerApp($apppicked);# This calls the function that initiates
the socket connection
$MainWin->XButton->Enable();
}
#==
sub CallServerApp {
use IO::Socket;
# create the fork() pid
if(fork()) {
#create socket
$sock = new IO::Socket::INET(PeerAddr => 'xxx.xxx.xxx.xxx',
PeerPort => someport,
Proto=> 'tcp'
);
die "Socket could not be created. Reason: $!\n" unless $sock;
# send the name of the app that the user wants the server to run
print $sock $_[0] . "\n";
$sock->flush();
# print the replies from the server about the status of the app to the
RichEdit Field
while(<$sock>) {
$ResponseTF->ReplaceSel($_."\r\n");
$MainWin->Update();
$MainWin->DoEvents();
}
close($sock);
}
return 1;
}
---
This SF.net email is sponsored by: ValueWeb:
Dedicated Hosting for just $79/mo with 500 GB of bandwidth!
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
___
Perl-Win32-GUI-Users mailing list
Perl-Win32-GUI-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
--
Glenn
=
If the grass is greener on the other side of the fence,
try taking better care of your own side. -- Unknown
[perl-win32-gui-users] Re: CALL FOR BUGS
Hi Aldo, The next two paragraphs are kind of "pie in the sky" or "dream concepts"... but after them are some bug reports... Glad to see you back and working on Win32::GUI. I've been contemplating either (1) trying to fix and enhance it myself or (2) replacing it with something perhaps simpler, slower, and yet more general computers are fast these days, so perl code vs C code might be less significant... I thought about maybe doing something like allowing _every possible_ event to be intercepted, using something similar to your new event model... and just defining those events for which user actions are desire perhaps even via the standard Windows constants and anything not handled by the user would go to the default windows handler. It might be nice to have 2 functions, one called before the default windows handler, and one after, and also a flag saying the default window handler should be skipped. Or maybe it would be simpler to provide an API to invoke the default window handler from the user handler... and make the user responsible for calling the default handler, if desired, from those user defined event handlers. However, since the new event model seems to have much missing functionality in the 0.0.665 release, trying to get my own head around it was difficult, and yet I really didn't want to try to write something from scratch either. Attached are some messages from a couple months ago showing problems mostly in accelerator key support, both in the old and new event models. I must have accelerator key support in my next major project, so I must fix them (or replace Win32::GUI) if you don't I tried to use the new event model, with dynamically generated menus, and couldn't it seemed the events never got triggered. Perhaps something is missing there, or perhaps I didn't understand something. I've sort of abandoned that code, but if you know you've fixed something in that area, or implemented more of the new event model, I'd like to try it again. I'd like to convert fully to the new event model, or something similar. Stuart Arnold <[EMAIL PROTECTED]> appears to be new to Win32::GUI and has had lots of questions recently. One comment he made was about the use of the GWL_USERDATA field by Win32::GUI. While I initially thought it was quite reasonable for Win32::GUI to use this hook (one of the few provided by Windows API) for its own purposes, it would be nice to provide a replacement or, this hit me later... instead of having Win32::GUI use GWL_USERDATA to look up the Win32::GUI data structures given a window handle, it would be possible to just make a side hash structure, indexed by window handle, that would contain the Win32::GUI data this would leave GWL_USERDATA free for user data, as Stuart desired -- Glenn = If the grass is greener on the other side of the fence, try taking better care of your own side. -- Unknown --- Begin Message --- Hi, I have a program that uses Win32::GUI, and in several places, it uses a DoEvents loop, and text boxes processed by that DoEvents loop seem to result in doubled characters. I don't recall that happening in earlier versions of Win32::GUI, does anyone else? So I recompiled Win32::GUI with several of the debug #defines in place, and started reading Win32::GUI code. I've not been a creater of Windows programs before Win32::GUI, so I'm not real familiar with the Windows API, but it is documented, sort of. So I figure debugging this will be a good learning experience to get me somewhat familiar with the Windows API, intensely familiar with Win32::GUI, somewhat familiar with XS, and perhaps able to contribute to its development. So first I had to figure out the message loop(s), since that is where all the action happens first. I notice that there is a discrepancy between the message handling in Win32::GUI::Dialog vs Win32::GUI::DoEvents vs Win32::GUI::DoModal. The message handling logic flow in all three procedures is very similar (and perhaps should be abstracted into a single procedure for ease of maintenance... maybe it wasn't because this is XS? I don't speak XS well, either) I notice that the logic flow includes 3 local variables: perlud, fIsDialog, and acc, that I wish to discuss here. Before setting perlud, fIsDialog and acc are both set to zero. After calculated perlud, if it validates, then fIsDialog is extracted from the dwPlStyle field. In DoEvents alone, the acc variable is also set in this block. In Dialog and DoModal, the local variable "acc" is not set, hence being left at NULL. However, the logic after that, identical in all three places, has two tests for (acc != NULL) which will never be true in Dialog or DoModal. It would appear that this could be a reason for accelerator keys not functioning in many circumstances? Or is it just extraneous code, and a bug in DoEvents? N.B. It seems that the code in Win32::GUI 0
Re: [perl-win32-gui-users] How to define generic handler for buttons
On approximately 5/16/2003 8:32 AM, came the following characters from the keyboard of Frazier, Joe Jr: > It is all rather nasty looking code, but it works very well(except > there is not really an easy way to create accelorator keys for the > menu items since it is dynamic..) I reorder the menu items based on an LRU like scheme, and then assign accelerator keys (0-9) to the first 10 entries. It helps for frequently used items. -- Glenn = Wise men talk because they have something to say. Fools talk because they have to say something." -- Plato
[perl-win32-gui-users] Easter release?
Hi, Aldo? Still there? While lots of bugs were reported too shortly before Easter for me to expect an Easter release to actually happen, I'm curious to know if any progress is being made on any of the bugs, and if there actually will be a new release of Win32-GUI in the near future? I'm about to start a new project (next week), and need to make the decision about whether to (1) Use the new Win32-GUI release (2) hack up the old Win32-GUI to fix the bugs I care about (3) write a (probably less functional) replacement for Win32-GUI containing only the features I need for my project, or (4) figure out how to use Win32-GUI for dialog windows, and some other code for my main window. In particular, I need to be able to react to keystrokes regardless of the focus of the mouse within my main window accelerator keys, I guess it is called. Johan? Are you there? Does The GUI Loft cure the lack of accelerator keys? Or is is just stuck not being able to use them because of the lack of support in Win32-GUI? Anyone? any other comments on the current state of development? A few others have signed up as developers and/or documenters, so if you have additional insights that I'm missing, fill me in please. Thanks! -- Glenn = Wise men talk because they have something to say. Fools talk because they have to say something." -- Plato
[perl-win32-gui-users] Bug report
Sorry for the line wrapping...
The code below is from Win32::GUI v0.0.665 GUI.xs:
// add (or create) the tooltip
if(perlcs.szTip != NULL) {
if(perlcs.hvParent != NULL) {
if(perlcs.hTooltip == NULL) {
SV** t;
t = hv_fetch_mg(NOTXSCALL perlcs.hvParent,
"-tooltip", 8, 0);
if(t != NULL) {
>perlcs.hTooltip = (HWND) SvIV(*t);
}
}
if(perlcs.hTooltip == NULL) {
#ifdef PERLWIN32GUI_STRONGDEBUG
printf("XS(Create): creating
-tooltip...\n");
#endif
perlcs.hTooltip =
CreateTooltip(NOTXSCALL perlcs.hvParent);
}
}
The line that I've marked with > (line 641 of the released gui.xs)
produces a warning, text below:
Use of uninitialized value in subroutine entry at
C:/Perl/site/lib/Win32/GUI.pm line 524
The referenced line is a call to Win32::GUI::Create.
It seems like maybe the first -tip option defined in a subwindow results
in this warning. So it would appear that dereferencing SvIV(*t) is
what produces the warning. I don't (yet) speak XS well enough to say
anything more about what the bug might be, such that the warning is
generated.
I have some questions:
1) Does anyone else have sufficient knowledge to say anything more about
how to fix the problem?
2) Is there an easy way to see what (source) line of Perl is being
executed when debugging using VC++ and stepping through C code?
2b) Maybe a better question would be if there is a writeup or
suggestions for debugging XS code under Win32
3) When first starting Perl in the debugger, it claims that it's symbol
is from a file named "perlmain.c" which doesn't seem to exist (for
Win32) in ActiveState Perl build 805. What does this really mean?
3b) [Somewhat off-topic for this group] There was a perlmain.c under the
wince directory, but clearly it was the wrong one. Once a VC "workspace
for debugging" was told that association, though, it "remembered" it,
and I had to throw that workspace away, and start a new one to
"disassociate" that file from the startup. Is there an easier way to do
such disassociations?
After tomorrow, I probably won't be reading this group for about a week,
but I'll try to respond when I next get a chance.
--
Glenn
=
Wise men talk because they have something to say.
Fools talk because they have to say something." -- Plato
[perl-win32-gui-users] Win32::GUI bug fix, info, etc.
Hi Aldo,
Four topics:
1) Patch for some "uninitialized" warnings produced by Win32::GUI for
one of my GUI programs
2) Accelerator keys
3) Stuttering typing during repeated calls to DoEvents
4) resize cursor
Topic 1
Here is the fix (suggested by Jan Dubois, after I pinpointed where the
problem was happening) for a couple "uninitialized" references made by
Win32::GUI. Added code in red. Can you merge this into your development
source? I've tested that tooltips still work afterwards, and that the
warning message no longer gets generated.
GUI.xs:
// add (or create) the tooltip
if(perlcs.szTip != NULL) {
if(perlcs.hvParent != NULL) {
if(perlcs.hTooltip == NULL) {
SV** t;
t = hv_fetch_mg(NOTXSCALL perlcs.hvParent, "-tooltip", 8, 0);
if(t != NULL && SvOK( *t )) {
perlcs.hTooltip = (HWND) SvIV(*t);
}
}
if(perlcs.hTooltip == NULL) {
#ifdef PERLWIN32GUI_STRONGDEBUG
printf("XS(Create): creating -tooltip...\n");
#endif
perlcs.hTooltip = CreateTooltip(NOTXSCALL perlcs.hvParent);
}
}
Topic 2
Accelerator keys: seems like there's a lot of work to do to make them
work. Have you done or are you planning to do this work in the short
term? If I do some of the work for this, is there any chance it will get
merged into the real source for Win32::GUI ? Do you have any
recommendations for what approach (data structures and/or code paths)
should be taken for this, or can I just do what I want, as long as it
works !?
Topic 3
Stuttering typing during repeated calls to DoEvents. I really don't have
a lot of understanding of this problem. I can write a "pure perl" test
case that seems to do the same things as Win32::GUI with respect to
message queue handling, and it doesn't stutter. When I added traces for
the incoming messages, and for the calls to the DefWindowProc (in all
the places I could find that it is called) it seems to me like
Win32::GUI gets 1 WM_KEYDN, but 2 WM_CHAR and WM_KEYUP messages for each
keystroke pressed (from traces in DoEvents-- I added traces there, and
each other places that GetMessage and PeekMessage was called).
However, I must not have found all the places where they get processed:
I'd have thought they'd be passed through to DefWindowProc, but after
tracing all the references to DefWindowProc that I could find, I still
couldn't see where they were processed! So I set conditional breakpoints
on every MessageLoop function in GUI_MessageLoops.cpp, looking for a
WM_CHAR value in uMsg, and still no hits.
So I must confess to ignorance about how to debug this one. Give me some
ideas, and I'll try to do some more.
Topic 4
GUI 0.0.665 seems to have lost the ability to show the specialized arrow
cursors for resizing during when the cursor hovers over the borders.
While the -resizable => 0 option can eliminate the ability to resize
things, -resizable => 1 (or unspecified) allows resizing to happen, but
the fancy cursors are not used. I found the following discussion of the
those fancy cursors in MSDN. But I can't see where you handle the
WM_NCHITTEST message at all. This would imply that you pass it on to the
default window procedure. I set some conditional breakpoints on all the
GUI_MessageLoop functions for WM_NCHITTEST, and this was more fruitful
than trying to find WM_CHAR messages. I was able to hit one, and step it
through to the DefWindowProc, which return HTBORDER (which means you
can't resize, and means the cursor doesn't change shape). Why HTBORDER
is returned by the DefWindowProc is a mystery to me... I don't have a
clue at present about if the hwnd parameter passed is the correct one,
or if all of its parameters reflect the fact that the window was created
with WS_THICKFRAME (which it was, in my case). From the text from MSDN
(below), it explains that the action of the DefWindowProc in this case
is exactly what you should do if you don't want the arrows to show up!
I don't quite understand why there are so many different places to call
the default window procedure (I'm barely figuring out XS, much less all
of Win32::GUI). Seems like if they were all unified, that it would be
easier to instrument/trace messages that get passed to the default
window procedure and the responses.
The following from C++ Q&A, Periodicals 1996, in MSDN for VC++6.0:
How does Windows know to display that little size arrow cursor when the
user moves the mouse into the frame of a sizable window? By sending the
window a special message, WM_NCHITTEST. The window returns a code
indicating which area of the window the mouse is in. HTCAPTION says the
mouse is in the caption; HTMINBUTTON says it's in the minimize button,
and so on (see "Dave's Top Ten List of Tricks, Hints, and Techniques for
Programming in Windows," MSJ October 1992, for more information on
WM_NCHITTESTEd.). Of special relevance now are the hit test codes
HTLEFT, HTRIGHT, HTTOP, HTTOPLEFT, HTTOPRIGHT, HTBOTTOM, HTBOTTOMLEFT,
and HTBOTTOMRIGHT. As the names
[perl-win32-gui-users] no taskbar entry for a Win32::GUI program
From time to time the question has been asked on this list about how to have a Win32::GUI program running, but have no entry in the taskbar. When hidden and disabled, no entry will appear, but when shown or enabled, it will come back. Unless, when you create the window, you use: -toolwindow => 1, There is a more complicated solution, involving creating a fake main window, making a real main window with the fake main window as a parent, and then deleting the fake main window. This technique also works, but is much more complex than the option above. I've tested that option with 0.0.665. I don't think it is available in 0.0.558, although the technique may be available with the right parameter to -exstyle. -- Glenn -- http://nevcal.com/ === Wise men talk because they have something to say. Fools talk because they have to say something." -- Plato
Re: [perl-win32-gui-users] no taskbar entry for a Win32::GUI program
On approximately 6/25/2003 7:04 AM, came the following characters from
the keyboard of Frazier, Joe Jr:
>>-Original Message-
>>From: Glenn Linderman [mailto:[EMAIL PROTECTED]
>>Sent: Tuesday, June 24, 2003 10:07 PM
>>To: Win32 GUI
>>Subject: [perl-win32-gui-users] no taskbar entry for a Win32::GUI
>>program
>>
>>
>> From time to time the question has been asked on this list
>>about how to
>>have a Win32::GUI program running, but have no entry in the taskbar.
>>
>>When hidden and disabled, no entry will appear, but when shown or
>>enabled, it will come back.
>>
>>Unless, when you create the window, you use:
>>
>> -toolwindow => 1,
>>
>>There is a more complicated solution, involving creating a fake main
>>window, making a real main window with the fake main window
>>as a parent,
>>and then deleting the fake main window. This technique also
>>works, but
>>is much more complex than the option above.
>
>
>
> Glenn, I have not tried the above, but if it is what I "think" it is,
then the third solution (one I currently use in an application) is to
have your minimize and maximize events explicitly call hide() and
disable() / show() and Enable() respectivly. I wrap these up (with
other stuff) in a if ($window->IsVisable()) block:
>
> sub Window_Minimize {
>if ($Window->IsVisible){
>logit ("Window is Visible\n") if ($debug);
>$Window->Disable();
>logit ("Window Disabling\n") if ($debug);
>$Window->Hide();
>logit ("Window Hiding\n") if ($debug);
> $Window->CenterOnScreen(); Custom function added so it can
be called as a method (it is a hack and probably not a good idea, but it
does what I need it to do with no problems)
>$Window->NI->Modify( -id => 1, -tip => "Show PCKeys");
>$PopupMenu->{RestoreItem}->Enabled(1);
>$PopupMenu->{CloseItem}->Enabled(0);
>return 0;
>}
> }
>
>
> Then, since it is not visable in Task bar, etc, the only way to get
back is via my TrayIcon and here I put code to reverse the process:
>
> ub NI_Click { # NI is the name of the trayICON
>if ($Window->IsVisible){
>$Window->Disable();
>$Window->Hide();
> $Window->CenterOnScreen(); Custom function added so it can
be called as a method (it is a hack and probably not a good idea, but it
does what I need it to do with no problems)
>
>$Window->NI->Modify( -id => 1, -tip => "Show PCKeys");
>$PopupMenu->{RestoreItem}->Enabled(1);
>$PopupMenu->{CloseItem}->Enabled(0);
>return 1;
>}
>else {
>$Window->NI->Modify( -id => 1,-tip => "Hide PCKeys");
>$PopupMenu->{RestoreItem}->Enabled(0);
>$PopupMenu->{CloseItem}->Enabled(1);
>$Window->Enable();
> $Window->CenterOnScreen(); Custom function added so it can be
called as a method (it is a hack and probably not a good idea, but it
does what I need it to do with no problems)
>$Window->Show();
>$Window->SetForegroundWindow();
>$CBdropdown->SetFocus();
>return 1;
>}
> }
>
> When I get around to it, I will try your find. Thanks!
Hi Joe,
My second paragraph attempted to briefly describe that solution
which doesn't eliminate the task bar window during use of a window, but
does eliminate it while it is hidden and disabled. That is a nice
technique for programs that use a NotifyIcon as their interface when
they are hidden from the screen, yet would like one or more of their
windows to have task bar entries when they do appear on the screen.
That technique has been described before, which is why I gave it so
little discussion area, although it has been a good while now, so your
redscription of the technique is not inappropriate.
Rather, I was focusing on the slightly different question of how to have
a window that _never_ appears in the taskbar, which is what "-toolwindow
=> 1" achieves. This technique is useful for programs that use the
NotifyIcon as their interface when they are hidden from the screen, and
that probably only have one window at a time displayed, and don't feel
the need to have that window appear in the task bar (perhaps clicking
the NotifyIcon brings to the the front, so the task bar entry is not
needed).
Hopefully, some of this thread might make it in to the new documentation
project, somewhat edited for the different nature of documents vs
newsthreads.
--
Glenn -- http://nevcal.com/
===
Wise men talk because they have something to say.
Fools talk because they have to say something." -- Plato
Re: [perl-win32-gui-users] no taskbar entry for a Win32::GUI program
On approximately 6/25/2003 10:39 AM, came the following characters from the keyboard of Frazier, Joe Jr: >> -Original Message- From: Glenn Linderman >> [mailto:[EMAIL PROTECTED] >> >> On approximately 6/25/2003 7:04 AM, came the following characters >> from the keyboard of Frazier, Joe Jr: >> >>>> -Original Message- From: Glenn Linderman >>>> [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 24, 2003 10:07 PM >>>> >>>> From time to time the question has been asked on this list >>>> about how to have a Win32::GUI program running, but have no >>>> entry in the taskbar. >>>> >>>> When hidden and disabled, no entry will appear, but when shown >>>> or enabled, it will come back. >>> > > This bit here, in combination with the first sentance was what > confused me. My solution ( I assume someone on the list presented it > to me over 2 years ago when I created this app) does show the icon on > the task bar when the app is viewable on the screen, but not on the > task bar when minimized. I was just unclear that you mean no taskbar > icon "ever". Question? is it the disable or the hide that removes > from the taskbar? I have never really played with various > combinations to find out what does what in such a situation and what > happens to the main window compaired to the task bar icon. Do not > have time to check right now, but would make for more bulk in the > documentation being written It takes both "hidden" and "disabled" to remove a window's entry from the taskbar using this technique. And when you "show" or "enable", the taskbar entry comes back. >>>> Unless, when you create the window, you use: >>>> >>>> -toolwindow => 1, >>>> >>>> There is a more complicated solution, involving creating a >>> >> fake main >> >>>> window, making a real main window with the fake main window as >>>> a parent, and then deleting the fake main window. This >>>> technique also works, but is much more complex than the option >>>> above. >>> > > I just knowticed that this option also seems to get rid of my > Minimize button?? Hmm. So it does. And it gets rid of the Maximize button too. Except I see you didn't have a Maximize button already. Looks like -toolwindow overrides -maximizebox, -minimizebox, and -helpbutton, eliminating them all, as well as getting rid of the taskbar entry. > It also makes the "X" to close the > window like real small (1/3-1/2 normal size). This is on Win 2k. > Perl 5.6.1, GUI .668. I'm using Perl 5.8, GUI 0.0.668, for reference. I don't notice an appreciable difference is the size of my close box "X" by adding the -toolwindow, for my window definitions. I didn't try your window definition, though. However, maybe that was due to the fact that I specified the same -font parameter for both cases. With a -font parameter, you may be picking up different sized system fonts for the two cases. -- Glenn -- http://nevcal.com/ === Like almost everyone, I receive a lot of spam every day, much of it offering to help me get out of debt or get rich quick. It's ridiculous. -- Bill Gates
Re: [perl-win32-gui-users] no taskbar entry for a Win32::GUI program
On approximately 6/26/2003 5:57 AM, came the following characters from
the keyboard of Frazier, Joe Jr:
> See the attached file. The "X" icon is about 50% smaller than normal
> on my Win2k system (not tested elsewhere) using GUI .668 and
> Perl 5.0.1.
> use Win32::GUI;
> use strict;
> use warnings;
>
> package main;
>
>
> my $Window = new Win32::GUI::Window (
>-name => "Window",
>-topmost => 1,
>-left => 300,
>-dialogui => 1,
>-top=> 400,
>-width => 258,
>-height => 280, #235,
>-maxsize => [258,280],#[258,235],
>-minsize => [258,280],#[258,235],
>-text => "No Tool Window",
>-maximizebox => 0,
>-minimizebox =>1,
>-helpbutton => 0,
>-resizable =>0,
> );
>
> my $Window2 = new Win32::GUI::Window (
>-name => "Window2",
>-topmost => 1,
>-toolwindow => 1
Oops, you left out the ending , (comma). Only affected the -left
position, though, so not a big deal.
>-left => 600,
>-dialogui => 1,
>-top=> 400,
>-width => 258,
>-height => 280, #235,
>-maxsize => [258,280],#[258,235],
>-minsize => [258,280],#[258,235],
>-text => "With the ToolWindow",
>-maximizebox => 0,
>-minimizebox =>1,
>-helpbutton => 0,
>-resizable =>0,
> );
>
> sub Window_Terminate
> {
>return -1;
> }
> sub Window2_Terminate
> {
>return -1;
> }
> $Window2->Enable();
> $Window2->Show();
> $Window->Enable();
> $Window->Show();
>
> Win32::GUI::Dialog();
>
> Note that as of yet, I have not played with the various settings for
> minimizebox, etc. It does look kind of cool with the small button, but
> I would just like to know why
I got the same results with your test program as I did with mine. Perhaps
the close box is a little smaller, but certainly not as smaller as
yours. Perhaps this has something to do with other system settings
I changed the window labels, and added the commas, to make it easier to
do another experiment, but basically this screen shot uses the same
parameters as your program.
I note that the "system icon" is also gone on the toolwindow -- no
camel. So the -sysmenu option becomes overridden as well!
So I guess -toolwindow is pretty powerful. Not all of its effects are
necessarily desirable to all applications. The more complex, deleted
parent window method may be more appropriate for applications that
actually want a full-function window when it is displayed.
--
Glenn -- http://nevcal.com/
===
Like almost everyone, I receive a lot of spam every day, much of it
offering to help me get out of debt or get rich quick. It's ridiculous.
-- Bill Gates
<>
Re: [perl-win32-gui-users] Tooltips - do they work?
On approximately 7/4/2003 2:39 PM, came the following characters from the keyboard of Jeremy White: All, Do tool tips work? I've searched this list, and couldn’t find a reference to a working example? If anyone could provide pointers, I would be grateful, and will update the document project with an example. Cheers, Jez. Yes, tool tips work in at least some cases (I haven't found or searched for cases where they don't work -- but I've just used them with buttons and labels. Unfortunately, the examples that I have are not suitable for including in documentation, as I pass things through a couple layers of wrappers before it gets to a real Win32::GUI call. But the gist of it is just to add -tip => 'Configuration options menu', to the list of parameters when creating the item. I haven't attempted to change them dynmically, either. -- Glenn -- http://nevcal.com/ === Like almost everyone, I receive a lot of spam every day, much of it offering to help me get out of debt or get rich quick. It's ridiculous. -- Bill Gates
Re: [perl-win32-gui-users] Tooltips - do they work?
On approximately 7/5/2003 9:51 AM, came the following characters from the keyboard of Jeremy White: From: Glenn Linderman <[EMAIL PROTECTED]> Unfortunately, the examples that I have are not suitable for including in documentation, as I pass things through a couple layers of wrappers before it gets to a real Win32::GUI call. But the gist of it is just to add -tip => 'Configuration options menu', Thanks for the reply - I created a simple window, with one button with the tip option included. Still nothing…tried it under 5.6, and 5.8, both with 665. I’m on XP. Do I need to create event handlers or anything? I am just being stupid!? Perhaps, I should say what I think should happen - just in case I’m barking up the wrong tree - when the mouse hovers over the button, the little yellow box should appear with the text that was specified in the -tip option? Indeed, that is the sort of behavior you should expect, and that I get, with Win2K SP3 or SP4 (worked on both), Perl 5.8 build 805, Win32::GUI build 0.0.665. -- Glenn -- http://nevcal.com/ === Like almost everyone, I receive a lot of spam every day, much of it offering to help me get out of debt or get rich quick. It's ridiculous. -- Bill Gates
Re: [perl-win32-gui-users] Tooltips - do they work?
On approximately 7/5/2003 1:03 PM, came the following characters from the keyboard of Glenn Linderman: On approximately 7/5/2003 9:51 AM, came the following characters from the keyboard of Jeremy White: From: Glenn Linderman <[EMAIL PROTECTED]> Unfortunately, the examples that I have are not suitable for including in documentation, as I pass things through a couple layers of wrappers before it gets to a real Win32::GUI call. But the gist of it is just to add -tip => 'Configuration options menu', Thanks for the reply - I created a simple window, with one button with the tip option included. Still nothing…tried it under 5.6, and 5.8, both with 665. I’m on XP. Do I need to create event handlers or anything? I am just being stupid!? Perhaps, I should say what I think should happen - just in case I’m barking up the wrong tree - when the mouse hovers over the button, the little yellow box should appear with the text that was specified in the -tip option? Indeed, that is the sort of behavior you should expect, and that I get, with Win2K SP3 or SP4 (worked on both), Perl 5.8 build 805, Win32::GUI build 0.0.665. Oh, and maybe I should mention that tooltips don't _always_ show up. It seems that if another process is consuming all the CPU cycles, that tooltips are not displayed during that time. Maybe it is some "benevolent" way of shedding CPU activity since it is so loaded already? However, when I'm using a program that has tooltips, and they don't show up, I get aggravated but I do have a program that periodically slurps up all my CPU cycles, so I guess it is my own fault... but still, I think the tooltips should show up if you leave your mouse there long enough. -- Glenn -- http://nevcal.com/ === Like almost everyone, I receive a lot of spam every day, much of it offering to help me get out of debt or get rich quick. It's ridiculous. -- Bill Gates
[perl-win32-gui-users] bug fix for Win32::GUI 0.0.665 (on Perl 5.8.0)
For anyone with the ability to compile Win32-GUI, that has been annoyed
that the double-headed arrows don't show up to provide feedback to the
user that clicking and dragging at this point will resize a window, like
I have been, help is at hand-- I found the bug.
In the CommonMsgLoop function in GUI_MessageLoops.cpp, change case
WM_SETCURSOR to read as follows (white space reformatted somewhat from
the original):
case WM_SETCURSOR:
{
LPPERLWIN32GUI_USERDATA perlud;
perlud = (LPPERLWIN32GUI_USERDATA) GetWindowLong((HWND) wParam,
GWL_USERDATA);
WORD nHitTest = LOWORD( lParam );
// WORD wMouseMsg = HIWORD( lParam );
if( nHitTest == HTCLIENT ) { // only diddle cursor in client areas
if( ValidUserData(perlud) ) {
if( perlud->hCursor != NULL) {
SetCursor( perlud->hCursor );
return TRUE;
} else {
return FALSE;
}
}
return FALSE;
}
}
break;
Explanation: the prior code for WM_SETCURSOR was not sensitive to
whether or not the cursor was located in a window's client area or in
the window's non-client area. Therefore, same cursor was used
throughout both areas, based on the cursor defined for the window, or
the cursor defined for the window class. By only executing that logic
when the cursor is within the window's client area (see the check for
HTCLIENT in the code above) the cursor in the window's non-client areas
is handled by the DefWindowProc, which displays the double-headed arrows
when given the chance!
If there is still a maintainer of Win32::GUI, feel free to apply this as
a patch to the original source code. This bug was referred to as Topic
4 in the message entitled "Win32::GUI bug fix, info, etc." dated
6/24/2003 5:10 PM PT, and which was written in response to the Call for
Bugs for the never delivered Easter release of Win32::GUI, summarizing a
number of problems after it became clear that the Easter release didn't
happen in that time frame. The referenced message contains a different
bug fix, which hasn't yet resulted in a new release of Win32::GUI, so
that is why I wonder if there is still a maintainer.
--
Glenn -- http://nevcal.com/
===
Like almost everyone, I receive a lot of spam every day, much of it
offering to help me get out of debt or get rich quick. It's ridiculous.
-- Bill Gates
[perl-win32-gui-users] accelerator keys - now working
Hi, It was extremely important for my next project that I have accelerator keys working in Win32::GUI (or whatever interface I chose to code to). As it turns out, there were only a few scattered places to fix things, and I was able to get them working. However, along the way, for debugging purposes (debugging several things, see ** below), I have changed or rearranged a fair number of lines of code in a few of the source files. Hence, it is not particularly easy for me to describe herein the exact details of the fix. Having succeeding in this, my priority turns to my next project, rather than generating a minimal set of changes for a patch file... but if someone else wants to do that, to the end that it will be released into a new version of Win32::GUI, I'd be glad to share my changed files with them. If there is no hope of a new version of Win32::GUI, then after I'm done my next project, I might package and release all my changes in a branched version of Win32::GUI ... I guess it should be renamed, though, if it diverges from the original. ** I was debugging not only accelerator keys, but also resize cursor display (see recent message entitled "bug fix for Win32::GUI 0.0.665"), and attempts to debug the DoEvents double keystroke problem, although I gave up on that one for now. -- Glenn -- http://nevcal.com/ === Like almost everyone, I receive a lot of spam every day, much of it offering to help me get out of debt or get rich quick. It's ridiculous. -- Bill Gates
[perl-win32-gui-users] packaging into PPM
So what are the steps to package Win32::GUI (version 0.0.665) into a PPD file, so that it can be distributed? I know others have done it, but I have never made a PPD out of anything... Pointers to appropriate documentation is fine, if it covers everything needed, or pointers + specific things for Win32::GUI. -- Glenn -- http://nevcal.com/ === Like almost everyone, I receive a lot of spam every day, much of it offering to help me get out of debt or get rich quick. It's ridiculous. -- Bill Gates
Re: [perl-win32-gui-users] packaging into PPM
On approximately 11/7/2003 11:34 AM, came the following characters from the keyboard of Laurent ROCHER: Hi, So what are the steps to package Win32::GUI (version 0.0.665) into a PPD file, so that it can be distributed? I know others have done it, but I have never made a PPD out of anything... Pointers to appropriate documentation is fine, if it covers everything needed, or pointers + specific things for Win32::GUI. For make a binary package for ppm, you need a ppd file and a tar.gz file. 1) Build Win32GUI. perl makefile nmake 2) Tar gzip you blib directory into a Win32-GUI.tar.gz file. 3) Make a ppd file nmake ppd Edit this ppd file and replace HREF="" by HREF="Win32-GUI.targ.gz" 4) Distribute ppd and tar.gz in a zip file. See more at : http://aspn.activestate.com/ASPN/docs/ActivePerl/faq/ActivePerl-faq2.html#how_to_make_ppm_distribution Personnaly, i have a bat file doing this (and create html doc) : del Win32-GUI.ppd del Win32-GUI.tar del Win32-GUI.tar.gz del vc60.pdb del .\blib\arch\auto\Win32\GUI\GUI.pdb nmake ppd call pod2html -htmlroot=. GUI.pm -outfile=GUI.html call pod2html -htmlroot=. BitmapInline.pm -outfile=BitmapInline.html call pod2html -htmlroot=. GridLayout.pm -outfile=GridLayout.html mkdir /s blib\html\lib\Win32\GUI move GUI.html blib\html\lib\Win32\GUI.html move GridLayout.html blib\html\lib\Win32\GUI\GridLayout.html move BitmapInline.html blib\html\lib\Win32\GUI\BitmapInline.html tar cvf Win32-GUI.tar blib gzip --best Win32-GUI.tar perl -p -i.bak -e"s/HREF=\"\"/HREF=\"Win32-GUI.tar.gz\"/g" Win32-GUI.ppd del Win32-GUI.ppd.bak del pod2htm*.* del Win32-GUI.tar After i Zip Win32-GUI.ppd, Win32-GUI.tar.gz and a small Readme.txt. If you have a WebSpace, you can setup your own PPM repository. A PPMServer if you can run perl srcipt or a Simple Web repository. I personnaly setup up only a web repository. You copy all you ppd and tar.gz file into a directory. You replace HREF in all ppd by a full url to your tar.gz file. After you need to build 3 files using attached perl script. perl packagelst.pl > package.lst perl summary.pl > summary.ppm perl searchsummary.pl > searchsummary.ppm Send all file in your Web space and only setup PPM to use this repository. Laurent. Laurent, Thanks for the detailed explanation! Just what I need. I'll give this a whirl, and see what I wind up with as a result. -- Glenn -- http://nevcal.com/ === Like almost everyone, I receive a lot of spam every day, much of it offering to help me get out of debt or get rich quick. It's ridiculous. -- Bill Gates
Re: [perl-win32-gui-users] accelerator keys - now working
On approximately 11/7/2003 8:51 AM, came the following characters from the keyboard of Erick Bourgeois: On Wed, 05 Nov 2003 23:46:45 -0800, Glenn Linderman <[EMAIL PROTECTED]> said: Hi, It was extremely important for my next project that I have accelerator keys working in Win32::GUI (or whatever interface I chose to code to). As it turns out, there were only a few scattered places to fix things, and I was able to get them working. However, along the way, for debugging purposes (debugging several things, see ** below), I have changed or rearranged a fair number of lines of code in a few of the source files. Hence, it is not particularly easy for me to describe herein the exact details of the fix. Having succeeding in this, my priority turns to my next project, rather than generating a minimal set of changes for a patch file... but if someone else wants to do that, to the end that it will be released into a new version of Win32::GUI, I'd be glad to share my changed files with them. If there is no hope of a new version of Win32::GUI, then after I'm done my next project, I might package and release all my changes in a branched version of Win32::GUI ... I guess it should be renamed, though, if it diverges from the original. Glenn, Why don't you use CVS (the one already setup on SF.net) for all these much appreciated changes? It is indeed much easier to keep track of everything that way. Erick, That's a great suggestion. Except. 1) I don't have CVS installed; I haven't used it for about 6 years, and then only in an environment where there were explicit step by step instructions for that particular task (which isn't to say I don't understand source control facilities 2) I became an expert in ClearCase for a while, and PVCS/RCS, and SCCS in past lives, but just never have used CVS much) 3) I doubt that I have write permission enabled for the CVS repository; I'm going through the learning curve for Perl5 internals, Win32::GUI, and Windows's GUI API all at once, and I'm not sure I have the bandwidth for a CVS + Sourceforge learning curve too 4) There needs to be some coordination with Aldo, perhaps, and he hasn't responded publicly or privately to any of the email I've sent him regarding bugs over the last couple years. Or is the community ready to proceed without Aldo? 5) and because of the learning curves, I'm adding lots of debugging #if/#ifdef code all over Win32::GUI, and I'm not sure the real maintainers (if there are any left) would want all that cluttering the source code. So, if the changes are appreciated, and someone that is an expert in CVS + SourceForge wants to help me overcome the difficulties #1-3, and claim that #4 and #5 aren't problems, then I'd be glad to do just that. If not, well, maybe when I finish my current project (Feb or March?) then I'll look into tackling those learning curves without an expert. That said, I think it only took a dozen or so of real code changes to get accelerator keys working although I was really scratching my head trying to find one missing line... until I realized it was completely missing. -- Glenn -- http://nevcal.com/ === Like almost everyone, I receive a lot of spam every day, much of it offering to help me get out of debt or get rich quick. It's ridiculous. -- Bill Gates
Re: [perl-win32-gui-users] accelerator keys - now working
On approximately 11/13/2003 9:27 AM, came the following characters from the keyboard of Jeremy White: 4) There needs to be some coordination with Aldo, perhaps, and he hasn't responded publicly or privately to any of the email I've sent him regarding bugs over the last couple years. Or is the community ready to proceed without Aldo? Did you or anyone get a reply from Aldo about the latest round of emails? Not me. I can't speak for "anyone" of course. Perhaps we should try and move forward somehow. I've just looked through the mailing list and there are several other bug fixes that should be applied to any new build. In the short term, 1) I'd be glad to contribute my fixes to anyone that cares, that would be willing to CVS-ize them, and make them generally available. 2) I'd be willing to make available my binary distribution to anyone that wants my fixes (I've called it 0.0.668, since there were 3 fixes applied to 0.0.665), but I'm working on 0.0.669, adding more keys to the legal set of accelerator keys... all keys are legal accelerator keys to Windows, and only a subset were implemented in Win32::GUI. 3) I'd be willing to incorporate patches into my version, if someone identifies them, and sends me the patches, they aren't too cumbersome to apply, and make the merged binary distribution available. Then there is the documentation project headed up by Erick Bourgeois (http://jeb.ca/perl/win32-gui-docs/index.pl/home). We just need to get some momentum going... Accelerator keys could use more documentation now that I have them working. Any ideas/thoughts/suggestions? I'm sure everyone has their own hot buttons. I've mostly fixed my known ones, but as I proceed with my current project, I may run into other limitations or bugs. Probably it would be good to produce an error if the -name operand is omitted. And update the documentation to mention that it is required. What is the difference between Aldo, and Waldo ??? Where's Waldo? Cheers, jez. _ Find a cheaper internet access deal - choose one to suit you. http://www.msn.co.uk/internetaccess --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ Perl-Win32-GUI-Users mailing list Perl-Win32-GUI-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users -- Glenn -- http://nevcal.com/ === Like almost everyone, I receive a lot of spam every day, much of it offering to help me get out of debt or get rich quick. It's ridiculous. -- Bill Gates
Re: [perl-win32-gui-users] Change menu text
On approximately 11/13/2003 1:20 PM, came the following characters from
the keyboard of Jonathan Southwick:
Is it possible to change the text on a menu? I want to change a menu
item from "Refresh workgroups" to "Refresh clients" depending on what
view they are currently at. I am already keeping track of the view I
just need to change the menu text.
$m_config->{'sGetDataDir'}->Change( -text =>
"\x26reset data directory ($datadir)" );
Your menu object will be different than mine ($m_config), and your menu
item will be different than mine (sGetDataDir), and the text you want to
display will be different than mine ("\x26reset data directory
($datadir)", but this should give you the idea.
--
Glenn -- http://nevcal.com/
===
Like almost everyone, I receive a lot of spam every day, much of it
offering to help me get out of debt or get rich quick. It's ridiculous.
-- Bill Gates
Re: [perl-win32-gui-users] accelerator keys - now working
On approximately 11/13/2003 5:38 PM, came the following characters from the keyboard of Erick Bourgeois: On Thu, 13 Nov 2003 15:44:08 -0800, Glenn Linderman <[EMAIL PROTECTED]> said: Perhaps we should try and move forward somehow. I've just looked through the mailing list and there are several other bug fixes that should be applied to any new build. In the short term, 1) I'd be glad to contribute my fixes to anyone that cares, that would be willing to CVS-ize them, and make them generally available. I would be more than willing to bring the files together and serve them up on jeb.ca Not sure whether this includes CVS-ing them? I'm guessing that it doesn't, but would do the other half, of making them generally available. 2) I'd be willing to make available my binary distribution to anyone that wants my fixes (I've called it 0.0.668, since there were 3 fixes applied to 0.0.665), but I'm working on 0.0.669, adding more keys to the legal set of accelerator keys... all keys are legal accelerator keys to Windows, and only a subset were implemented in Win32::GUI. So would you put the .ppd and .tar.gz files up to, in a manner that PPM could use? 3) I'd be willing to incorporate patches into my version, if someone identifies them, and sends me the patches, they aren't too cumbersome to apply, and make the merged binary distribution available. Then there is the documentation project headed up by Erick Bourgeois (http://jeb.ca/perl/win32-gui-docs/index.pl/home). We just need to get some momentum going... Accelerator keys could use more documentation now that I have them working. Glenn, since you have fixed the bugs and are most familar (perhaps) with the code at this point, could you do the editing? Do you mind creating an account with my documentation content manager? This way I could set your priviledge to "Content Manager" and you could make all the changes you want to accelerator keys. I created the account and sent you a private note about that. It depends on how hard it is to learn your process for updating information. I'm trying to stay heads down on a project to get it done... but for sure after that I'd be willing to update. -- Glenn -- http://nevcal.com/ === Like almost everyone, I receive a lot of spam every day, much of it offering to help me get out of debt or get rich quick. It's ridiculous. -- Bill Gates And here is why it is ridiculous: The division that includes Windows posted an operating profit of $2.26 billion on revenue of $2.81 billion. --from Reuters via http://biz.yahoo.com/rc/031113/tech_microsoft_msn_1.html So that's profit of over 400% of revenue... with a bit more investment in Windows technology, particularly in the area of reliability, the percentage gain might go down, but so might the bugs and security problems? Seems like it would be a reasonable tradeoff. WalMart earnings are 3.4% of revenue.
Re: [perl-win32-gui-users] accelerator keys - now working
On approximately 11/14/2003 12:53 AM, came the following characters from the keyboard of Jeremy White: I would be more than willing to bring the files together and serve them up on jeb.ca Erick, are you able to generate flat html files which could be included automatically in new builds? Speaking of flat HTML files, I know that there are a bunch of HTML files that are included with the source distribution that are not included with the binary distribution. Laurent's instructions for making the binary distribution, which worked great overall (Thanks Laurent), include making a few pod2html files and including them in the distribution. I noticed that running pod2html on gui.pm produces an error (no title for GUI.pm) and that the corresponding GUI.html file is rather limited. I've mostly ignored POD in my Perl coding, so I don't have a clue what should be done to fix that... but maybe it isn't necessary since under docs/html there is a GUI.html which is the top logical layer of all the other HTML files in the distribution... so if those other HTML files could be included in the binary distribution in such a way that they appear as part of the ActivePerl documentation tree, that would be a much better solution, perhaps, than fixing the POD in GUI.pm From the way Laurent packaged the other two HTML files in his distribution, it would seem that it is just a matter of copying them to the appropriate subtree under blib\html\lib\Win32 It appears that is set up to allow for one HTML file for each package? Yet GUI.pm hyperlinks to other HTML files... some of which are for subpackages, and some of which are not. How does one handle the ones that are not? If we get more documentation into the distribution, then perhaps Erick could organize his site a little differently, to automatically include the distributed documentation (which it appears a lot of the documentation there is from the source distribution, but then there is more... at least the FAQ and code samples, I haven't compared all he other stuff against what is in the source distribution.) Maybe including documantation for several different releases? Maybe including a list of differences between different releases? I've lost track of the list of differences between 0.0.558 and 0.0.665, for example. I know the (incomplete) NEM was introduced, but what else? 3) I'd be willing to incorporate patches into my version, if someone identifies them, and sends me the patches, they aren't too cumbersome to apply, and make the merged binary distribution available. There were a couple of fixes for the splitter control that were mentioned a while back, I'll see if I can dig them out. I've also got a small extension to the datetime control that could go in to. I'd be willing to incorporate these if you can find them and email them to me. -- Glenn -- http://nevcal.com/ === Like almost everyone, I receive a lot of spam every day, much of it offering to help me get out of debt or get rich quick. It's ridiculous. -- Bill Gates And here is why it is ridiculous: The division that includes Windows posted an operating profit of $2.26 billion on revenue of $2.81 billion. --from Reuters via http://biz.yahoo.com/rc/031113/tech_microsoft_msn_1.html So that's profit of over 400% of investment... with a bit more investment in Windows technology, particularly in the area of reliability, the profit percentage might go down, but so might the bugs and security problems? Seems like it would be a reasonable tradeoff. WalMart earnings are 3.4% of investment.
Re: [perl-win32-gui-users] Change menu text
The \x26 is a hex escape for & which Windows uses to alert users to the
menu selection key.
Why I used \x26 instead of just saying & in that particular example text
string probably exceeds the bounds of your curiosity it has to do
with other tools I use that scan the source code looking for &, and
which aren't really smart enough at parsing Perl to figure out if an &
is in a comment or a string or whatever.
On approximately 11/14/2003 6:34 AM, came the following characters from
the keyboard of Jonathan Southwick:
Thanks, that worked. One question though, just because I am curious:
What does the 'x26' do?
Jonathan
At 11/13/2003 03:52 PM, Glenn Linderman wrote:
On approximately 11/13/2003 1:20 PM, came the following characters from
the keyboard of Jonathan Southwick:
Is it possible to change the text on a menu? I want to change a menu
item from "Refresh workgroups" to "Refresh clients" depending on what
view they are currently at. I am already keeping track of the view I
just need to change the menu text.
$m_config->{'sGetDataDir'}->Change( -text =>
"\x26reset data directory ($datadir)" );
Your menu object will be different than mine ($m_config), and your
menu item will be different than mine (sGetDataDir), and the text you
want to display will be different than mine ("\x26reset data directory
($datadir)", but this should give you the idea.
--
Glenn -- http://nevcal.com/
===
Like almost everyone, I receive a lot of spam every day, much of it
offering to help me get out of debt or get rich quick. It's ridiculous.
-- Bill Gates
---
This SF.Net email sponsored by: ApacheCon 2003,
16-19 November in Las Vegas. Learn firsthand the latest
developments in Apache, PHP, Perl, XML, Java, MySQL,
WebDAV, and more! http://www.apachecon.com/
___
Perl-Win32-GUI-Users mailing list
Perl-Win32-GUI-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
Jonathan Southwick
[EMAIL PROTECTED]
Technical & Network Services
Allegheny College
Meadville, PA 16335
(814) 332-2755
---
This SF.Net email sponsored by: ApacheCon 2003,
16-19 November in Las Vegas. Learn firsthand the latest
developments in Apache, PHP, Perl, XML, Java, MySQL,
WebDAV, and more! http://www.apachecon.com/
___
Perl-Win32-GUI-Users mailing list
Perl-Win32-GUI-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
--
Glenn -- http://nevcal.com/
===
Like almost everyone, I receive a lot of spam every day, much of it
offering to help me get out of debt or get rich quick. It's ridiculous.
-- Bill Gates
And here is why it is ridiculous:
The division that includes Windows posted an operating profit of $2.26
billion on revenue of $2.81 billion.
--from Reuters via
http://biz.yahoo.com/rc/031113/tech_microsoft_msn_1.html
So that's profit of over 400% of investment... with a bit more
investment in Windows technology, particularly in the area of
reliability, the profit percentage might go down, but so might the bugs
and security problems? Seems like it would be a reasonable tradeoff.
WalMart earnings are 3.4% of investment.
Re: [perl-win32-gui-users] Suggested addition to GUI.XS and some good news
Steve, I'd be glad to incorporate your routine into my code, which I hope someday to get on SourceForge. However, I have a question about it first. I'm not sure i is 100% complete, though... aren't there Win32::GUI data structures that need to be altered also? I think the tree of hashes that Win32::GUI creates during window creation includes a "-parent" field that sounds like it ought to be updated along with the theory that Windows's idea of the parent gets updated. Or maybe you've thought this through and have decided that it should be (for some reason, that maybe should be stated in the documentation for this function). Or maybe you've done that in your Perl code that calls this? Or maybe a lot of things. In spite of all that, if it seems to function correctly for you, adding it really wouldn't hurt anyone else even if it isn't 100% complete. And the other question, is where should it be added? I suppose to the main Win32::GUI package... Suggest a specific spot, though. On approximately 11/15/2003 5:14 PM, came the following characters from the keyboard of Steve Pick: Hi, Can anyone currently maintaining or debugging Win32::GUI add this to GUI.xs? It's a small change that lets you do SetParent() from Perl. I've written a dockable-windows routine (panes in your main window can be detached into windows) that works with my (very cool) packing grid object, which will be available to download soon. The docking routine needs to be able to change a window's parent (of course). This works with 665: ### # (@)METHOD:SetParent(VALUE) # Sets a windows parent handle # documentation. HWND SetParent(handle,value) HWND handle HWND value CODE: RETVAL = SetParent(handle, value); OUTPUT: RETVAL While I'm posting I might as well explain what the packing grid object does. It allows you to pack widgets into a grid. Heard that before? Well this does it with a difference. Each object you add to the grid can have properties assigned to it that dictate how it's aligned in the cell (left, center, right, top, middle, bottom) and whether it's stretched to fill the cell (vertically, horizontally or both). Each column or row in the grid can have a fixed width or a variable width. Variable-widthed columns or rows stretch to accommodate large widgets, and scale when the grid is resized (the entire grid can be given Width and Height). Still need more? Columns and rows can be resized. With my DragHandle object (which is a very simple label that can be dragged around the window using the mouse, and constrained horizontally and vertically, showing the appropriate cursors of course) you can implement mouse-dragable column/row sizes very easilly. These three modules are all almost complete, so you'll get them soon. They're all pure perl except for the one mod required for the dockable windows to work. Soon you'll be able to create slick apps *fast* :) Any questions, just ask. Steve --- This SF. Net email is sponsored by: GoToMyPC GoToMyPC is the fast, easy and secure way to access your computer from any Web browser or wireless device. Click here to Try it Free! https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl ___ Perl-Win32-GUI-Users mailing list Perl-Win32-GUI-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users -- Glenn -- http://nevcal.com/ === Like almost everyone, I receive a lot of spam every day, much of it offering to help me get out of debt or get rich quick. It's ridiculous. -- Bill Gates And here is why it is ridiculous: The division that includes Windows posted an operating profit of $2.26 billion on revenue of $2.81 billion. --from Reuters via http://biz.yahoo.com/rc/031113/tech_microsoft_msn_1.html So that's profit of over 400% of investment... with a bit more investment in Windows technology, particularly in the area of reliability, the profit percentage might go down, but so might the bugs and security problems? Seems like it would be a reasonable tradeoff. WalMart earnings are 3.4% of investment.
Re: [perl-win32-gui-users] I'm here
Hi Aldo, Glad to hear from you again. I would like CVS commit access on SourceForge, user name guruglenn although I may not be able to use it until next year (but that's only a couple months away). Thank you. I'm glad to hear you are working on NEM, as I think it is a friendlier model overall. Unfortunately, due to timing, I must proceed with my current project using the old event model + bug fixes. Regarding bugfixes, it would be nice to have them available on the current code base, but at this point, with many non-working features in your current development code base, it seems like simply releasing it wouldn't be practical. Although I haven't yet figured out SourceForge's CVS implementation, I know the general capabilities of a source code control system, having worked with SCCS, RCS, and ClearCase. And I think CVS is built on top of SCCS or RCS, so has the same capabilities, just packages them nicer? At least, I think that is how it started... Anyway, perhaps it would be nice to have two branches... a development branch and a bugfix branch. Perhaps you could continue on the NEM on the development branch, and let other people work on the bugfix branch, fixing bugs, and perhaps doing minor enhancements. If this sounds good to you, perhaps someone (I'd volunteer starting in Jan, but if there are other volunteers that's OK) could be the designated "pumpking" for the bugfix branch. On approximately 11/17/2003 2:47 AM, came the following characters from the keyboard of Aldo Calpini: hello Win32::GUI people I'm here, I'm here! I'm very, very sorry for my latitance. I know I have promised a lot of things, a lot of times, and never respected what I said. please accept my excuse for this. and I'm very, very happy to see things moving and people willing to help. as it is clear at this point, I'm not in the position to continue developing Win32::GUI all alone. but I'm not going to give up the project. if there is something useful for the community I can do acting as a coordinator (sort of "pumpking", in Perl terms), I'll be very happy to coordinate. if someone feels like taking over the whole stuff, I'll be very happy to be just a member of a team of developers. my current development version of Win32::GUI has many bugfixes, but the internals are being heavily reworked (to support NEM more "natively") and there are many non-working features. as an open question to anyone interested, I ask: do you think it is better to keep the "rewrite" off for a while and work on bugfixing the current release, or do you prefer working with me on the new internals? I can give all the tech help (eg. about XS and about how Win32::GUI works) to people who want to be part of the dev team. there's a mailing list (perl-win32-gui-hackers) that I set up just for this task. so, if you want CVS commit access on SourceForge, just give me your SourceForge user name and I will set it up. the -hackers mailing list can also be used to ask questions about how SourceForge and/or CVS works. regarding the documentation, I appreciate what Erick did, but I found it a little difficult to work with. I think a wiki (with CGI::Kwiki, for example) would be a better start. we could also write in POD so that the documentation could be more easily integrated in the CPAN distribution. I'm still backlogging all the messages on the list, so I will have more to elaborate on later. for now, please accept my most sincere and humble apologies for being such a non-existant person for so much time :-( cheers, Aldo __END__ $_=q,just perl,,s, , another ,,s,$, hacker,,print; --- This SF. Net email is sponsored by: GoToMyPC GoToMyPC is the fast, easy and secure way to access your computer from any Web browser or wireless device. Click here to Try it Free! https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl ___ Perl-Win32-GUI-Users mailing list Perl-Win32-GUI-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users -- Glenn -- http://nevcal.com/ === Like almost everyone, I receive a lot of spam every day, much of it offering to help me get out of debt or get rich quick. It's ridiculous. -- Bill Gates And here is why it is ridiculous: The division that includes Windows posted an operating profit of $2.26 billion on revenue of $2.81 billion. --from Reuters via http://biz.yahoo.com/rc/031113/tech_microsoft_msn_1.html So that's profit of over 400% of investment... with a bit more investment in Windows technology, particularly in the area of reliability, the profit percentage might go down, but so might the bugs and security problems? Seems like it would be a reasonable tradeoff. WalMart earnings are 3.4% of investment.
Re: [perl-win32-gui-users] I'm here
On approximately 11/20/2003 2:13 AM, came the following characters from the keyboard of Aldo Calpini: Erick Bourgeois wrote: Great to see you back. I installed and played with CGI::Kwiki. The main problem I have with this module/application is that users need to learn the wiki "language". (For example, to make a the H4 tag, you must put 4 = before and after the word(s).) I am planning to use plain POD for the Kwiki, there will be no need for wiki markup itself. The benefit of the content manager I use is that it uses HTML and thus it has no learning curve in this respect. May I ask what you found to be difficult? I've used it very little, but for example I seem to remember that making a link from a page to another one was a little messy (since the pages seem to be dinamically generated). but above all, the main problem is that I don't want HTML documentation, but rather POD that can be translated to HTML. translating from HTML to anything else is more painful (not impossible, but painful). and having the documentation in POD is unarguably a benefit (think about perldoc, search.cpan.org, etc.) Aldo, I really do believe this should help, otherwise it would be a bit cumbersome to completly move away from this and transfer over to CGI::Kwiki. But, like I said in an earlier post, if people really don't like it, then I guess I could switch over to CGI::Kwiki. so let's ask people what they prefer. I, personally, would go with CGI::Kwiki with native POD format for editing. let's vote this and decide :-) I prefer HTML, because it is easy to make links, because I understand it, and because it is a standard. I really should learn POD, though, since it is native to Perl, which I use unless I have to use something else. So I wouldn't complain about POD... so I guess my second choice would be POD, because it is the native Perl documentation format, and HTML can be produced. I don't know anything about CGI::Kwiki or wikis in general, but I guess they are collaborative editing things isn't CVS a collaborative editing thing too? Granted CVS probably has a bigger learning curve than a wiki (at least from what I've heard about wikis), but it provides version control, compact storage of multiple versions, selectable version retrieval, history, and trackability. Does a wiki provide all those things too? On the other hand, the current Win32::GUI seems to have a bunch of HTML files for which I cannot find POD sources. Is this just because you started in HTML before realizing the difficulties of translating it to something else? Or are the POD files squirrelled away somewhere, and not findable? Or? You are the only one that can tell us the history, whether accidental, shameful, or well-intentioned but misguided :) -- Glenn -- http://nevcal.com/ === Like almost everyone, I receive a lot of spam every day, much of it offering to help me get out of debt or get rich quick. It's ridiculous. -- Bill Gates And here is why it is ridiculous: The division that includes Windows posted an operating profit of $2.26 billion on revenue of $2.81 billion. --from Reuters via http://biz.yahoo.com/rc/031113/tech_microsoft_msn_1.html So that's profit of over 400% of investment... with a bit more investment in Windows technology, particularly in the area of reliability, the profit percentage might go down, but so might the bugs and security problems? Seems like it would be a reasonable tradeoff. WalMart earnings are 3.4% of investment.
[perl-win32-gui-users] Re: [perl-win32-gui-hackers] additional fix for cursors
Excellant. I had noticed the resize cursor persisted until the mouse pointer got to a "real" sub object inside the main window... annoying but not (to me) as annoying as not having the resize cursors at all, and not a problem on windows that are filled with sub objects. But this fix does the trick. Thanks, Steve. I've applied it to my version, and I'll be sure to coordinate with Laurent to get all my fixes into the bug-fix branch. On approximately 11/20/2003 4:36 PM, came the following characters from the keyboard of Steve Pick: In addition to Glenn Linderman's fix for resize cursors this should be put in (@)INTERNAL:Create(%OPTIONS) near the top: perlcs.hCursor = LoadCursor(NULL, IDC_ARROW); I've put it just below the line that reads perlcs.iEventModel = PERLWIN32GUI_EM_BYNAME; This will stop the cursor remaining as a resize handle, hourglass etc when moved inside the window. Steve -- Glenn -- http://nevcal.com/ === Like almost everyone, I receive a lot of spam every day, much of it offering to help me get out of debt or get rich quick. It's ridiculous. -- Bill Gates And here is why it is ridiculous: The division that includes Windows posted an operating profit of $2.26 billion on revenue of $2.81 billion. --from Reuters via http://biz.yahoo.com/rc/031113/tech_microsoft_msn_1.html So that's profit of over 400% of investment... with a bit more investment in Windows technology, particularly in the area of reliability, the profit percentage might go down, but so might the bugs and security problems? Seems like it would be a reasonable tradeoff. WalMart earnings are 3.4% of investment.
Re: [perl-win32-gui-users] TextField entry
Hi, the overall effect can also be achieved via accelerator keys...
define Enter as an accelerator key.
On approximately 11/26/2003 4:07 PM, came the following characters from
the keyboard of Steve Pick:
Hi,
I've just submitted an addition for Win32::GUI v0.0.665 which adds the
keycode and extra info as arguments to the onKeyDown handler. This allows
you to do this, to create a single-line text entry field which detects a
press of the Enter key.
my $textfield = new Win32::GUI::Textfield ($win,
-name => "textfield1",
-left => 0,
-top => 0,
-width => 100,
-height => 20
-multiline => 1,
-autohscroll => 1,
-autovscroll => 0,
-onKeyDown => \&keydown,
);
sub keydown {
my ($additional_data,$keycode) = @_;
if($keycode == 13) {
print "Enter has been pressed.\n";
}
}
Hopefully this will be included in the next CVS update, and will allow you
to get Enter presses without using that nasty "default button" method.
Steve
- Original Message -
From: "Johan Lindstrom" <[EMAIL PROTECTED]>
To:
Sent: Wednesday, November 26, 2003 2:04 PM
Subject: Re: [perl-win32-gui-users] TextField entry
At 01:58 2003-11-26, Ross Clunie wrote:
I would like to be able to use the ENTER key as an event trigger for a
textfeild. I have the _LostFocus event set and this works when the tab
key
is used but I would like ENTER key to emulate this function. Is it
poosible.
Fake it by adding a button that is -ok and/or -default (I think -ok is an
option proper). Turn off the -tabstop and put the button outside the
window
(e.g. at 10, 10).
The button's _Click event will be triggered when you press Enter in the
Textfield.
/J
-- --- -- -- -- -- - - -
Johan LindströmSourcerer @ Boss Casinos [EMAIL PROTECTED]
Latest bookmark: "Oracle9i Database Concepts -- Contents"
[perl-win32-gui-users] Re: TextField entry
I think it should work now in my version with the accelerator key fixes.
I'd be glad to send you that version for testing if you would like it; I
hope to get a patch to Laurent for the accelerator key fixes before the
weekend is over, and before my hard disk completely dies :( :( :(
On approximately 11/28/2003 6:13 AM, came the following characters from
the keyboard of Glenn W Munroe:
Glenn, I know that accelerator tables are broken and that you've put a
lot of work into figuring out why. I could never get them to work at all;
will this work now or just when the long-awaited fix is released? If it
will work now, would you please post a snippet of code so I can see what
I'm doing wrong?
Thanks,
Glenn Munroe
Hi, the overall effect can also be achieved via accelerator keys...=20
define Enter as an accelerator key.
On approximately 11/26/2003 4:07 PM, came the following characters from
the keyboard of Steve Pick:
Hi,
=20
I've just submitted an addition for Win32::GUI v0.0.665 which adds the
keycode and extra info as arguments to the onKeyDown handler. This allo=
ws
you to do this, to create a single-line text entry field which detects =
a
press of the Enter key.
=20
my $textfield =3D new Win32::GUI::Textfield ($win,
-name =3D> "textfield1",
-left =3D> 0,
-top =3D> 0,
-width =3D> 100,
-height =3D> 20
-multiline =3D> 1,
-autohscroll =3D> 1,
-autovscroll =3D> 0,
-onKeyDown =3D> \&keydown,
);
=20
sub keydown {
my ($additional_data,$keycode) =3D @_;
if($keycode =3D=3D 13) {
print "Enter has been pressed.\n";
}
}
=20
Hopefully this will be included in the next CVS update, and will allow =
you
to get Enter presses without using that nasty "default button" method.
=20
Steve
--
Glenn -- http://nevcal.com/
===
Like almost everyone, I receive a lot of spam every day, much of it
offering to help me get out of debt or get rich quick. It's ridiculous.
-- Bill Gates
And here is why it is ridiculous:
The division that includes Windows posted an operating profit of $2.26
billion on revenue of $2.81 billion.
--from Reuters via
http://biz.yahoo.com/rc/031113/tech_microsoft_msn_1.html
So that's profit of over 400% of investment... with a bit more
investment in Windows technology, particularly in the area of
reliability, the profit percentage might go down, but so might the bugs
and security problems? Seems like it would be a reasonable tradeoff.
WalMart earnings are 3.4% of investment.
[perl-win32-gui-users] Re: Accelerators again
On approximately 12/8/2003 5:47 AM, came the following characters from the keyboard of Glenn W Munroe: Glenn, Those accelerators are working fine and have fixed a couple of long-standing problems (like getting a listview labeledit to work). At first, I tried to attach them to individual controls, but found they only work at the window level. Then, when I looked inside the Win32::GUI main window hash, I see an 'accel' key for every control. Do you know if they were ever meant to work at control level? I take it you just use a big switch statement inside your key handler to see which control has focus and take the appropriate action? The code in Win32::GUI to handle -accel was actually already there... it just had some bugs. So actually the logic flow is a bit different than you seem to suppose. There is no "key handler"... Windows turns key up/down events into messages that get sent to the message queue of the currently active process... that message queue receives not only key events but also mouse events, click events, redraw events, drag-n-drop events, every kind of event that you can imagine. However, Windows guidelines tell you that there are certain APIs you should call to preprocess the message stream before dispatching the message to the window handler and they are related to keyboard handling Things like TranslateAccelerator, IsDialogMessage, TranslateMessage, and DispatchMessage (well, that isn't "before dispatching", that IS dispatching!). Now the way that Win32::GUI is handling accelerators is to look at an incoming event message, obtain the handle of that message, and then search upward in that window's parental tree until there is no more parent, and use the accelerator table defined for that window. I'm not exactly sure if that is a Windows-recommended technique or not, but that is how it works at present. It seems like it would be possible to pick up the "first defined" accelerator table in the parental tree, rather than walking up to the top before looking, although that would take more cycles per message to do so. I notice that both TranslateAccelerator and IsDialogMessage are passed the parent window handle, rather than the one the message came in on. Cheers, Glenn2 PS I hope you don't mind me contacting you directly like this, but until your fix gets into the main stream, there's not much point posting to the users list. I'll get the hint if you're busy... Well, I am busy... but not too busy to discuss recently release bug fixes. Laurent has picked up my fixes in his current bug-fix branch, but I'm not sure yet when an official bug fix release will be produced... maybe when the rate of fix submittals slows down enough to do so. The benefit of communicating on-list, is that the issue is better documented for future searches of the mailing list archives, educating the whole community rather than just ourselves! So I hope you don't mind my replying to the whole list, including your message. Glenn = signature-less today, it appears. Still reinstalling software on a new hard drive. The former signature will return, to everyone's dismay!
Re: [perl-win32-gui-users] Win32-GUI Release 0.0.670
If there are additional enhancements you need for TGL, maybe you could send a list of them to [EMAIL PROTECTED] ? I can only speak for myself, but it seems that TGL is a reasonably significant application of Win32-GUI, and supporting it is in the best interests of the Win32-GUI community. But I have no clue what you need, until you tell me, nor would anyone else. Perhaps you've mentioned it in the archives, but most of the archives are filled with questions from people that needed to add "-name" to their window parameters :) And in scanning the archives looking for stuff, it would be very easy to overlook something. On approximately 12/14/2003 11:45 AM, came the following characters from the keyboard of Johan Lindstrom: At 20:04 2003-12-14, Laurent ROCHER wrote: A new Win32::GUI release is availlable. This release come from 0.0.665 Fix CVS branch. Excellent work guys! (but still no DnD support it seems, so I can't actually use it for TGL without tweaking :) /J -- --- -- -- -- -- - - - Johan LindströmSourcerer @ Boss Casinos [EMAIL PROTECTED] Latest bookmark: "ONLamp.com Generating Database Server-Side Cros..." http://www.onlamp.com/pub/a/onlamp/2003/12/04/crosstabs.html dmoz (1 of 30): /Computers/Software/Databases/MySQL/ 142 --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Perl-Win32-GUI-Users mailing list Perl-Win32-GUI-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users -- Glenn -- http://nevcal.com/ === Like almost everyone, I receive a lot of spam every day, much of it offering to help me get out of debt or get rich quick. It's ridiculous. -- Bill Gates And here is why it is ridiculous: The division that includes Windows posted an operating profit of $2.26 billion on revenue of $2.81 billion. --from Reuters via http://biz.yahoo.com/rc/031113/tech_microsoft_msn_1.html So that's profit of over 400% of investment... with a bit more investment in Windows technology, particularly in the area of reliability, the profit percentage might go down, but so might the bugs and security problems? Seems like it would be a reasonable tradeoff. WalMart earnings are 3.4% of investment.
Re: [perl-win32-gui-users] Right-click menu broken in 0.0.670?
On approximately 1/2/2004 12:19 AM, came the following characters from
the keyboard of Johan Lindstrom:
After upgrading from 0.0.558 -> 0.0.670, the right click-menu seems
broken in TGL. The right-click menu displays alright, but the event
handlers never receive any calls. The normal menus attached to a normal
window works fine.
Actually I just installed the 0.0.665 version and it seems it is already
broken in that version.
I briefly diffed 558 and 665 but couldn't find anything obvious.
I didn't use 558 very long, so I'm not sure of all its features in
detail... I hadn't learned all of them before switching to 665 when it
came out.
In the above description you mention "right click-menu" But none of
your example code attempts to capture the "_RightClick" event. So I'm
not quite sure what you are asking.
I can, however, confirm that popup menus seem to work fine (for some
definitions of fine, at least) in 665 and 670, as I have a number of
applications that use them.
In comparing the code sequences between my working programs, and your
non-working test case, it finally hit me what the difference is
First see the code differences, then some more discussion. I'm actually
not sure what changed between 558 and 665 such that the 558 version
works the way you have it coded, and I did no research into that (at
least not yet).
The following minimal example works in 0.0.558, but not in later versions:
#!/usr/local/bin/perl -w
use strict;
use Data::Dumper;
use lib "..";
use Win32::GUI;
my $mnuMain = Win32::GUI::MakeMenu(
"&File" => "mnuFile",
" > &New\tCtrl+N"=> "mnuFileNew",
);
my $winMain = new Win32::GUI::DialogBox(
-left => 700,
-top=> 50,
-width => 300,
-height => 100,
-name => "winMain",
-text => "",
-menu => $mnuMain,
);
my $btnMenu = $winMain->AddButton(
-name => "btnMenu",
-text => "Popup Menu",
-left => 10,
-top => 10,
-height => 20,
-width => 100,
);
my $mnuPopup; # define this here, globally
$winMain->Show();
Win32::GUI::Dialog();
sub ::mnuFileNew_Click {
print "New selected\n";
return(1);
}
sub ::btnMenu_Click {
print "Popup menu\n";
# my # take out this "my"
$mnuPopup = Win32::GUI::MakeMenu(
"popup"=> "popup",
" > &Left"=> "mnuEditAlignLeft",
);
$winMain->TrackPopupMenu($mnuPopup->{popup},
$winMain->Left + $btnMenu->Left + 20,
$winMain->Top + $btnMenu->Top + 20,
);
return(1);
}
sub ::mnuEditAlignLeft_Click {
print "align left selected\n";
return(1);
}
__END__
Is this not the way to do popup-menus? Are there any examples working
with 0.0.670 I could try instead of my approach?
With the above changes, your sample code now works on 665 and 670.
Any reports of other applications that broke popup-menus? Any ideas from
the developers?
There are two problems with defining locally scoped menus: one, is that
they are gone before they can be used (not sure what 558 did differently
to make that work), and the second is that it consumes $MenuIdCounter
values which never get returned. Now that is a "big" number (for some
definitions of "big"), but even so, if a program repeatedly defines and
destroys menus, and loops on that long enough, it will "run out" and the
counter will "overflow" and "wrap around", and get back to reusing
numbers that may be in use for less dynamic menus, and things could get
confused. I think the effect would be that the less dynamic menus would
get wiped out by the more dynamic ones, and then they would quit
working, probably by starting to invoke menu entries from the more
dynamic menu that wiped them out. Not good.
The design of the menus (which I just figured out this last week,
actually) is clearly aimed at having menus that are defined once, mostly
statically. It is fine to use Change to alter the entries, it is less
fine to dynamically define and then discard entries, I think that not
all data in the Win32::GUI global structures (like %Menus) are returned
when a menu item is destructed.
By putting your menu definition inside another _Click routine (and I
didn't fix that, above, but moving it all up where the $mnuPopup
variable is now declared would do so) you are effectively dynamically
defining the menu just before popping it up. Now that the variable is
more global, the menu data stays around long enough to be found and
used. But reuse of the menu probably leaks resources through
redefinition of the menu.
So this response has
(1) demonstrated a workaround for your problem in the current sample code,
(2) discussed a possible resource leak ($MenuIdCounter values, and
possibly %Menus entries which would be a real memory leak) in
Win32::
Re: [perl-win32-gui-users] Right-click menu broken in 0.0.670?
On approximately 1/2/2004 9:38 AM, came the following characters from
the keyboard of Johan Lindstrom:
At 18:06 2004-01-02, Glenn Linderman wrote:
In the above description you mention "right click-menu" But none of
your example code attempts to capture the "_RightClick" event. So I'm
not quite sure what you are asking.
The button was just the easiest way to get a minimal test case, since
the menu itself came out fine I didn't figure that would make any
difference. Modulo the confusion :)
With your fix it works fine. Thanks!
Any reports of other applications that broke popup-menus? Any ideas
from the developers?
There are two problems with defining locally scoped menus: one, is
that they are gone before they can be used (not sure what 558 did
differently to make that work),
This is kind of weird. I didn't go for the global var, in my test case I
stuck it in a hash to keep it in scope. But IIRC, that's exactly what
the %Win32::GUI::Menus hash is for. Huh?
I think %Menus is used for lookup of commands when they arrive, and are
not part of the menu of the current window. Whether it has other
purposes or effects, I haven't yet figured out.
Another thing I just tried was this:
$winMain->TrackPopupMenu($mnuPopup->{popup},
$winMain->Left + $btnMenu->Left + 20,
$winMain->Top + $btnMenu->Top + 20,
);
print "TRACKED\n";
Win32::GUI::DoEvents();
print "Done events\n";
This prints:
TRACKED
align left selected
Done events
which means the WM_COMMAND is put in the message queue and then I force
it to be handled before the menu goes out of scope. Without the
DoEvents(), the menu goes out of scope, and the WM_COMMAND is processed
in the next message loop with no menu to be found.
Well, at least it's interesting :)
Yep. That is interesting.
and the second is that it consumes $MenuIdCounter values which never
get returned. Now that is a "big" number (for some definitions of
"big"), but even so, if a program repeatedly defines and destroys
menus, and loops on that long enough, it will "run out" and the
counter will "overflow" and "wrap around", and get back to reusing
numbers that may be in use for less dynamic menus, and things could
get confused. I think the effect would be that the less dynamic menus
would get
I think, with the code not-so-fresh in my mind, that if it really wraps,
the Win32::GUI::Menus hash will be overwritten with the new menu
handles, so that will work out fine. Not that it will wrap (isn't it a
long?)
Yes it is really big, so it shouldn't wrap soon. Yes the Menus hash
would be overwritten, but any static hashes created early in the
program, and expected to still function at the end, would be wiped out
along the way.
By putting your menu definition inside another _Click routine (and I
didn't fix that, above, but moving it all up where the $mnuPopup
variable is now declared would do so) you are effectively dynamically
defining the menu just before popping it up. Now that the variable is
more global, the
Which I have to do, since they are truly context sensitive. And I'm
willing to live with the minor resource waste.
I haven't figured out how much resource is wasted, hopefully it is
minor. But because it is presently unkonwn to me, I'd really rather not
take the chance that it causes problems for someone on a memory
constrained machine... or someone that leaves the program running for
days or weeks... those sorts of problems are extremely hard to figure
out when and if they happen.
Dynamic menus can be handled via Change. One can keep a cache of menus
of various ordinal size, and choose the one of the appropriate size, and
change the content dynamically. One could even dynamically eval the
_Click methods to do the right thing, dynamically. This would keep the
counter from wrapping, and any other resource leakage would be
minimized. It would require replacing Win32::GUI::Menu->new calls with
something that does the above, of course, which would be a little
complex to write at first, but probably as easy to use in the code as
Win32::GUI::Menu->new.
For your application, that may be overkill. For my applications, the
menus aren't all that dynamic, but for one of them I had the choice of
either dynamically recreating the same static menu over and over again
(which would have made some other things easier, perhaps), or working a
little harder to make them static and reuse them. Because of the
leakage issue, and because my program would be making heavy use of the
menus, and because the menus have many entries, it seemed possible that
the leakage could be a problem, so I worked a little harder to reuse them.
--
Glenn -- http://nevcal.com/
===
The best part about procrastination is that you are never bored,
because you have all kinds of things that you should be doing.
Re: [perl-win32-gui-users] RFC: Yet another event model, anyone?
Johan,
That is an interesting idea, and of course, makes things more OO-like.
OO-likeness, in my opinion, doesn't necessarily make something better,
but in this case there are a couple benefits that you point out: the
ability to have multiple instances of a Window or widget without name
conflicts, and confusion between the window object variable and its
name. The latter can be "worked around" with naming conventions, of
course, but the former requires either code duplication, or, well,
something like your new module, which is quite a bit of work.
What I can't tell by glancing at your module is whether you can deal
with existing windows using your module. One thing that works today
with Win32::GUI is that you can "take over" an existing Window, and
perform operations on it using the Win32::GUI methods. Does this still
work with your class? I don't know why it wouldn't, but then again, I
didn't try to prove that it would. Your comments on that topic would be
welcome.
Another orthogonal issue is the New Event Model. If it were finished
and working. NEM allows the event subs to be nameless. Of course,
there is still the problem of trying to support multiple instances of a
Window or widget. It is not clear, though, how your approach would
integrate into the NEM. Maybe that doesn't matter, except perhaps to
people that use it. I tried the NEM, but found too many bugs and
missing features. But it appears some people are using it.
None of my current Win32::GUI applications would currently benefit from
being able to have multiple instances of the same sort window, but I can
certainly envision some applications that I might want to write that
could benefit. So that is why I find it an interesting idea.
I imagine that it would be quite simple to add an additional parameter
to the event calls, which would be the window object, as the XS code
does have pointers to sufficient information. Whether that would have a
significant impact on performance, I do not know, but probably there
would be less impact than the approach you have taken in your pure Perl
proof of concept. Certainly it would be less code generated for an
application if done in XS, but also harder to maintain code, probably.
Not sure it would be much harder, though, but XS is more complex than Perl.
Well, there's some initial comments for you to ponder. Not clear that
I'll have the time or need to play with this at the moment, but maybe
someone will.
On approximately 1/4/2004 6:07 PM, came the following characters from
the keyboard of Johan Lindstrom:
When I first looked at Win32::GUI for the first time many many years ago
(4? ok, not so many) I found it kind of confusing how the objects and
events worked.
Coming from an OO background and with experience from a few other window
toolkits (VB and Borland TurboVision among others) I would have expected
to subclass the Window class, create an object, add controls to the
object, and then I would defined methods in my subclass to be called
when events fired. Kind of like this:
package DemoWindow;
#My DemoWindow is-a Window...
use base qw(Win32::GUI::Window);
#...but with event handlers for events that may fire
sub btnOk_Click { my $self = shift; #the Window object
#Change text of the clicked button
$self->btnOk->Text( "Ok - " . int(rand(100)) );
return(1);
}
But that's not how it works. Instead, event handlers based on the -name
of the windows and controls created. They are sub routines called in a
procedural fashion which requires me as an application programmer to
keep track of which window the event belongs to. This is not very
convenient.
I have not yet seen any "best practice" emerge for dealing with this.
Either the window variable needs to be a global or a singleton (which in
this case is the same thing, but without the stigma of globals, and
people don't argue back when you bring up the havey artillery of design
patterns), or it has to be connected to a global or singleton which is
your "application" object or whaterver. It's nothing that can't be
solved, but it's either inconvenient or not very maintainable.
One other drawback with the event-handler-as-procedure approach is that
there can only be one instance of the window, because if you create a
new window with the exact same names the event handler sub has no way to
determine which window fired the event. This can be coded around at
great inconvenience (with Perl, few things are impossible).
My point is: If only the Window object (or the window object of the
control) firing off the event was passed as the first parameter to the
event handler everything would be so much easier to live with. Finding
the event handler sub in the correct package (OO style) would be a boon.
Actually, the result of my holiday hacking today is a module that pretty
much does this. Win32::GUI::Window::Object
http://www.bahnhof.se/~johanl/perl/Win32GUI/Window/
T
Re: [perl-win32-gui-users] RFC: Yet another event model, anyone?
On approximately 1/4/2004 8:41 PM, came the following characters from
the keyboard of Glenn Linderman:
Johan,
That is an interesting idea, and of course, makes things more OO-like.
OO-likeness, in my opinion, doesn't necessarily make something better,
but in this case there are a couple benefits that you point out: the
ability to have multiple instances of a Window or widget without name
conflicts, and confusion between the window object variable and its
name. The latter can be "worked around" with naming conventions, of
course, but the former requires either code duplication, or, well,
something like your new module, which is quite a bit of work.
Oh, and the multiple instances issue can be worked around solely by
adding the extra parameter of window object pointer to the event
subroutines... if done internally to Win32::GUI, it wouldn't need to be
OO-like to solve the multiple instances problem.
What I can't tell by glancing at your module is whether you can deal
with existing windows using your module. One thing that works today
with Win32::GUI is that you can "take over" an existing Window, and
perform operations on it using the Win32::GUI methods. Does this still
work with your class? I don't know why it wouldn't, but then again, I
didn't try to prove that it would. Your comments on that topic would be
welcome.
Another orthogonal issue is the New Event Model. If it were finished
and working. NEM allows the event subs to be nameless. Of course,
there is still the problem of trying to support multiple instances of a
Window or widget. It is not clear, though, how your approach would
integrate into the NEM. Maybe that doesn't matter, except perhaps to
people that use it. I tried the NEM, but found too many bugs and
missing features. But it appears some people are using it.
Yet another orthogonal issue is whatever enhancements or newer models
Aldo might be working on for the next major version of Win32::GUI.
None of my current Win32::GUI applications would currently benefit from
being able to have multiple instances of the same sort window, but I can
certainly envision some applications that I might want to write that
could benefit. So that is why I find it an interesting idea.
I imagine that it would be quite simple to add an additional parameter
to the event calls, which would be the window object, as the XS code
does have pointers to sufficient information. Whether that would have a
significant impact on performance, I do not know, but probably there
would be less impact than the approach you have taken in your pure Perl
proof of concept. Certainly it would be less code generated for an
application if done in XS, but also harder to maintain code, probably.
Not sure it would be much harder, though, but XS is more complex than Perl.
Well, there's some initial comments for you to ponder. Not clear that
I'll have the time or need to play with this at the moment, but maybe
someone will.
On approximately 1/4/2004 6:07 PM, came the following characters from
the keyboard of Johan Lindstrom:
When I first looked at Win32::GUI for the first time many many years
ago (4? ok, not so many) I found it kind of confusing how the objects
and events worked.
Coming from an OO background and with experience from a few other
window toolkits (VB and Borland TurboVision among others) I would have
expected to subclass the Window class, create an object, add controls
to the object, and then I would defined methods in my subclass to be
called when events fired. Kind of like this:
package DemoWindow;
#My DemoWindow is-a Window...
use base qw(Win32::GUI::Window);
#...but with event handlers for events that may fire
sub btnOk_Click { my $self = shift; #the Window object
#Change text of the clicked button
$self->btnOk->Text( "Ok - " . int(rand(100)) );
return(1);
}
But that's not how it works. Instead, event handlers based on the
-name of the windows and controls created. They are sub routines
called in a procedural fashion which requires me as an application
programmer to keep track of which window the event belongs to. This is
not very convenient.
I have not yet seen any "best practice" emerge for dealing with this.
Either the window variable needs to be a global or a singleton (which
in this case is the same thing, but without the stigma of globals, and
people don't argue back when you bring up the havey artillery of
design patterns), or it has to be connected to a global or singleton
which is your "application" object or whaterver. It's nothing that
can't be solved, but it's either inconvenient or not very maintainable.
One other drawback with the event-handler-as-procedure approach is
that there can only be one instance of the window, because if you
create a new window with the ex
Re: [perl-win32-gui-users] New "Hook" Method
On approximately 1/6/2004 6:51 AM, came the following characters from
the keyboard of Stephen Pick:
Hi,
Arrrgh.
The Win32 API deals, in the most part, with pointers to structs rather
than structs themselves. You can't pass homemade structs as Perl
references to SendMessage and hope that they're magically converted into
C pointers, that would indeed be nice, but it just isn't how it works.
pack/unpack does seem to have a conversion feature that deals with
pointers, though, which I have to admit I have never figured out how to
use it, or for certain why the feature is included. None of the
examples show its use.
I've idly wondered, from time to time, if one could obtain a pointer to
a homebuilt struct via pack, and then pass that as an integer value via
Win32::API to a parameter that expects a pointer, and if that would
work. Of course, Win32::API provides support for passing pointers to
plain structs, so I've never had to worry about that in reality. But
then since SendMessage doesn't, maybe it would be useful there?
I offer these comments and speculations not in the knowledge that this
is a workable solution, but that it might be close to one... please
don't laugh me off the list if it is completely ridiculous. But it
seems I always have something else more important to do when I get near
the computer, rather than try out this sort of thing.
Another alternative, of course, is to use the Win32::API module to
create a new interface to the Windows SendMessage API rather than using
the one in Win32::GUI.
I recommend you take a look at the Win32::API module for Perl. This may
help you as it certainly helped me.
Steve
-Original Message-
From: Glenn W Munroe [mailto:[EMAIL PROTECTED]
Sent: 06 January 2004 14:28
To: 'Stephen Pick'; perl-win32-gui-users@lists.sourceforge.net
Cc: [EMAIL PROTECTED]
Subject: RE: [perl-win32-gui-users] New "Hook" Method
Thanks for that, Steve. I'll be looking out for the new
implementation.
In the meantime, I've been playing with some other messages and always
seem to hit the same problem with pointers to structures. When you say
"you can't use Perl to resolve the pointer" does that mean it is
impossible without XS code? Can you not just "pack" the correct
structure? For example, it would be nice to be able to select
all items
in a listview without going through a slow loop like:
for (0..$mw->lvList->Count()-1) {$mw->lvList->Select($_)}
Now,
$mw->lvList->Select(-1)
would be nice, but it doesn't work!
Taking an idea from the VB world I tried this:
use constant LVM_SETITEMSTATE => 0x1000 + 43;
use constant LVIF_STATE => 0x0008;
use constant LVIS_SELECTED => 0x0002;
my
$lvItem=pack("IiiIIp",LVIF_STATE,0,0,1,LVIS_SELECTED,"",0,0,0,0);
$mw->lvList->SendMessage(LVM_SETITEMSTATE, -1, \$lvItem);
Needless to say, it fails miserably. I assume the problem is with the
pointer to the structure. Is the structure wrong or is the
problem with
the Perl variable reference? I know that a Perl variable is
represented
by a C structure internally; can you get a pointer to the actual data
value without resorting to XS code?
Thanks again,
Glenn
-Original Message-
From: Stephen Pick [mailto:[EMAIL PROTECTED]
Sent: Monday, 05 January, 2004 06:46
To: [EMAIL PROTECTED]; perl-win32-gui-users@lists.sourceforge.net
Cc: [EMAIL PROTECTED]
Subject: RE: [perl-win32-gui-users] New "Hook" Method
Hi Glenn,
I've been trying to get the ListView EditLabel feature to
work. I can
turn it on OK and have got the handle to the edit control
and through
that the control's contents. The problem is that the control is
created
and destroyed automatically, and it is difficult to get
access to the
final data. According to MSDN, an LVN_ENDLABELEDIT notification is
sent
just before the control is destroyed, but I can't figure out how to
get
to that. Would the new "Hook" method work? Again, according to MSDN,
the
LVN_ENDLABELEDIT notification is sent in the form of a WM_NOTIFY
message. Would I have to grab that? That sounds like it may
be biting
off more than I can chew... Can you offer any pointers? Could you
perhaps post a snippet of code showing how the "Hook" method works?
You can't do this with Hooks at the moment. Personally I am not happy
with the current hook implementation as it does not satisfy what I
originally intended it to do. A new hook implementation should come in
the next few days, and I'll add the ability to hook notifications as
well as messages.
The problem is that WM_NOTIFY messages are delivered with an
lParam that
is a pointer to a structure containing the notification code (like
LVN_ENDLABELEDIT). While you can use the current hooks
implementation to
catch WM_NOTIFY and see the wParam and lParam arguments, the lParam
pointer is useless to you in Perl and you can't use Perl to
resolve the
pointer and get the notification code from it.
Watch this space...
Steve
-
[perl-win32-gui-users] Re: [perl-win32-gui-hackers] CVS commit
On approximately 1/7/2004 5:33 PM, came the following characters from the keyboard of Steve Pick: Hi, I've committed the updated hooks code in 665-Fix. See GUI.xs for the documentation for the Hook and UnHook functions. What's new: Hooks work in Old Event Model and New Event Model Thanks. The above should let me catch WM_MENUCHAR messages, which are needed in order to handle keystrokes that are not simple alphanumerics, when displaying menus. Eventually. When I get to it. -- Glenn -- http://nevcal.com/ === The best part about procrastination is that you are never bored, because you have all kinds of things that you should be doing.
Re: [perl-win32-gui-users] General Perl Text Extraction doubt
On approximately 1/8/2004 9:04 AM, came the following characters from the keyboard of #SHUCHI MITTAL#: Hi all Since everyone here is a perl expert and im a total newbie i would be very very grateful if someone could help me out with my doubts. Indeed everyone here is a perl expert... but this list is focused on use of Win32::GUI. So when you have broader questions, rather than GUI related questions, using a different forum is appropriate, and you will get a much broader range of experts to give you help. If you are working on Win32, I'd suggest joining and submitting this type of question to [EMAIL PROTECTED] I am doing a project to develop a student professor system including databases etc. To start off I need lots of professor data from various websites of educational institutions( for populating my database) . To extract this data and get started I decided to use perl since its text extraction capabilities are known to one n all. The problem is all these sites have a totally different HTML format and structure and differ in which the info of all profs is listed, and I cant seem to come up with a generic PERL code to extract this data and put it in text files on my local hard disk. Therefore I think ill need to use REGEX and PATTERN MATCHING to do the task but im not sure how to go about it. I wrote one code that works with www.ntu.edu.sg/sce/staffacad.asp but this is way to specific and doesnt work with any other staff sites.! I need to do the following: 1. Visit the base site of any institute and extract professor information which includes NAME,EMAIL,DEGREE,RESEARCH INTERESTS AND PUBLICATIONS RELEASED 2. For publications the listing either appears via a link on the profs homepages or as a chunk of data under the heading "PUBLICATIONS" etc. I think i can get the data if its via a link but i dunno hoe to extract that exact chunk in the middle of a page. 3. All this info shud be extracted to external text files I can manage if someone just helps me with snippets of code to gt started with the extraction...accurate extraction of information from any random site of a intitution which has profs listed etc. For example some sites are www.ntu.edu.sg/sce/staffacad.asp , http://www.ntu.edu.sg/eee/people/, http://www.ie.cuhk.edu.hk/index.php?id=6, http://www.ntu.edu.sg/mpe/admin/staff.asp Greatly appreciate any help in any direction...totally lost here..please feel free to ask if u have any doubts regarding my question! shuchi --- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html ___ Perl-Win32-GUI-Users mailing list Perl-Win32-GUI-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users -- Glenn -- http://nevcal.com/ === The best part about procrastination is that you are never bored, because you have all kinds of things that you should be doing.
Re: [perl-win32-gui-users] Updated sourceforge tracker
On approximately 1/13/2004 12:14 PM, came the following characters from the keyboard of Jez White: Hi, I've updated the bug/feature request tracker at: http://sourceforge.net/tracker/?group_id=16572 I've also added the bug about the broken menu tell tales. I would encourage you all to add your bugs and feature requests to the tracker! Works fine for me. See the note that I added to the bug, when closing it. (Yes, this is a nefarious scheme to actually get people to go to the bug tracker, and learn how to use it... yes, I could have answered it here... I was about to, and then I decided I should read all the responses first, and Jez set me up for this nefarious scheme, heh heh) cheers, jez. -- Glenn -- http://nevcal.com/ === The best part about procrastination is that you are never bored, because you have all kinds of things that you should be doing.
Re: [perl-win32-gui-users] Intermediate release of Win32::GUI
On approximately 1/13/2004 3:05 PM, came the following characters from the keyboard of Steve Pick: Before you build a new PPM, let me fix all the broken and/or horrible example code :) I don't know where half of the examples in the current PPM came from, but a lot of them don't work and I'm in the process of fixing them. Steve Thanks Steve. This'll likely make the first newbie question much more relevant to doing real work. -- Glenn -- http://nevcal.com/ === The best part about procrastination is that you are never bored, because you have all kinds of things that you should be doing.
Re: [perl-win32-gui-users] GroupBox tabbing
On approximately 1/14/2004 6:41 AM, came the following characters from
the keyboard of Chris Wearn:
Hi All,
When using AddGroupbox with RadioButtons, we have to use -group
with -tapstop. However I am trying to use a Groupbox to contain a number of
Textfields and other controls, and have not been able to tab at all.
Using the Groupbox works perfectly as a container and by using -parent,
resize event offsets are easier to calculate. The only thing I can't get
working is the ability to tab between the controls. Does anybody know the
correct way of doing this, or is it not possible?
Chris Wearn
#!perl -w
use Win32::GUI;
$MainWindow = new Win32::GUI::Window(
-title => 'tabbing',
-left=> 100,
-top => 100,
-width => 500,
-height => 400,
-dialogui => 1, # you might try adding this
-name=> 'MainWindow',
);
$MainWindow->{'-dialogui'} = 1; # or this, afterwards.
# I've used this form, but not the other, to do what I think
# you want to do.
$gpbSessSettings = $MainWindow ->AddGroupbox(
-name => "gpbThisSettings",
-left => 10,
-top=> 10,
-width => 250,
-height => 200,
-text => " SESSION SETTINGS",
);
# TEXTFIELD - Save Path
$txtSavePath = $MainWindow ->AddTextfield(
-parent => $gpbSessSettings,
-name => "txtSavePath",
-left => 10,
-top=> 20,
-text => "",
-width => 80,
-height => 22,
-group => 1,
-tabstop=> 0,
);
# TEXTFIELD - Save Name
$txtSaveName = $MainWindow ->AddTextfield(
-parent => $gpbSessSettings,
-name => "txtSaveName",
-left => 10,
-top=> 45,
-text => "",
-width => 80,
-height => 22,
-tabstop=> 0,
);
$MainWindow ->Show();
$rc = Win32::GUI::Dialog(0);
sub MainWindow_Terminate {
$MainWindow ->PostQuitMessage(1);
# return -1;
}
---
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html
___
Perl-Win32-GUI-Users mailing list
Perl-Win32-GUI-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
--
Glenn -- http://nevcal.com/
===
The best part about procrastination is that you are never bored,
because you have all kinds of things that you should be doing.
Re: [perl-win32-gui-users] Accelerator bug?
Glenn, Sorry for the delay, I was not monitoring this email address from 1/15 until now. On approximately 1/16/2004 8:28 AM, came the following characters from the keyboard of Glenn W Munroe: Glenn, I haven't really used the NEM much yet, but when I knocked up a small test script this morning with the new model I found that accelerators didn't work. Had you noticed this or can you confirm it? If so, is it a bug with accelerators themselves or some underlying "feature" of the system? Indeed, I think it is just a missing feature in NEM. When I looked at the code inside Win32::GUI for accelerators, I was able to figure out and fix accelerators for OEM, but I think NEM has much more code that simply isn't there for accelerators. This is one reason I am still using OEM. (OEM = Old Event Model, when it takes a break from meaning Original Equipment Manufacturer :) ) Regards, Glenn Munroe -- Glenn -- http://nevcal.com/ === The best part about procrastination is that you are never bored, because you have all kinds of things that you should be doing.
Re: [perl-win32-gui-users] Scroll bar example
On approximately 1/16/2004 8:26 AM, came the following characters from the keyboard of Stephen Pick: You must handle all scrolling yourself, as i've said a million times. I will look into MDIs when I have the time; win32::gui already seems to have an MDI object but I'm unsure of what it does. I'll add a note here... I have an app using a Win32::GUI::MDI window, in which I have added a label bitmap, and when the bitmap is larger than the MDI window scroll bars appear, and are active, with no coding on my part except the creation of the window, and the choice of specifically sized bitmaps to put inside the window. The scroll bars retain their state when different bitmaps of different sizes are swapped in, and I haven't figured out if there even is a way to "clear" that state. The scroll bars disappear if the bitmap is small enough. The scroll bars come back when needed. The scroll bars consume space within the MDI window when they appear, but not when they don't. If an old image bigger than the MDI window is replaced by a new image smaller than the MDI window, but big enough it consumes more space than the is available when the scroll bars are displayed, and the scroll bars are not selecting the top left corner of the display, the scroll bars don't go away. Have I seen them go away when they are finally scrolled to the top left corner by the user? I think so. Seems like they should go away immediately, though. Old memories, now, though, so some of this may be a little inaccurate. Seems like this sort of thing could be improved, by someone that knows more about Win32 programming than I have learned so far. -- Glenn -- http://nevcal.com/ === The best part about procrastination is that you are never bored, because you have all kinds of things that you should be doing.
