What is the search scope for the binding of actions provided in "Action" attributes in UI views? I'm trying to bind to a class method of a global class instance. However, the method cannot be found. Where does the class instance have to reside? Is there a best practice for this in case the source code is spread over several modules?
Debugging Python code is easier than debugging English prose.
You can either use a global function (not a method) or a method of the object that is loading the view, i.e. the object that self refers to in the context of the load_view call. In the latter case, you'd use something like self.some_method in the UI editor.
Hmmm, does not seem to work. I still get the error "Warning: Couldn't bind action 'self.handle_button' of 'button_view_punctuation'sample". I'm using a class method to call ui.load_view and the same class has a method with signature "handle_button(self, sender)".
It won't work in a class method. self has to be an instance of the class in the scope where you're calling load_view.
I meant to say: I'm using the same class and the same instance of that class.
See what I mean about debugging English prose? It is MUCH harder. How about a minimum sample code that we can all stare at?
THIS and this thread may be of interest.
There are sort of two ways to use custom classes and associated pyui's.
The first is where you create a custom class, as a view controller, which uses load_view to encapsulate a pyui as a subview, or as an instance member (self.view= ui.load_view()). You would call load_view from within __init__(self) for example, or a custom method. In that case, self is in the local scope when you call load_view, and therefore self.my_action already exists. Note in that case, you would NOT use the custom class attribute of the pyui -- that was confusing to me for a while.
The other method is when you create a custom class, and an associated pyui. This time you set the pyui Custom Class attribute to your custom class. When you run load_view, it returns an instance of your Custom Class. However, in that case the bindings don't work like you want, because your object does not exist yet when the pyui is parsed (it gets instantiated during the load process). In this approach, you would set your bindings manually within did_load. The advantage of this type of approach is that you can then insert a Custom Class UI element through the UI editor into another pyui, the disadvantage is that the bindings to actions within the class have to be done manually.
This shows a tricky method using the inspect module to overcome this obstacle, and gain access to the object while it is being created. I believe this only works in the beta (or upcoming 1.6).
So, I found the problem. It was not a coding issue, really, but I did not see the forest for the trees. I mixed up two views and got confused. Thanks for your advice and I apologize for wasting your time.