I am currently using some wxPython's AuiNotebook in one of my projects and I have a problem that can't manage to solve. I think there should be a simple solution but can't manage to find it.
I have created a new class derived from wx.lib.agw.aui.AuiNotebook and I am trying to get the index of a tab at the moment it's clicked. I wrote something like that:
class NewNotebook(wx.lib.agw.aui.AuiNotebook):
# __init__ function an stuff...
def OnTabClicked(self, evt):
index = self.GetSelection()
print index
wx.lib.agw.aui.AuiNotebook.OnTabClicked(self, evt)
The aim was to capture the index of the tab clicked on and in some cases, have a special behavior, or just perform a regular click otherwise. However, I think that AuiNotebook.OnTabClicked actually changes the selection among different things. It would explain why index contains the value of the tab that was selected before the click.
I did not a find a way to get the selection of the new tab though. I looked for some information in the captured event but still could not find the one I wanted.
So, does someone know how I can get the selected tab before I call AuiNotebook.OnTabClicked?
There doesn't seem to be a builtin way to do this. The closest I found was something I helped with on the wxPython mailing list, but that had to do with double-clicking.
Here's one workaround that came to me though. When you first show the frame, set some kind of class property to the currently shown tab (i.e. self.currentTab = 0). Then catch the EVT_AUINOTEBOOK_PAGE_CHANGING or EVT_AUINOTEBOOK_PAGE_CHANGED event and update the property. For me, when I catch EVT_AUINOTEBOOK_PAGE_CHANGING, I always get the index of the tab I'm clicking on, at least on Windows.
Related
This is a minor issue but I've been struggling with it most of the afternoon and getting nowhere, so here goes. I'm about to write a Python script that will require the use of the ScrolledListBox(). Never having used it before, I started with an experimental script where I could play with it and get familiar with it. I now have the script to where I can double click on an item and, in the handler, correctly print the selected item to stdout. However, I notice that when the item is selected, either with a single or double click, a rectangular border appears around the item in the list and remains there until another item is selected. I've been trying to see if there's a way to get rid of this border but so far have been unable to do so. Here's what I've tried:
1) Thanks to another post in this forum I found that the keys() method would give me a list of the available options for the widget. So, given a ScrolledListBox named slb1 I could do something like print(slb1.keys()) and I got the full list of everything I could configure on the widget. One of them was 'selectborderwidth' so I did: slb1.configure(selectborderwidth=0) thinking that this would remove the border. It didn't.
2) Next I dug through my copy of "Python and Tkinter" and discovered the selection_clear(first, last=None) method. The description states, "If any of the elements between first and last (inclusive) are selected, they are deselected." So I tried: slb1.selection_clear(0, None) in the handler but once again the rectangular border around the item remained.
I'm just getting started in Python and Tkinter so hopefully I'm missing something somebody with more experience knows about. Any ideas on how to get rid of the border?
Thanks,
Dave
The documentation by New Mexico Tech, which can be a good reference when working with Tkinter, lists the attributes for the Listbox widget, among which activestyle. This parameter refers to the box around the currently active (not necessarily selected) item, and can take the values underline, dotbox, and none.
If you set activestyle to none, the dotted border will go away.
I have come across a problem while using wxPython lately: I want to grey out a whole wx.Menu and I can't find a way to do it. I could disable all the wx.MenuItem instances related to the wx.Menu, but I find it less efficient ergonomically speaking than greying out the menu itself.
The wx.Menu class has a method named Enable() which accepts the 'enable' argument, but its solely use is to enable/disable a related wx.MenuItem and not the wx.Menu itself. Actually, I'm not even sure that what I want can be done.
However, I would be glad to listen to your solutions if you have some.
Enable is just for the menu items. EnableTop should counter-intuitively disable the entire menu. See my old tutorial on menus about half-way down for more info. Here's how I did it:
self.menuBar.EnableTop(0, False)
Note that it's zero-based, so zero is the first menu, one is the second, etc.
My GUI consists of a wx.ListCtrl on the left, with a list of objects to edit, and a set of wx.TextCtrls on the right, for editing the selected object.
My strategy for implementing this was:
On a textbox's wx.EVT_KILL_FOCUS , update the relevant attribute of the currently selected object
On the list's wx.EVT_LIST_ITEM_DESELECTED, either hide the textboxes or blank them out and disable them (needed for when the user clicks the blank space in the list control)
On the list's wx.EVT_LIST_ITEM_SELECTED, populate the text controls with the values of the selected object's attributes
With this setup, there are 3 use cases, and 2 of them work:
When the user is clicking/tabbing between textboxes, the correct wx.EVT_KILL_FOCUSs occur, and the attributes get updated.
When the user clicks from a textbox into the blank space in the list, that's OK as well: first wx.EVT_KILL_FOCUS causes the attribute to update, and then wx.EVT_LIST_ITEM_DESELECTED hides the textboxes.
The problem is when the user clicks directly from a textbox to another object in the list control. The order of events in this case is wx.EVT_LIST_ITEM_DESELECTED, wx.EVT_LIST_ITEM_SELECTED, and then finally wx.EVT_KILL_FOCUS. You can probably see the problem: by the time the method that updates attributes is called, a new object has already been selected and the textboxes have been populated with new values.
So I know exactly what the problem is, but I can't come up with a nice, clean way to fix it. Ideally I'd like to be able to change the order of the wx events (putting wx.EVT_KILL_FOCUS at the front), but I doubt that's possible. Is there some other obvious solution I'm missing?
wx.EVT_LIST_ITEM_DESELECTED will only fire when the user changes the selected object in the list box. This serves the same purpose as losing focus on the text box. Call the update routines from that event as well. To skip the subsequent wx.EVT_KILL_FOCUS from the text box set a "isDirty" attribute in the parent object after you update the attributes. You can check the isDirty value anytime to confirm there are changes to commit. This attribute would have to be reset when you populate the text boxes for the new selection and then set during other textbox events.
It looks to me like you are trying to re-implement from scratch the functionality of wxListbook. It seems like a lot of work, perhaps you can use wxListbook
to do what you need.
http://docs.wxwidgets.org/2.9.4/classwx_listbook.html
How to suppress end user ability to edit/add/delete text in a Text widget? (Python v3.2.. and tkinter)
The point is to suppress only the ability to change/add/delete text but not to castrate other features. Perhaps a NoEdit Text widged would be a better name.
I've tried .text['state'] = 'disabled' and it works almost OK in Windows (it still allows user to select/copy text highlights the selection, page up/down and up/down buttons work. The only thing broken seems to be the cursor made invisible.)
But on MacIntosh everything is broken. No highlights, no select/copy,... UGH
Since Tkinter has practically no documentation in Python, I've searched and found some TCL advise, to derive a new class and suppress the insert and delete functions.
So, I've tried as so:
class roText(tk.Text):
def insert(self,*args,**kwargs):
print(" Hey - Im inside roText.insert")
pass
def delete(self,*args,**twargs):
pass
def pInsert(self,*args,**twargs):
super().insert(*args,**twargs)
Unfortunately it didn't work right. Apparently tkinter does not use those insert and delete functions when end user enters/deletes code. Perhaps those TCL insert/delete are something else, and I lost something in translation from TCL and Swahili. What functions does tkinter.Text use for end user editing text? Hopefully they are not internal...
So, is there a way to modify the Text widget to suppress only end user editing?
Is there a way to do it without diving inside and overriding internal Tkinter code, so the stuff doesn't get broken by next releases of Tkinter?
Looking at the Idle shell window, I see that they've managed to suppress edits (except for the last line). So there is a way. But what is it and how costly?
Sorry for bumping an old question, but I was searching for an answer to this question also and finally found a solution. The solution I found involves overriding the key bindings when the text widget has focus and is pretty simple. Found here.
To override the bindings of a widget there is a bind function where you pass a string of what is to be overridden and the new function you want it to call.
self.txtBox.bind("<Key>", self.empty)
Somewhere else in the class you'll need to define the function to handle the event.
def empty(self, event):
return "break"
By returning the string "break" the event handler knows to stop after your function, instead of continuing with the default action.
I hope this answers your question. Cheers.
The reason the disabled state doesn't seem to work on the Mac is because it turns off the binding that gives focus to the widget. Without focus, the highlighting on a Mac doesn't show up. If you set the state to disabled but then assign a binding to <ButtonPress-1> to explicitly set focus to the disabled text widget, you can then select and copy text and the highlighting will show.
As for the cursor disappearing... arguably, that's what's supposed to happen. The cursor tells the user "this is where text will get inserted". Since no text will get inserted, having that visual clue would be confusing to the user. What you could do instead, if it was really important, is to insert a small image wherever they click to simulate the cursor.
To answer your question about whether the widget actually uses the insert and delete methods: the methods on the actual underlying widget are what the default bindings use, so overriding them in a subclass has no effect. You would need to redo all the default bindings for that to work. It's doable, but a lot of work.
Unfortunately, this is one area where programming in Tcl really shines, because you can simply disable the insert and delete commands of the widget. Of course, you can do that directly in Tkinter also since ultimately it runs tcl code to do everything, but that would involve writing some tcl code which is not a very good solution from the perspective of a Python coder.
I think the best solution is to use the disabled state, then add in just enough bindings to do what you want.
Here's a simple example that works by explicitly setting focus on a mouse button click. With this code I'm able to click and swipe to select a region, or double- or triple-click to select words and lines:
import Tkinter as tk
class SampleApp(tk.Tk):
def __init__(self, *args, **kwargs):
tk.Tk.__init__(self, *args, **kwargs)
self.text = tk.Text(width=40, height=20)
self.text.bind("<1>", self.set_focus)
self.text.insert("end", "\n".join(dir(tk.Tk)))
self.text.configure(state="disabled")
self.text.pack(fill="both", expand=True)
def set_focus(self, event):
'''Explicitly set focus, so user can select and copy text'''
self.text.focus_set()
if __name__ == "__main__":
app = SampleApp()
app.mainloop()
#BryanOakley It took me a while to test your suggestion since I have no Mac.
Unfortunately Mac implementation of Python is buggy.
I've added focus, ie my disable function which I call after creating a window and inserting text, now calls first:
self.txt['state'] = 'disabled'
and then
self.txt.focus_set()
Which is what I think you've suggested.
It "kind of" worked. Ie: when selecting text (click and drag or double-click) highlighting works most of the time. Python must have some bad memory references or such bugs: Sometimes highlighting doesn't work at first, then it starts working (in the same window) after more clicking. Sometimes when program is invoked it works right of the bat. Sometimes selecting with Shift-rightArrow key will work but selecting with the mouse will not. Then starts working again. Or it will work fine in one window but not in another one (both of the same class), then starts working in all windows...etc...
The good thing is that adding focus did not affect badly Windows (ie all works fine as without focus.
I guess at this point I will just hope that future/next release of Python for Mac will fix those bugs..
BTW, it seems that Mac is a bit of an orphan for Python. Implementation is much uglier then for Windows. I mean the fonts look worse, the buttons, etc.. Or it could be due to different screen resolutions and Python ports that poorly account for those. Not sure
Anyway. Thank you for your help and suggestion to use focus for Mac.
I am using a wxPython wx.html.HtmlWindow to display part of my interface. The user can scroll down a list of links in a window smaller than the list. When they click on a link, I need to repaint the web page, but I want to return the page position back to where they clicked it.
I've tried MouseEvent.GetLogicalPosition() on the event, but it wants a DC and the best I've been able to do is get the same information as GetPosition(), so I must not be feeding it the right one.
I also tried HtmlWindow.CalcScrolledPosition(), but apparently that isn't available in HtmlWindow because I get a NotImplementedError...
What I would like is a scroll position that can be derived from the MouseEvent, or the OnLinkClicked information.
I know about HtmlWindow.ScrollToAnchor(), but it's flaky and unaesthetic -- I would prefer to bypass it if possible so that I can scroll back exactly to where the user clicked.
Thanks!
how about having a look at the source of wxHtmlWindow for inspiration? for example at wxHtmlWindow::LoadPage(): it
// store[s the current] scroll position into history item:
int x, y;
GetViewStart(&x, &y);
(*m_History)[m_HistoryPos].SetPos(y);
this saved scroll position is used in wxHtmlWindow::HistoryBack():
Scroll(0, (*m_History)[m_HistoryPos].GetPos());
Refresh();
to go back to the saved position.
i would assume that this built-in "go-to-the-last-position-in-window" handling isn't the most "flaky and unaesthetic". could something similar work for you, too?
Maybe a bit late, but with some tips from ax, and some hints from here, I think that calling:
scrollpos = wx.html.HtmlWindow.GetViewStart()[1]
and storing that, and then later doing a call to:
wx.html.HtmlWindow.Scroll(0, scrollpos)
works for me. Of course, you do need to change wx.html.HtmlWindow to an actual reference to an instance.
Here is what I am doing to scroll page to previous position.
I do this to avoid blinking.
pos = self.GetViewStart()[1]
self.Freeze()
self.SetPage(src)
if save_scroll_pos:
self.Scroll(0, pos)
self.Thaw()
Usually, click events are trigged by MouseUp events. If you track the mouse position by capturing any MouseDown events, you will know where the last click (MouseUp) happened, and that should allow you to reconstruct things.
For this particular problem, you might have to do a bit more work in MouseDown like checking if they are within the wxHtmlWindow control and if so, then saving something like a line number.