http://qs321.pair.com?node_id=11143398


in reply to Re^2: Unable to capture mouse events in Win32::Console
in thread Unable to capture mouse events in Win32::Console

somewhat fully loads 2 cores even without me touching anything

If I do a loop (similar to what fireblood used), then it does seem to hog at least one CPU if it can:

use strict; use warnings; use Win32::Console; use Time::HiRes qw(sleep); my $OUT = new Win32::Console(STD_OUTPUT_HANDLE); my $IN = new Win32::Console(STD_INPUT_HANDLE); my $save = $IN-> Mode; END { $IN-> Mode( $save )}; $IN-> Mode(( $save | 0x0010 ) & ~0x0040 ); # +MOUSE, -QUICK_EDIT $OUT->Write("Perl version $^V \n"); $OUT->Write("more text could go here\n\n"); my $n_buttons = $IN->MouseButtons(); $OUT->Write("Your mouse has $n_buttons buttons\n"); $IN->Mode(ENABLE_MOUSE_INPUT); my @info = $IN->Info(); $OUT->Write(sprintf "IN info:(%s)\n", "@info"); @info = $OUT->Info(); $OUT->Write(sprintf "OUT info:(%s)\n", "@info"); my $counter = 0; my %MouseFlags = ( FIRST_CLICK => 0, MOUSE_MOVED => 1, DOUBLE_CLICK => 2, MOUSE_WHEELED => 4, MOUSE_HWHEELED => 8, ); @MouseFlags{values %MouseFlags} = keys %MouseFlags; # reverse mapping while(1) { if($IN->GetEvents) { @console_events = $IN->Input(); local $" = ","; if( 2 == ($console_events[0]//0) ) { $OUT->Write(sprintf "Mouse (@console_events): (%d,%d) Btn= +%d Flag=%d:%s\r", @console_events[1..3], $console_events[5], $MouseFl +ags{$console_events[5]}); # I switched to \r so that the mouse events + wouldn't flood the screen, which was causing the mouse y coordinate +reported to be confusing, since it was scrolling the window, and it's + mouse-coordinate relative to the TOP of the console history } elsif ( 1 == ($console_events[0]//0) ) { $OUT->Write("Keyboard (@console_events)\n", ); exit if 27 == ($console_events[3]//0); # ESC = 27 } else { $OUT->Write("Unknown (@console_events)\n"); } } }

However, if I add a 10ms sleep in the else condition, then the CPU usage drops to virtually nothing, at least for me:

... # the code before the while loop is identical to the program listi +ng above use Time::HiRes qw/sleep/ while(1) { if($IN->GetEvents) { @console_events = $IN->Input(); ... } else { sleep 0.01; } }

Alternately, getting rid of the GetEvents also seems to not peg the CPU, at least for me:

... while(1) { @console_events = $IN->Input(); ... }

Info seems to produce valid list if STD_OUTPUT_HANDLE was used

I agree with the Anonymous Monk's assessment that STD_OUTPUT_HANDLE will give valid ->Info().

use strict; use warnings; use Win32::Console; my $OUT = new Win32::Console(STD_OUTPUT_HANDLE); my $IN = new Win32::Console(STD_INPUT_HANDLE); my @info = $IN->Info(); $OUT->Write(sprintf "IN info:(%s)\n", "@info"); @info = $OUT->Info(); $OUT->Write(sprintf "OUT info:(%s)\n", "@info"); __END__ IN info:() OUT info:(150 9001 0 15 7 0 0 149 29 150 71)

is built on same-time as Win32::Console i.e. dated and legacy some-middle-90s MS API.

I partially agree. Win32::GUI is built on the Win32 API, which has its roots in the 90s MS API -- but so are any Win32 API application. But MS specifically documents the Console+Mouse related calls as not recommended (see, for example, Mouse Event Record Structure, which is where the ->Input() results come from for Mouse events), whereas MS doesn't mark most of the Win32 API (like the Win32 controls, which is where Win32::GUI gets all of its pushbuttons, windows, etc) with similar verbiage

And regarding 2013 vs 2017: both are still too long since they were maintained and had reported bugs fixed: Win32::Console hasn't been updated since 2013; Win32::GUI hasn't been updated since 2017; both could stand some improvements, even in their handling of the underlying Win32 API, and especially in their documentation.