If I run cmd.exe, and from there run perl pm.pl, when I try to do any mouse, it is consumed by my cmd.exe > properties > options, so the script doesn't show any events. If I go to cmd.exe > properties > options, and turn off all the edit and text selection options, then run the script, it still grabs my mouse clicks -- and when I look, I see that it turned back on Quick Edit Mode and Insert Mode! If I do the sequence of run the script, then turn off all the edit options, if I click or wiggle, I do see a mouse event (#2):
C:\Users\peter.jones\Downloads\TempData\perl>perl pm.pl Perl version v5.30.0 more text could go here Your mouse has 5 buttons calling input method! An Event was detected! number= 6 event: 2 event: 42 event: 48 event: 1 event: 32 event: 0
Similarly, if I run from Explorer using my double-click association, so that it opens a new cmd.exe window (which doesn't inherit my default options with edit options enabled), I get events. (This was the reason I added the sleep(10): so that the created cmd.exe window wouldn't go away immediately after processing the mouse event(s).
update: As an aside, if I add the mode setting from vr's post (which I hadn't read yet when I created this post), modified to use Marshall's $IN console, then I find I don't need to futz with the cmd.exe properties manually. Thanks!my $save = $IN-> Mode; END { $IN-> Mode( $save )}; $IN-> Mode(( $save | 0x0010 ) & ~0x0040 ); # +MOUSE, -QUICK_EDIT
When looking at the adapted code, I have a nitpick and a query.
Nitpick: (this originated in fireblood's original): per Indirect Object Syntax, one should avoid the indirect-object style new Win32::Console(...) syntax, and instead use Win32::Console->new(...) syntax (or even the Win32::Console::->new(...) syntax; there are some circumstances where perl can interpret it ambiguously without both the :: and ->). It's not critical in this example, and I know that Win32::Console still recommends the old notation, but one can learn and use best practices even when the documentation/examples don't use it.
Query to Marshall: why are you throwing away the first @console_events ? You are actually getting two events, and only reporting the first. I can see this if I change the "calling input method!" print to $OUT->Write ("calling input method!" . @console_events . "(@console_events)\n");, at which point the above in-cmd.exe example becomes
C:\Users\peter.jones\Downloads\TempData\perl>perl pm.pl Perl version v5.30.0 more text could go here Your mouse has 5 buttons calling input method!6(2 42 47 0 32 1) An Event was detected! number= 6 event: 2 event: 42 event: 48 event: 1 event: 32 event: 0
For the if condition, did you really want to PeekInput of Win32::Console instead, or stick with GetEvents of Win32::Console as shown in the original, so that it polls whether there was an event, but doesn't remove the event from the queue? Or was there a specific reason for throwing away the first event?
Regarding the two mys, I am actually surprised there isn't a warning, because the my @console_events in the if condition is then masked by the my @console_events inside the block, but the use warnings isn't saying anything about it. (which it normally does, like in perl -le "use strict; use warnings; my $x; my $x" (warning: windows quote syntax, given the windows context of Win32::Console))
In reply to Re^3: Unable to capture mouse events in Win32::Console
by pryrt
in thread Unable to capture mouse events in Win32::Console
by fireblood
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |