Starting a Python script thru a shortcut - how to detect the SHIFT key being pressed while doing it ?

Dennis,

I've been googeling for that, and somehow I get the feeling that it just stores the last keyboard event for those modifier keys. Which ofcourse means that it suffers the same problem as I started with.

formatting link

If you have wx installed, could you please check ? (Anyone else who has wx installed is invited too :-) )

Regards, Rudy Wieser

Reply to
R.Wieser
Loading thread data ...

On Mon, 17 Feb 2020 07:52:49 +0100, "R.Wieser" declaimed the following:

While I no doubt do have it installed on at least one machine, I haven't really used it. My primary usage of Python is quick&dirty programs typically processing batches of data into some format for later use. No GUI needed. The other problem is that my wxPython books predate the "Phoenix" rewrite and may not be applicable.

Heck, if Windows and/or Linux had an equivalent of Amiga Message Ports (needed to implement REXX port) I'd likely be using a port of REXX for some stuff.

Note that wx.KeyboardState is described as a base class for wx.KeyEvent

-- that means it has to be accessible when KeyEvent determines an event took place, not the other way around.

formatting link
(And it does look like pre-Phoenix modifiers were only available as properties of a key event
formatting link
). Having said that -- while I can call it anywhere without getting an error, it also is not detecting changes. And that is even in a keydown/keyup handler. I have verified that the meta keys WILL generate down/up events. Modifiers do not generate EVT_CHAR events.

Okay... I couldn't get wx.KeyboardState() to do anything desirable. It acted more like a way to SET modifier state!

BUT... I stumbled onto a wx.GetKeyState(key)

-=-=-=- pi@rpi3bplus-1:~$ cat wxstate.py #!/usr/bin/env python3 import wx import sys

class KeyState(wx.Frame): def __init__(self, *args, **kw): super(KeyState, self).__init__(*args, **kw) # self.ks = wx.KeyboardState()

print("KeyState init: %s, %s, %s" % (wx.GetKeyState(wx.WXK_ALT), wx.GetKeyState(wx.WXK_CONTROL), wx.GetKeyState(wx.WXK_SHIFT)))

if wx.GetKeyState(wx.WXK_CONTROL) and wx.GetKeyState(wx.WXK_SHIFT): sys.exit()

self.wdw = wx.Window(self)

self.SetFocus()

self.timer = wx.Timer(self) self.Bind(wx.EVT_TIMER, self.OnTimer)

self.timer.Start(1000)

def OnTimer(self, event): print("KeyState timer: %s, %s, %s" % (wx.GetKeyState(wx.WXK_ALT), wx.GetKeyState(wx.WXK_CONTROL), wx.GetKeyState(wx.WXK_SHIFT))) if wx.GetKeyState(wx.WXK_CONTROL) and wx.GetKeyState(wx.WXK_ALT): sys.exit()

app = wx.App()

frm = KeyState(None, title="Key State Test")

frm.Show()

app.MainLoop() pi@rpi3bplus-1:~$

-=-=-=- pi@rpi3bplus-1:~$ ./wxstate.py KeyState init: False, False, True KeyState timer: False, False, True KeyState timer: False, False, False KeyState timer: False, False, False KeyState timer: False, False, False KeyState timer: True, True, False pi@rpi3bplus-1:~$ ./wxstate.py KeyState init: False, True, False KeyState timer: False, True, False KeyState timer: False, False, False KeyState timer: False, False, False KeyState timer: True, True, False pi@rpi3bplus-1:~$ ./wxstate.py KeyState init: False, True, True pi@rpi3bplus-1:~$

-=-=-=-

NOTES: First run, held shift key down while pressing to start the script. Second run, held control key down... Third run, held both shift and control down...

Can not use ALT key in this test as it interferes with key operation.

Due to the test output I can not run it from file manager as it needs a console. Furthermore -- my configuration for .py files, when double-clicked results in a dialog asking

[Execute] [Execute in Terminal] [Open] [Cancel]

Something that may make you happy! Try this one... (You may need: sudo apt install python3-wxgtk4.0 )

-=-=-=- pi@rpi3bplus-1:~$ cat myApp.py #!/usr/bin/env python3 import wx import sys

logout = open("myApp.log", "w")

