B. How can we maintain a single handle rather than redefining it each time?
Ideally, we’d like to configure something like NWebDriverMode.Headless once and reuse it without updating every definition individually. It’s also not very clear if I’m targetting the existing browser instance / tab or a new browser instance / tab.
Even if I use the input and output elements the settings like WebDriver mode need to be set again. They don’t automatically get inherited from the Output element. For example in my first work flow I set an output argument that will be the Output element of my NApplicationCard activity. Inside of that NApplicationCard I will set the WebDriver mode to NWebDriverMode.Headless. In the next work flow I will take the out argument of the first workflow and assign it to this new NapplicationCard activity. This new activity will have it’s own options and don’t seem to inherit the options of the output element.
Another example is if I set the Close option to NAppCloseMode.Always it will close right away as soon as the workflow is done. I expect it to be done when there’s no more NApplicationCard activities and not as soon as the first one is finished.
the first request I agree options are different it is to make sure each has its own…but setting close to always is in that scope so obviously it would close once the scope ends
may be for the first one you can raise a feature request as such…already such request has been raised for click activities and object repo …can include this as well as feature if it is considered
Is there any way I can track requested features? I just find making reusable workflows not very reusable. I expected I could pass around the UiPath.UiAutomationNext.Activities.NApplicationCard as an output variable of type NApplicationCard like a handle to that browser and its pages.
Do you know if there’s a demo of how you guys expect us to create re-usable workflows in browser automations? Like I want a workflow for loggin in and I would like to set all the options there and pass around that handle to use in my other workflows and test cases. I hope I’m being clear with my request. Feel free to ask for further clarification and thank you for the help!
when you create a topic you can select feature request and it would be created as such and based on votes received product team would pick it up and update on thread
as of now with modern migration it is still not available to pass all options as well…but in a way that would restrict few things also…for example…in login you would use open always generally…but its not ideal for other pages…ifnotopen is also not ideal…so thats one reason they are kept separate…with object repository few options are being merged like the window selectors and input method etc but not all again…
now coming to reusables…think of it like this…when you build a reusable you build with a mindset that the component would be used again so building it would still help in other automations but yes we hear the concern of options needs to be choosen again but because of different requirements having few options left for choice is also a good way…the handle helps you with not passing url always, not selecting the window always as of now
Agree with you on limitations …the more we all give feedback the more it would be improved