ravenpi has asked for the wisdom of the Perl Monks concerning the following question:

Hi, all. I'm attempting to throw some characters into the keyboard buffer to "persuade" a reluctant DOS program to interact with me. It seems as if Win32::Console is the way to go about this, specifically with WriteInput(). That being said, I'm afraid I am below the lowliest of acolytes in the Great Perl Hierarchy, and my attempts to implement this with the (very) sparse documentation available have been futile. (I've been receiving UNDEF upon invocation, which means I goofed.) If someone could show me a functional snippet -- always assuming I'm not entirely barking up the wrong tree -- I'd be eternally grateful for the glimpse at Enlightenment.

Thanks kindly,


Replies are listed 'Best First'.
Re: Win32::Console question.
by technojosh (Priest) on Dec 17, 2007 at 17:17 UTC
    I had some luck with this:
    use Win32::GuiTest qw(:ALL);
    Win32::GuiTest CPAN link

    Specifically, i was interacting with the LPR printing program from the command prompt. You didn't cite any specific code up there so I'm not sure exactly what you are trying, but I got LPR to interact with me on the command line with some form of the code below:

    use strict; use warnings; use Win32; use Win32::Process; use Win32::GuiTest qw(:ALL); # start new command prompt my $process_object_cmd; Win32::Process::Create( $process_object_cmd, "C:\\Windows\\system32\\c +md.exe","",0, NORMAL_PRIORITY_CLASS, ".", ) or die "Could not spawn p +rocess\n"; &Set_Focus( "Command Prompt" ); my $ipAddress = 'test'; my $printName = 'test'; my $file = 'test'; # # Below in the qq[] is where I'd try sending some input to # whatever DOS app you're going for...here I'm printing # to LPR... # SendKeys( qq[lpr -S $ipAddress -P $printName filename $file] ); SendKeys( "~" ); # # If you need to send more keystrokes or whatever, check # the documentation, pretty much any keyboard stuff is # possible with that module # # Subroutine: Set_Focus # Parameters: window Name # Description: Takes the name of a window, uses tools from GuiTest to +set focus # to that window so that we may send it input. Returns + window ID sub Set_Focus { my $windowName = shift; my $retryCounter = 0; my @windows = FindWindowLike( undef, "$windowName", "" ); unless ( @windows ) { @windows = FindWindowLike( undef, "$windowName", "" ); sleep(1); $retryCounter++; if( $retryCounter == 5 ) { die "Unable to gain control of $win +dowName...\nScript exiting...\n" } } my $focusError = (bring_window_to_front( $windows[0] )); return( $windows[0] ); } # Subroutine: bring_window_to_front # Parameters: window ID # Description: Takes in window ID, and sets it as foreground window sub bring_window_to_front { my $window = shift; my $success = 1; unless ( $window ) { $window = "notyet" } unless( $window eq "notyet" ) { SetActiveWindow($window); sleep(1); SetForegroundWindow($window); } if ( $window eq "notyet" ) { #print "* Could not set the window id: $window active\n"; $success = 0; } return $success; }
    (My apologies if the example isn't exactly perfect, I chopped it out of a much larger program)

    This example will probably just print the LPR help stuff, since I use 'test' for all the connection strings, just thought I'd let you know. Also added a couple extra comments in the code...

      Awesome! An approach I hadn't even considered -- that'll do the trick. Thanks so much for a functional template; I should be able to warp that to my means. (And, for the record, I hadn't posted my code 'cause it could barely have been called code -- when I'm as lost as I was, it more closely resembles a grasping-at-straws approach than anything structured.)

        You might be embarrassed to have anyone see your code, but it's still a good idea to post code. Don't worry, no-one's here to pick on someone just because they're starting out or otherwise lacking knowledge.

        • Many problems aren't where the questioner thinks, so relevant information is left out. This will cost you and the people helping you of valuable time.
        • Some problems are easily recognized by inspection. No code ... no inspection! You're depriving someone of the chance to give you an immediately useful answer. Otherwise, it may take several exchanges to get the relevant information.
        • Many people will skip nodes without code, as they don't want to create an example from scratch. Many times it's much easier to fix something that's already there. Additionally, many monks are interested in helping those who make an effort. If the problem's not important enough for you to give a good, clear problem statement, then why is it worth my time? There's no shortage of questions to choose from. A chunk of code goes a long way in this regard (think "sweat equity").
        • Seeing your code gives a monk a general idea as to your skill level. That helps them not give advice at too high or too low a level. It also gives them the opportunity to offer advice on a particular concept that you're not clear on, or show you an interesting coding technique that could save you time.
Re: Win32::Console question.
by moritz (Cardinal) on Dec 17, 2007 at 17:04 UTC
    Show us the code you've got so far, otherwise we can't help you improving it.

    Disclaimer: I have no Win32 and won't be able to help you anyway, but other will. On Unix you'd use expect for these kind of things.