Global variables

[judithPA]

I am using a global variable to move from a gallery form (list of jobs) to edit a selected record in an edit form

Select(Parent);Set(glbCurrentRecord, ThisItem)

and I return from the edit form setting the OnSucess property

Set(surveyPropID,glbCurrentRecord.ID)

I have a second gallery form (List of equipment used in a job) and now want to navigate to an edit form from this galley. Do I need to set a second global variable to identify the equipment item for this job or do I just use the same record trigger Select(Parent);Set(glbCurrentRecord, ThisItem)?

Thanks

[timl · Accepted solution]

@judithPA 

I would use a second global variable because the data type of the value that you're storing will be different. In the first case, it's a job item whereas in the second case, it's an equipment item.

[RusselThomas · Accepted solution]

Hi @judithPA ,

This is probably more a question of what you should do vs what you can do, so @timl is correct, but I'd actually like to expand on this a little for other people's benefit.

Variable record fields are generally type-specific and are formed using their originating construct - meaning a field is typed based on what you first put in it.  If "Title" was text when you first created it, you can't go along and put a number in there later.

If you create a variable with one construct, [Column A, Column B, Column C] and then later use the same variable to capture another construct, [Column C, Column D, Column E] - then PowerApps will actually create a merged construct, where the columns from your first construct are added to the columns of the second construct into a single record/table. 

[Column A, Column B, Column C, Column D, Column E].

When you capture one construct over another, new columns are added, existing unused columns are cleared and all common columns are overwritten.  If there is any column that has the same name across two source constructs, but different types (eg: if "Column C"  was a string type in one source, and a boolean or true/false type in another) you will get errors. 

So while you can do this, it's probably not advisable as I'm sure you can imagine it can get very messy - and if you use the variable anywhere as a record reference when writing back to your source you will also get errors, unless you drop any columns not specific to the source you're writing back to, again another tedious task to track.

I would suggest be intentional about your variables and their naming convention so you know what to expect from them.  I would call my first variable glbCurrentJob and the second glbCurrentEquiment or something similar - that way you know what to expect to find inside it at any given time.

Kind regards,

RT

[timl]

@RusselThomas - Thanks for the taking the time to describe this so well - that's very helpful 🙂

[judithPA]

Oh dear, I seem to have another problem. I add equipment items  to the sharePoint table by using some select and text boxes and patch those in to my equipment table. The selected equipment items all appear in a gallery above these selection options for the current job.

But when I click on the Camera button I was hoping that the current record would be displayed in the edit screen alongside and I could then add a photo if required.

Any suggestions please?