You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
On iOS, UITextField defines a keyboardType property. However, this property doesn't appear to get picked up by Rubicon.
Other properties (like borderStyle) work fine.
If you manually invoke send_message(obj, 'setKeyboardType:', ...), it works, too.
So - there's evidently something about the property discovery process.
A little digging revealed that the keyboardType() and setKeyboardType() accessor and mutator aren't found by cache_property_methods(). This may be due to the fact that they're defined on the UITextInputTraits protocol, rather than on a direct superclass of UITextField.
The text was updated successfully, but these errors were encountered:
Hm, it seems like calls to keyboardType are handled dynamically. The keyboardType property does exist on UITextField, but there is no keyboardType method. Instead, UITextField overrides forwardingTargetForSelector:. When called with SEL("keyboardType") as an argument, it returns a UITextInputTraits object, which does have a statically provided keyboardType method. (The UITextInputTraits here is a class, apparently undocumented, and not the protocol of the same name.)
When calling a method with Rubicon using Python method call syntax, the method is looked up on the class (in the attribute access) and then called later (when the ObjCBoundMethod object is called). This doesn't work for dynamic methods, since they don't exist on the class. On the other hand, send_message uses objc_msgSend and friends to send a method call to the object directly, which triggers the whole dynamic method call process.
Here are some results of playing around with this in Pythonista (iPhone SE, iOS 10.3.3). I used this library that I wrote a while ago since it has better reflection/introspection support than Rubicon does at the moment. (Eventually I want to port that over to Rubicon, or implement something similar, when I have the time...)
On iOS,
UITextField
defines akeyboardType
property. However, this property doesn't appear to get picked up by Rubicon.Other properties (like
borderStyle
) work fine.If you manually invoke
send_message(obj, 'setKeyboardType:', ...)
, it works, too.So - there's evidently something about the property discovery process.
A little digging revealed that the
keyboardType()
andsetKeyboardType()
accessor and mutator aren't found bycache_property_methods()
. This may be due to the fact that they're defined on theUITextInputTraits
protocol, rather than on a direct superclass ofUITextField
.The text was updated successfully, but these errors were encountered: