I'm talking about <<NotebookTabChanged>> event that ttk.Notebook can be bound to. Say I have:
def tabChanged(self, event):
print "tab changed"
And say I want to manually trigger this method. What I actually mean by this is, say I have a basic, tabbed GUI and there's a start button which makes plots when you click it. There are plots on each tab and when you change tabs, <<NotebookTabChanged>> is triggered, which is an automatically created event by ttk.Notebook. I already have a self.tabChanged method for this case. What I wanna do is, I wanna make my start button trigger this event so I don't have to create a new method just for the button which will do the exact same thing as self.tabChanged. So I need a way of triggering the event through a button click, but remember, that event is ttk.Notebook's own event and apparently it was designed to be used with tabs, not buttons. Is there a way to trigger <<NotebookTabChanged>> manually with a button click?
You can generate virtual events (eg: events that begin and end with << and >>) with event_generate:
self.the_notebook.event_generate("<<NotebookTabChanged>>")
Related
When reading events from a simple button in PySimpleGui, spamming this button with mouseclicks will generate an event for each of the clicks.
When you try to do the same with Listboxes (by setting enable_events to True for this element) it seems like there is a timeout after each generated event. If you click once every second, it will generate all the events. But if you spam-click it like before it will only generate the first event.
I'm not sure if this behavior is intended (only started learning PySimpleGui today), but is there a way to get rid of this delay? I tried checking the docs but can't find it mentioned anywhere.
I think the reason is that a Listbox reacts to click events, but also to double click events. A Button does not. This behavior looks like consistent.
Morning, I would like to call a function in my GUI in the event that the content of a TextCtrl is changed. Only after the user leaves the TextCtrl object though, not during editing.
Please can you help me find the right event handler to use, I'm very new to wxpython and I can't even find a list of allowable events.
Many thanks
You can bind the TextCtrl to wx.EVT_TEXT to capture changes to the value and wx.EVT_KILL_FOCUS to trigger an even when the focus changes. Alternatively you could bind it to wx.EVT_SET_FOCUS and save the current TextCtrl value and also bind to it wx.EVT_KILL_FOCUS to and compare the new value to see if it's changed.
------- EDIT -------
WxFormBuilder is fantastic tool for quickly creating basic UIs. It will also show you every event that you can bind to a widget by clicking on the 'events'` tab.
I have a Qt program with many buttons, user-interactable widgets, etc.
At one stage in the program, I would like all the widgets to temporarily 'stop working'; stop behaving to mouse clicks and instead pass the event on to one function.
(This is so the User can select a widget to perform meta operations. Part explanation here: Get variable name of Qt Widget (for use in Stylesheet)? )
The User would pick a widget (to do stuff with) by clicking it, and of course clicking a button must not cause the button's bound function to run.
What is the correct (most abstracted, sensible) method of doing this?
(which doesn't involve too much new code. ie; not subclassing every widget)
Is there anything in Qt designed for this?
So far, I am able to retrieve a list of all the widgets in the program (by calling
QObject.findChildren(QtGui.QWidget)
so the solution can incorporate this.
My current horrible ideas are;
Some how dealing with all the applications events all the time in one
function and not letting through the events when I need the
application to be dormant.
When I need dormancy, make a new transparent widget which recieves
mouse clicks and stretch it over the entire window. Take coordinates
of click and figure out the widget underneath.
Somehow create a new 'shell' instance of the window.
THANKS!
(Sorry for the terrible write-up; in a slight rush)
python 2.7.2
PyQt4
Windows 7
You can intercept events send to specific widgets with QObject::installEventFilter.
graphite answered this one first so give credit where credit is due.
For an actual example in PySide, here's an example you might draw some useful code from:
my_app.py
from KeyPressEater import KeyPressEater
if __name__ == "__main__":
app = QApplication(sys.argv)
eater = KeyPressEater()
app.installEventFilter(eater)
KeyPressEater.py
class KeyPressEater(QObject):
# subclassing for eventFilter
def eventFilter(self, obj, event):
if self.ignore_input:
# swallow events
pass
else:
# bubble events
return QObject.eventFilter(self,obj,event)
I use GtkAboutDialog and everything works fine except the close button of this widget. All other buttons works fine, I don't know how but all buttons have default callbacks and they create and destroy the windows.
But the "Close" button of GtkAboutDialog widget does not work. I can not even see it's widget. So, can I access it?
[CLARIFICATION] What you're looking at is gtk.AboutDialog — popup window displaying information about an application (new in PyGTK 2.6). This window contains the 'close' button widget which is contained in a GtkHButtonBox widget. The GtkHButtonBox widget is the highest level widget I am able to access for some. Any ideas on how to get to the "close" button and connect a handler for a callback signal?
You don't conenct signals in the same way for a dialog as you do for a window. I made the same mistake when learning PyGTK.
The most basic form of a dialog is you display and run the dialog with:
aboutdialog.run()
Often you will then immediately call:
aboutdialog.destroy()
The .run() line is a loop, which runs until something happens within the dialog.
There is a working example here.
The gtk.AboutDialog is just a gtk.Dialog, and you handle responses from it in the same way. Instead of connecting to the clicked signal of the buttons, the dialog code handles that for you and returns a reponse from your run() call. You can check the value of the response returned to figure out what button was clicked.
If you're trying to override some behaviour instead, you can connect to the response signal of gtk.Dialog.
This is an old question, but since it's one of the first hits from google, I thought I'd throw in the solution that I found. You need an event handler to show the about dialog and one to close it. The first will likely be connected to your help->about menuitem's activate signal. The latter should be connected to the response signal of the about dialog. The two handlers will look something like this:
def on_menuitemHelpAbout_activate(self, *args):
self.builder.get_object('aboutdialog').show()
def on_aboutdialog_response(self, *args):
self.builder.get_object('aboutdialog').hide()
In the example above, I'm using the GtkBuilder to find my about dialog because I've constructed the interface with glade. Note that I'm using .show() over .run() because I don't see the sense in pausing program execution until the dialog is closed. Finally, the response handler can be made to take whatever action depending upon the response, but I'm ignoring it here.
In Tkinter I'm trying to make it so when a command is run a widget is automatically selected, so that a one may bind events to the newly selected widget.
Basically I want it so when I press a button a text widget appears. When it appears normally one would have to click the text widget to facilitate the running of events bound to the text widget. I want that behavior to automatically happen when the user clicks the button. So that one does not have to click the button and then the text widget, but simply the button.
I'd also like it so if one started typing after the button was pressed it would automatically start filling the text widget. Again to cut out having to click on the text widget.
What bit of code does the above?
The terminology which describes what you want is "focus" -- you want to set the keyboard focus to your text widget. To do that you need to use the focus_set() and/or focus_force() methods on the text widget.