Re: Screen Capture via wxPerl Script

[jmlynesjr]

Every post is a learning experience. "AM" thank you very much for your time and comments. I am always amazed at the time and effort donated by the Monks in answering questions.

Noted: I should have posted to SoPW rather that CUFP. I flipped a coin and picked the wrong place. I also should have linked to the original post and author. I got lazy and didn't look up how to do that.

The original script did not display the sample graphics in the frame. Thus my changes to the sample graphic code to get it to draw. "Bug" was the wrong word to use as was pointed out. The libraries certainly changed since 2003.

I saw the posts relating to the Win32 modules, but my goal is exploring wxPerl, so I didn't persue that option.

I saw a mention last night in the wxWidgets documentation to using Refresh before Update to force a screen repaint. Trying that in my original code worked differently, but not as I hoped. More reading is required.

My original post was cut and pasted from my wxperl_users email and must have gotten scrambled in the translation. Maybe that was the source of your compile problems. I have learned to post from the original file in the future, sorry.

Too bad wxWidgets can't select a specific window, but the explanation made sense.

I'm not informed enough to argue the wxPerl async issue, but I thought that was the purpose and function of event driven programming. It is in the real-time world I come from.

When I run your suggested code, the sample graphic is still not being drawn and I get the following warning:

(PM-ScreenCapture.pm:1799): Gtk-WARNING **: Tried to set the file choo
+ser to multiple selection mode, but this is not allowed in SAVE or CR
+EATE_FOLDER modes.  Ignoring the change and leaving the file chooser 
+in single selection mode.
saved /home/pete/Projects/perlprojects/CitrusPerl.proj/screenshot.png
saved /home/pete/Projects/perlprojects/CitrusPerl.proj/messup.png

I used the following structure from man Wx, but I really like your structure and plan to plagiarize it in the future! :)

       use Wx;

           my $app = Wx::SimpleApp->new;
           my $frame = Wx::Frame->new( undef, -1, 'Hello, world!' );

           $frame->Show;
           $app->MainLoop;

I considered using the file dialog, but went with the text entry dialog as a short cut. The file dialog is the better way to go.

The original script used Wx::Colour which was not found in the "standard" Citrus Perl @INC, but was found in a deeper directory. Thus the use lib '......' to point to the module.

Thanks again for the input. I have a lot to continue working with.

James

[Anonymous Monk]

The original script used Wx::Colour which was not found in the "standard" Citrus Perl @INC, but was found in a deeper directory. Thus the use lib '......' to point to the module.

What you found was GD::Colour which is not at all the same thing. Wx::Colour used to be a seperate module, it isn't anymore. use Wx; gets you Wx::Colour

[jmlynesjr]

Oops! That could make a difference...Need to change that and see what changes. Thanks again! ---James

[Anonymous Monk]

I'm not informed enough to argue the wxPerl async issue, but I thought that was the purpose and function of event driven programming. It is in the real-time world I come from.

Well, I really don't know what you mean by events and "main-line code" run asynchronously. I took it to mean you're talking about the perl code, and since it doesn't use fork or threads, doesn't open any sockets or files, look all synchronous to me

[jmlynesjr]

We may be talking apples and oranges, but I am enjoying and learning from this conversation.

My definition of "main-line code" is the stuff between my $app = Wx::SimpleApp->new; and $app->MainLoop;.

Within this segment, the frame is created and the onPaint event handler is defined. onPaint is never called directly, but is called "asynchronously" from within the bowels of Wx. I moved the TakeScreenshot($self, $file); call to various places within the main-line and onPaint segments with various results. Usually only capturing the background window not the sample window.

The sample screen is drawn by a continuous block of code(within the onPaint event handler)immediately followed by TakeScreenshot. On my PC, the screen doesn't paint completely in one motion, but paints the three circles and the first block of text followed by a blink and the next two blocks of text. Given this, it is strange that some of the time a complete screen is captured to the file. Mostly only the three circles and first block of text gets captured. All the drawing code runs before the capture code is called, so the $64,000 question is why is only a partial screen being captured(most of the time)? As Spock would say, "illogical".