class GUIConfig(wx.Frame): def __init__(self, *args, **kw): super(GUIConfig, self).__init__(*args, **kw)

self.wdw = wx.Window(self)

self.SetFocus()

self.timer = wx.Timer(self) self.Bind(wx.EVT_TIMER, self.OnTimer) self.timer.Start(1000)

def OnTimer(self, event): if (wx.GetKeyState(wx.WXK_CONTROL) and wx.GetKeyState(wx.WXK_ALT) and wx.GetKeyState(wx.WXK_SHIFT)): logout.write(" held down -- exit GUI\n") sys.exit()

app = wx.App()

if wx.GetKeyState(wx.WXK_CONTROL) and wx.GetKeyState(wx.WXK_ALT): logout.write(" held on launch -- Running GUI for config\n") frm = GUIConfig(None, title="myApp Config GUI") frm.Show() app.MainLoop() else: logout.write("Run application in background?\n") pi@rpi3bplus-1:~$

-=-=-=-

First time, double-clicked .py file and then clicked [Execute]

pi@rpi3bplus-1:~$ cat myApp.log Run application in background?

Second time, double-clicked .py file, then held down while clicking [Execute]

pi@rpi3bplus-1:~$ cat myApp.log held on launch -- Running GUI for config held down -- exit GUI pi@rpi3bplus-1:~$

Exiting the GUI and entering the background application is left as an exercise -- my test code just kills the entire program.

--
	Wulfraed                 Dennis Lee Bieber         AF6VN 
	wlfraed@ix.netcom.com    http://wlfraed.microdiversity.freeddns.org/
Reply to
Dennis Lee Bieber

Dennis,

Thank you for having tested it. I'm quite hesitant to just install "stuff" to see if something works (and if not just have it weighing-down the 'puter).

Thanks for finding that one. And with your test it proves to work too. :-)

In between I search for some way to just check the keyboard state on Linux (as that in itself already seemed to be a problem), and stumbled over the next:

formatting link
(notice the last entry, using gtk/gdk)

... but while testing that (it works btw) I stumbled over something I did not consider: Both the SHIFT as well as the CTRL keys are modifiers when selecting (a range of) files.

I found that out when SHIFT-doubleclicking the Python script itself, and seeing a number of scripts opened (luckily in texteditors, as I have set that as the default action). The same (ofcourse) happens for shortcuts on the desktop.

In other words, using either the SHIFT or CTRL modifier keys is just waiting for something bad to happen. :-((

I've just tried also the left "windows" key, and although that works you need to push it twice, as the first time drops the system menu. The right one works OK, but isn't all that handy for a right-handed person. NUMLOCK and CAPSLOCK also seem to work, but as those are toggle keys ...

Moving back a bit I tried to search for a "regular" key that I could perhaps use, but although the ESC key doesn't do anything wierd at the time I click the C++ program, it directly closes any dialog the program displays (which I used to display the contents of "button_state").

Man, I really hate it when the OS is laughing in my face. :-)

Do you perhaps have any ideas ?

Regards, Rudy Wieser

Reply to
R.Wieser

On Tue, 18 Feb 2020 11:18:26 +0100, "R.Wieser" declaimed the following:

Common practice in file managers is that and mouse click will select everything from "first" (or last depending on sort order) that HAD BEEN selected up to the item just clicked upon. "adds" the clicked item to an ad-hoc selection.

This likely meant you had a file, somewhere else in the window, that had been "selected" (highlighted) when you on the new file.

If you first single-click the one file, then hold and double-click, it should only process that single file.

No...

--
	Wulfraed                 Dennis Lee Bieber         AF6VN 
	wlfraed@ix.netcom.com    http://wlfraed.microdiversity.freeddns.org/
Reply to
Dennis Lee Bieber

Dennis,

Yeah, I was also thinking of that.

But whats the chance that I - even just once - forget to do that, with a number of programs and/or scripts being ran as a result ? Nope, I'm not going to take that chance.

The problem ofcourse wil be quite a bit smaller using the CTRL key, but even that is not a chance I want to take. Murphies law and all that.

... though I'll still have to decide if the "windows" key (left or right) would still be usable.

Shucks. Thanks anyway.

Regards, Rudy Wieser

Reply to
R.Wieser

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.