Object reference not set to an instance of the object

I have 2 screens in my project. 1 is login screen and another is work screen… both are differed only by titles. So i have created 2 app scopes and setted as an repository screens.. Now i have 2 screens…

Whenever i need this work screen i can simply drag and use right…Now i have dragged its throwing this error. I dont know why…someone pls help me…

@Salman_Faries Looks like the issue is not because you created 2 screens in Object Repository.F rom the screenshot, error is coming from the Navigate activity.

First I would check this value: in_Config(“Mclane_LoginURL”).ToStrin

Just put one Log Message before Navigate and print this value. If the config key is missing or value is Nothing, this error can come.

Also since both screens are same application and only title is different, you may not need 2 separate app scopes. You can keep the same application scope and create separate screens/objects under it, then handle the title in selector.

Try checking the config URL first. If URL is fine, then re-indicate the application/screen once and validate the selector.

Please let me know

Hi @Salman_Faries

Try to use checkapp state before to this and follow further based on the output.
or
Try to use wildcard in the URL… Because I think there will be some change in the title..

Hope it helps!!

Tnx, i found out that config variable i didnt passed… But will u pls able to elaborate me why object repos are used…If i want to move to prod then, how to move repos an outline

@Salman_Faries Yes, that explains the error :+1: Object Repository is mainly used to keep all UI elements/screens in one place instead of indicating the same element again and again in different workflows. So if selector changes later, you can update it in repository and activities using that element can reuse the updated definition. For moving to Prod, normally you dont need to move the Object Repository separately. If it is a local Object Repository, it is part of your UiPath project itself. Once you publish the project and deploy that package to Prod, repository screens/elements will go along with the project.

Got it. as per ur sugeestion i changed it into 1 screen and passing variable inside…but everytime when i run its getting resetted. What can i do?

Im setting like in_str_title between workfows…i need to set at repo level or how? pls explain

@Salman_Faries Yeah, this is because in_Str_title is an In argument. Any value you change inside that workflow will not be retained once the workflow ends.

Better keep one variable in Main, like str_Title, and pass it to the child workflows.

If you need to update the title inside a child workflow and use the updated value later, change the argument to In/Out and map it back to the same Main variable.

So flow will be like:

Main str_Title → child workflow updates it → same updated value passed to next workflow.

That should solve the reset issue.

if i set in main - str_title… i have 2 workflows example, login and working on portal.xaml

in login workflow, if i pass the variable, then it became argument, then i want to put like in_Str_Title right?

in that case if i directly go inside each each workflow and set the argument or i need to set it at high level only some confusions there…

also i dont want the title came outside..Its one time usable only for working on it

Got your point. In your case, if the title is only required inside that particular workflow and you dont need the value outside, then no need to keep it in Main or use In/Out.

For example, inside Login.xaml you can create a local variable str_Title and set the login screen title there. Same way inside WorkingPortal.xaml, create its own str_Title and set the work screen title.

Use an in_Str_Title argument only when Main is deciding the value and passing it to that workflow.

So simple rule is:

  • Used only inside one workflow → local variable
  • Value coming from Main/Config → In argument
  • Value needs to come back from child workflow → Out / In-Out argument

Since you mentioned title is one time usable only inside that workflow, I would keep it local there. No need to pass it till high level, otherwise it will just make the flow more complicated.