I need some help with selecting a value from a dropdown list. The dropdown is a WebElement, and the flow works well up to the point where the value should be selected.
My code is as follows:
.Browser("Browser").Page("PageName").WebElement("DropDownList").Click
.WebList("ListOfItems").Select(itemToSelect)
Note: itemToSelect is the name of the item that needs to be selected from the list, which is being passed as a parameter within the function.
When running the code, I get an unspecified error.
The weird thing is that before the error is thrown, I can see the value being selected from the list in the browser, as upon selecting it, some fields in the form change. Also, if I press "Skip" in the error message panel, the process goes on as if nothing happened.
I am certain the error comes from .WebList("ListOfItems").Select(itemToSelect) but I do not know what to do in order to fix it.
Try this code.It works for me.
StrAllItems = Split(Browser("name:=.*").Page("title:=.*").WebList("name:=.*").GetRoProperty("all items"),";")
For intCounter = Lbound(strAllItems) to Ubound(strAllItems)-1
If Browser("name:=.*").Page("title:=.*").WebList("name:=.*").GetItem(intCounter)= "SomeValue" Then
Browser("name:=.*").Page("title:=.*").WebList("name:=.*").Select (intCounter)
Exit For
End If
Next
Please let me know if this help.
If the test behaves correctly and you're just getting an superfluous error you can just ignore this specific error. It's best of course to understand where the error comes from, you should probably contact MicroFocus support but in the meantime you can turn off error handling for the offending line.
Browser("Browser").Page("PageName").WebElement("DropDownList").Click
On Error Resume Next ' turn off error handling
Browser("Browser").Page("PageName").WebList("ListOfItems").Select(itemToSelect)
On Error Goto 0 ' turn error handling back on
BTW, I changed your code a bit to make it valid, I assume this is what your code really looks like.
Possible timing issue: You might need to wait for the hole list to appear before you select the item.
Often, the item exists, but the app is still updating its GUI.
Whenever you access the GUI with UFT while the app is not idle (f.e. not ready for user input because it is still updating its HTML), you might get all kinds of strange results, including unexpected errors, hangs, instability.
So how do you wait for the list to be complete? I don't know, because it heavily depends on the way your app is refreshing its GUI. You need to explore that, and integrate some synchronization code that waits for the right condition to be met.
Unfortunately, this is a hell of a job sometimes.
A suitable workaround (and a good way to verify if my hyphothesis is correct) might be to insert a large delay between the first click and the list item selection click. (A quick way to do a similar thing is to single-step through the code.) If that does not generate any error or issues, you can be pretty sure it is what I describe, and you can experiment with lower delay durations to find a good value.
Thanks to everyone for your replies.
The issue turned out to be due to the object not being added well to the repository.
It was eventually fixed by adding it properly.
Related
In my application I want to run some code when opening a screen. AppInventor has a function ".initialize" for this, but it does not seem to work.
When I open the screen the code does not run, while the code is fine because it does work when I trigger it with something else than the ".initialize" function.
I have these code blocks: https://imgur.com/a/y0ZMqa3 as you can see the code inside is exactly the same but it doesn't run when the screen initializes while it does work when I check the checkbox.
I don't think its possible to get tiny DB values when the screen initializes. Perhaps try adding another component like a clock with a timer and then using the same blocks you have on .initialize after a certain time interval of some 500 milliseconds. Since as you say it doesnt work on the .initialize block but does work when the checkbox is changed.
What's the code?
You have to give us an idea of what it is your working with for us to be able to try and help you. Trust me man the chances of your question getting answered here are slim even if you pit it perfectly.
This is way too vague for somebody to even attempt to answer.
Next time make sure you ask with specifics.
I'm debugging a project using VS2012 ultimate, but encountered this problem very often now. usually it happens when i want to expand a collection type value(e.g, List<>, Dictionary<> and so on) to watch its value. It just failed to show the value and then hangs forever, the error message is like
"Function evaluation disabled because a previous function evaluation timed out. You must continue execution to reenable function evaluation." the only thing i could do is to restart the debugger.
can anybody give some help?
When you expand a value in the debugger to see its members, the debugger does somethings called a "func-eval" behind the scenes, which basically means it 'wakes up' one of the the threads in the debuggee and runs some code in it in order to display its result. This is usually either executing a property's getter or an object's .ToString() method.
Sometimes, the evaluation can take too long (often because a property getter gets stuck waiting on some lock that is held by another thread, in which case, you could keep waiting forever and it'll never return, because all threads except the thread that's doing the func-eval are paused by the debugger). In these cases, after a short while the debugger will decide to 'give up' and display the message you've encountered. You don't have to restart your app to try evaluating properties again - you can simply do another Step Over (F10).
As a more permanent solution, you can do one of two things:
Go into Tools->Options->Debugging->General and disable "Enable property evaluation and other implicit function calls". This will make the debugger's display a lot less useful as you will only be able to view fields, but it guarantees you will never get stuck and receive the timeout message.
Try to figure out which property in which object is the one that keeps timing-out. This can be a bit tricky, by try paying attention to which objects you are viewing when this happens - the timeout will usually occur just after you scroll down to the offending property. Once you know which property is at fault, either change it into a method, or put [DebuggerBrowsable(DebuggerBrowsableState.Never)] above it to prevent the debugger from displaying it.
Currently, I see a recurring error:
2013-04-18 02:35:51.583 aaah[1713:1110f] *** Terminating app due to uncaught exception 'NSGenericException', reason: '*** Collection <__NSArrayM: 0x1fc00dc0> was mutated while being enumerated.'
In the failing background queue (I see my queues state upon the moment of a crash by pressing Command + 5) I see:
0 _pthread_kill
1 pthread_kill
And I see assembly output which I completely don't understand.
I know how to resolve this kind of array enumeration errors - I just can't understand where/how I should seek for the piece of code causing my app to crash.
I have much multi-threaded code using AFNetworking and Core Data, so I can't just remember where the crucial section might be.
Also, this error occurs not always, but from time to time, so it is difficult just to use "isolation approach", isolating smaller and smaller pieces of code, to finally identify the buggy piece of code.
So the question is:
How can I extract some more useful information from this output, or Xcode can provide me with some more verbosity level, so I could know how to resolve this annoying piece of code.
Have you tried setting an exception breakpoint? Sometimes the debugger struggles with exception handling inside blocks but it might help.
In the breakpoints navigator (one of the tabs on the left side of the window) click the plus button at the bottom of the window and select add an exception breakpoint. Then hit done.
Now when you crash, the debugger should hopefully put you right before the instant the exception was raised.
See http://developer.apple.com/library/mac/#recipes/xcode_help-breakpoint_navigator/articles/adding_an_exception_breakpoint.html for more info.
Edit:
Based on the feedback provided in the comments, here's some more analysis:
The exception your application is raising means that you attempted to change a collection type (in this case, an NSMutableOrderedSet) inside of an enumeration block (in your case, most likely a for-loop). It looks like you're trying to remove objects in a set that you are looping over: [NSMutableOrderedSet removeObjectsInRange:inOrderedSet:]
To resolve this you should store the ranges you wish to remove and then do the actual removing once you're no longer iterating over the set. It's still going to be difficult since, as I understand it, you're not breaking inside of Objective-C code. You should look at the running threads in the panel on the left and look at what method they're currently in. That might give you a hint as to where your code is wrong.
I have been getting this error message when I step into some methods
Do you want to continue being notified when an Automatic step over occurs?
I usually answer Yes and I get taken to the line I want to step to.
However, I just pressed No (cause I was tired of the dialog box always popping up). When I did that it skipped a lot of code I wanted to step through. Now when I step into my method it is skipping my method (and jumping to the finally block because the method I am trying to step into is throwing an exception).
How can I change my answer back to Yes?
I would prefer it never ask me (default showing the code), but if faced with the choice of it skipping the code I need to see, or having a NagBox, I will take the NagBox.
I'm blissfully unaware of this. Try Tools + Options, Debugger, "Step over properties and operators" checkbox. If that's not it, document the key you press.
If I understand this message correctly, code is always skipped - regardless of your choice.
It's like "Hey, just a heads up, I am going to skip some code. Do you want me to notify you next time?" Yes/No
Uncheck Tools + Options, Debugger, "Step over properties and operators" and that will fix this issue.
For anyone who is still interested in this, I was able to solve my stepping into a function by doing the following
Tools -> Options -> Debugging -> General
and then unselect
Require source files to exactly match the original version
I realise this is an older programming environment, but I have to clean up some VB6 code and I am finding that most of it uses:
On Error Resume Next
What is the general consensus about the use of On Error Resume Next?
Surely, if there is an error, you would want the app to stop what it was doing, rollback any data changes, and inform the user of the error, rather than just resuming.
When is it a good idea to use On Error Resume Next?
It is perfectly reasonable to use On Error Resume Next to implement local structured error handling. This involves testing for an exception and acting on it of course, as well as disarming the mechanism afterward. Example:
On Error Resume Next
GetAttr strFilePath
If Err Then
On Error GoTo 0
'Deal with "no file" scenario.
Else
On Error GoTo 0
'Open and process the file.
End If
That's just a simple example where only one sort of exception is expected. In some cases it is necessary to test Err.Number for specific values and take different actions based on them.
The unstructured approach based on GoTo label can often work as well, but it is hardly superior in most instances. In VBScript the pattern shown above is the only form of exception handling you even have since there are no GoTos or labels.
What's objectionable is arming explicit exception testing at the head of every procedure and ignoring it... a sort of Trust the Force, Luke approach to trying to mask coding errors.
I have found it useful in functions where an error would not warrant the user being interrupted with the issue. A good example is in the resize event. If you make a mistake or there's a problem in the resize event then you probably don't want the user to see this, as it probably wouldn't affect functionality.
I would say in general, use it sparingly.
Almost never - unless used consciously for example on a line where a successful call will set a particular return value, and the subsequent code handles the return value to cater for the error case.