I am testing an iOS app devloped using Xamarin (without Xamarin forms). iOS on screen keyboard special keys like "Done" "Enter"... are visibleOnScreen but their "enabled" property is showing "false". This causes TestComplete to issue warning messages during playback. "The control is disabled, but the action will be performed"
Sorry for the delay, after contacting support in January, here's the answer I got from SmartBear support:
...I got a reply from our R&D team that the Enabled property corresponds to the native hidden method called isEnabled. You can find it and check this. Also, that Return button has the userInteractionEnabled property with the False value. This means that the Touch event will skip this button and will be caught by the parent control.
In order to go further in the investigation, I would have to "share" my mobile app which is problematic due to client/server security certificates and ports.
My final approach with those 2 iOS keys (Return-key and Dismiss-key) was to get the top and left values, add 20 (pixels) to be within the button region and touch it's parent object at those coordinates. This got rid of the warning message generated by TC.
The following code currently ends up in the "else" part.
myTouchParent(Aliases.iOS.myApp.window_X.iOS_WideKbd.KBKeyView('Dismiss-Key'));
function myTouchParent(myObj, StartWithThisObj : variant = nil);
begin
if StartWithThisObj = nil then
myObj.Parent.Touch(myObj.Left + 20, myObj.Top + 20)
else
StartWithThisObj.Touch(myObj.Left + 20, myObj.Top + 20)
end;Hi,
Hm-m... Interesting...
Thank you a lot for the update. Much appreciated!
> to "share" my mobile app which is problematic
Well, most probably this is already irrelevant for you as you have working workaround, but just to let you know that usually SmartBear is ready to sign the NDA agreement if needed.
If Enabled won't work for you because it's false, try another property. Visible looks good in this case.
Properties aren't always set the way one hopes they would be. I've tested apps where even Visible wasn't set even though clearly the thing could be seen.
My controls are not mapped that far... I am not "using" the property, TestComplete is issuing the warning by itself...
Hi,
I'm not sure I got the problem, but maybe this thread will help: https://community.smartbear.com/t5/TestComplete-Mobile-Application/iPad-iPhone-on-screen-keyboard/m-p/110964#M847
Hi,
This problem still exists. And I'm not sure is this a TestComplete issue or iOS keyboard peculiarity.
You can use Events as a possible workaround to block this kind of warning.
Also it is not necessary to TestComplete to touch 'Next' key to switch to the next text field. Using a Keys() method (to the appropriate text field) will do it automatically.
It is pretty much the same issue. But I thought important to test the changing behavior of the "return-key" via touching depending on the screens in my app.
Some places, the Return-key will get me to the next field, some other it should engage an on-screen button by default (like when positioned on the last field of a form, it will be like touching the "accept" button at the bottom of the form).
Hi,
> But I thought important to test the changing behavior of the "return-key"
"You can use Events as a possible workaround to block this kind of warning." as it was mentioned by baxatob or just by disabling the log temporarily.
E.g.:
bLogState = Log.Enabled;
Log.Enabled = false;
<disabledButton>.Touch();
Log.Enabled = bLogState;
> changing behavior of the "return-key"
It might be fine for your given application, but in general I am not sure I like this approach. (And yes, I am also not fond of 'overly-smart' modern applications that set, say, interface language based on my regional settings or do any other things that I did not explicitly request to do.)
It may be not obvious for me (from what I see on the screen) whether or not the current input field is the last in the input sequence or not. Thus I might be wondered why I was navigated away. Also I may want to double-check entered values before submitting them. Or do something else before finally accepting entered data. So *my personal preference* is to be in control of what application is doing (by explicitly triggering the actions in particular) and not to wonder end-user with unexpected navigation...
