Have you tried messing with the SimulateClick or SendWindowsMessage checkboxes? or even hardcoding a delay before to atleast identify a timing issue?
I will try them all again, just to be sure…Give me 5 minutes…
Actually I think you said you tried that. From my understanding, you want those unchecked if you get the generic error. But if they are both unchecked already, then it could be something else.
Simulate click just made it not click on anything. But it didn’t throw any errors… It just kind of skipped past it.
When I debug on slowmo It actually does click it. But I am not really supposed to use a delay. Because of the machine we are running it on. the run time varies. So we are not supposed to use delays, as they do not totally fix the issue.
When I do windows message click, I get this error.
launchRX has thrown an exception
Message: Action not supported by this type of element. Please use another type of click.
Exception Type: ElementOperationException
UiPath.Core.ElementOperationException: Action not supported by this type of element. Please use another type of click. —> System.Runtime.InteropServices.COMException: Action not supported by this type of element. Please use another type of click.
I think this has Something to do with my packages, but I don’t know what’s going on with that. All I know is that my log message activity disappeared…
Right. It was just as a way to identify the issue, so you can take a course of action to resolve it in a more dynamic way.
If I come across a possible solution, I’ll let you know. But as of now, I’m not quite sure.
You could try presenting it to technical support Here, and present a workflow that reproduces the issue, which isn’t always doable with website-specific issues and credentials.
I’m trying to click on a java application window… ? Would that make any difference?
Also. I tried the delay and it didn’t seem to help at 5 seconds. I will try a 10 second delay. It clicks on it when I’m in slow debug, but not normal debug or run mode.
You could also try changing the WaitForReady property, cause if the button isn’t yet ready for you to click it, it can cause errors sometimes.
Since it’s a java app, you could do some searches for how to click java buttons, but I can’t say I have run into very many issues with it myself, so I am unsure.
Hi, have u found the solution for this issue?
My case is similar like yours…if using simulate click, it will not click anything on java app
I have had similar experiences with simulate click in Java application (source unknown as to why it behaves like that needs more research), although you can use either the default or ‘SendWindowsMessage’ to work with Java apps and if you will have to scroll in those apps (like oracle applications) then better use set focus, activate element and then use the default click.
Hope this helps
Hello, we are also using UiPath for processing Java applications. I had a similar problem, with click generic error. The robot should do a few clicks and after that click a dropdown button and after that to click one of the submenu items. That last click used to bring that “Click gerneric error”.
I tried a lot of things. First I looked at the selector and removed here all special characters as German umlauts by shortening the selector. Also “Version Numbers” in the head of Java Apps can be a problem.
Every click worked fine but the last. Now I tried to use “SendWindowsMessage”. Using that leads to an error message like “this cannot be used with this application”… After removing the hook from that checkbox and trying again, I found that it now works.
I don’t know what the reason was and why it now runs. May be you can give a try and I hope my way can also lead you to success.
Yes, I faced same issue often in JxApplication. Click Generic Error occurs when Application / Element was not in a state to receive the click. To figure out we used the delay to isolate the issue within the analysis, same to the input from @ClaytonM
For solving / stabilization we looked at
- strict use of Attach window
- items in the application for getting synchronized with the app (WaitForReady was not reliable)
** sometimes combined with retry scope
- sometimes implemented loops in combination try catch
in JxApplications in deep/on Elements you have to pickup manually with UiExplorer (as you cannot grab with indicate …) the property relativeVisibility helped as well in some cases
I wouldnt use the Attach window all the time for everything strictly because it will be in scope of hitting the element and waiting for it to exist/appear/active which will slow the application down (especially legacy ones) better to have a standalone click/type activities just where it is failing.
Once it loads the frame I think an attach is a good way to preserve the scope.
It’s been awhile since I worked on this workflow, but if I remember right, it did have something to do with the selector and the window it was attached to… It was a conflict of the attach window selector and the window property in my click activity selector, so it didn’t know what to click on or something. I can’t recall how I resolved, but it was something similar to that. A Conflict between the attach browser selector, and the click activity selector, but I think I also had it inside of an element scope activity if I remember right. Things to look for.
@Raghavendraprasad I agree to you and I was not enough clear in my words. We set up some rules when to use Attach Window and when not. This we applyed in a strict way. Performance factors need to get in account for sure and you are right on this.
We had so something like a kit of tools for what to use or on how to deal with an JxApplication, that is reacting in deep range of performance (slow - time out, fast Click generic error). Therefore we were deciding what is the most working tool to get the bot robust working fo ar aprticular scenario. Never use it as rule that can be applied always. The specific application / scenarion is to taken into account.
@Heathersmithx as mentioned before find out whar can help you to grap a synchronization point (e.g. Element is loaded, Application is reactive, last row of table is loaded …) and then check if a click can be send more reliable to the element. Let us know in case you need more ideas and feel free to share more app specific constraints from your automatization task.
Perfect that is right @ppr I agree. A good mix of different approach that ‘suits’ the application is the right way. Best practices (some anyway) aren’t set in stone, rather change with environments and applications that we interact with. Oracle Java application is one such app. that has very unreliable selectors and dealing with it is what I call ‘major workaround time’
This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.