BUG: ON ELEMENT APPEAR ACTIVITY

Feedback Activities
, , ,
1

Activity is present in package and after drop and drag instantly its giving Error as “Object Not Set To An Instance Of Object”. Please look it and Enable it for latest version.

image
image967×376 14.3 KB

1 Like
3

It’s a known issue with the latest version of Studio and has already been reported. You should be working in modern anyway, and use Check App State.

1 Like
5

okay, Thanks for suggestion. Since I am preparing for UiARD certification, so just want to check “On Element Appear” in Classic Design

6

ATTENTION UiPath:
OnUiElementAppear is well and truly broken in this release.

Although this thread clearly cited a critical issue with an important function, the bug appears to have little traction. While I use the forums and keep up on upcoming community edition versions, I keep my production workstations on a paid “Enterprise” seat, and a specified working version.

The fact that this bug appears to not have attention is disturbing that the bug will make it all the way down the release schedule to the enterprise release - breaking many user’s production tested methods of handling pop-ups and waiting for presence of elements in an application.

While the forward thinking approach (“you should be using Modern design experience”) is great for users learning UiPath, the forum must realize that it also supports code that is in production already.

While this may seem like a rant, the problem for a production robot is that it is NOT apparent what the issue is: Upon upgrade, my robot simply exhibited the following NON-Helpful error - and even posted to this forum I had to de-construct my script block by block over 2 days to find the cause.

System.Exception: Object reference not set to an instance of an object
at System.Activities.Presentation.Validation.ValidationService.MarkParents(ValidationError validationError, IEnumerable1 errorParents, ModelItem source) at System.Activities.Presentation.Validation.ValidationService.MarkError(ValidationError validationError, List 1 errorSourcePath, ModelItem source)
at System.Activities.Presentation.Validation.ValidationService.MarkErrors(ICollection1 errors, ValidationReason reason, Activity rootActivity) at System.Activities.Presentation.Validation.ValidationService.OnValidationWorkCompleted(Tuple 3 input)
at System.Activities.Presentation.Validation.BackgroundValidationSynchronizer`1.<>c__DisplayClass26_0.b__0()
at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler), HResult -2147467261

Others: Please “up-vote” this bug thread - before it’s too late.

1 Like
7

Why did you upgrade it if it was working fine?

8

I upgraded in my dev environment to make sure it would still work in future release.
This is necessary to know if a future release is going to break my production code.

2 Likes
9

But again, why are you trying to upgrade it?

10

Because that’s the SDLC.

I upgrade in dev/test area only - to ensure future release will not break my code. Checking existing code against future releases is necessary to ensure no future production surprise as release schedule moves forward.

To be clear, this is not impacting my production work - that’s the point.

At SOME POINT even production running on enterprise/held release levels will be required to move forward - and I need to be sure that doesn’t stop the train.

Cheers.

1 Like
11

This is what I’m asking about. Why? It’s better not to touch what’s working. Don’t upgrade dependencies unless there is a reason to - exactly because upgrading them simply to upgrade them can cause other problems.

13

Now I think I understand the angle of your question, if you’re advising I not upgrade the dependencies - not necessarily commenting on the version.

I was originally upgrading the version only, and when it would not work and I posted about it with the very unhelpful error it threw, the forum and even UiPath staff recommended that I make sure to also upgrade the dependencies of the script. I admit I would not have changed them otherwise.

I do always need to make sure my code can continue run on newer running versions, as my workstations will eventually all end up on newer versions once stable - but leaving the dependencies on “lowest viable” has generally been fine for me – I’ll likely back these down to 23.4.4 – or just revert to the working level they were on before I tried moving them forward as an attempt to solve this specific issue.

My issue turned out to be that there is a fatal issue with “On Element Appear” in the newer version, which hopefully they will address soon, and likewise hopefully won’t require the newer dependencies either. I say “fatal issue” because for me, that function reliably solved a ton of issues and I use it heavily (hundreds of calls in various scripts).

14

That’s not how it works. Unless you manually go into a project and upgrade the dependencies then publish, they’ll stay on the version that’s specified in the project. Nothing will ever be upgraded unless you do this.

All this means is if you have two different versions specified in your project dependencies, it uses the highest version of the two. The naming of this setting is highly misleading.

For example…you have two dependencies:

  • UiPath.SomePackage.Activities
  • UiPath.OtherPackage.Activities

…and they each have the same sub-dependency inside them:

  • UiPath.SomePackage.Activities
    ** UiPath.SubPackage.Activities v1.0
  • UiPath.OtherPackage.Activities
    ** UiPath.SubPackage.Activities v2.0

If UiPath.SomePackage.Activities has the SubPackage set as “lowest applicable” then in your project it will use v2.0 instead of v1.0. If SomePackage has it set at “strict” then it requires v1.0 and you will get a dependency error in your project.

But again, that settings is relevant inside the code for SomePackage and OtherPackage not in your project. The only way it would affect your project is if you directly added UiPath.SubPackage.Activities so your dependencies look like this:

  • UiPath.SomePackage.Activities
    ** UiPath.SubPackage.Activities v1.0
  • UiPath.OtherPackage.Activities
    ** UiPath.SubPackage.Activities v2.0
  • UiPath.SubPackage.Activities

If you add SubPackage to your project with v1.0 and set it to strict, you’ll get a dependency error because your project demands v1.0 but UiPath.OtherPackage.Activities wants v2.0.

If you set SubPackage v1.0 in your project to lowest applicable, you’ll see “requested v1.0, resolved v2.0” when you mouse over it in your Project panel.

But you’d never want to directly install SubPackage in your project, because it’s already included in your other dependencies.

For example, I have a library I built named “Application Activities” - it includes UiPath.System.Activities. Therefore I don’t need UiPath.System.Activities directly added to my project. Just adding Appplication Activities already includes UiPath.System.Activities to my project.

15

Thanks for the insights.

16

Hi @Mike_Campbell ,

Thank you very much for raising this as an issue. Our developers are currently looking into resolving this issue as a high priority. I agree with you, this is a critical issue that we need to resolve as it has a large impact on workflows using UI Automation Classic.

Many thanks once again,
Raluca

18

For those who find their way here with similar experience - The response I received this morning from the UiPath enterprise support ticket I opened based on this thread:

"…the issue has been successfully reported and will be fixed in the future 2023.10.X Studio release. Just for adding to your report, it seems the error is also reported for On Element Vanish / On Image Appear / On Image Vanish activities.

19

Hi Michael,

I am adding some more details, for your attention until the issue is resolved.

The error does not occur when using Studio 2023.4, with any version of the UIAutomation package. It occurs only when using Studio community versions 2023.6 or 2023.8.

Until the release of Studio version 2023.10, when the issue will be resolved, one workaround is to remain with Studio on the enterprise version 2023.4. Existing workflows will work without the need for changes.

Also, that error only occurs at design time when using Studio 2023.6 or 2023.8. It does not appear at runtime if you run the processes built with Studio 2023.4 from Assistant 2023.6 or 2023.8.

We apologize for any inconvenience this may have caused and thanks again for bringing this issue to our attention.

Kind regards,
Luiza

1 Like
20

The user already gave you an answer. In fact, it’s shameful that we must explain such things at this point in life. Why are they releasing upgrades, then? If everything is working, why are they touching it if there’s not a reason to, simply because upgrading can cause other problems?

In my opinion, such posts are not only irritating, but they have nothing to do with the topic and shift the attention from the real matter and make us lose time and resources, thus should be avoided in the forum.

21

Hi,

Just wanted to post an update here that the issue should have been fixed on the 23.10 Community release:

22

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.