How to carry some data from a screen to another one

HI,

I have a customer form. After I create a new customer, I want to carry customer data to new screen. How do I store this data?

Thank you

Hello @Hnin-fccd! All you should have to do is create a variable on the second screen, and then populate it using a Quick Action on the original (customer) screen. Here are a couple screen shots that may help:

Let us know how it goes!

2 Likes

I got it. Thanks for your help.

I have a similar issue but the above technique is not working.

I am working on an internal chemical inventory system which has a table of Chemicals, which contains general data about the chemical, and each chemical has related Lots, which contains data specific to the particular container (expiration date, location, etc.). For the data entry, the Chemicals form allows the entry of the basic info, but the wizard created a "Done" button that redirects to the previous page. I would like to redirect to the Chemical Details page where I have button to go to the Lot form where the detailed information about the individual container can be entered.

As you can see in the screenshot above, the datacell from the Chemical Form (=$[Chemical]) should be sent to the InputRow of the Chemical Detail page. However, I just get the dreaded "VALUE".

Any ideas where I am going wrong? I could possibly change the flow to redirect to the Lot form, but I am stuck on that for the same reason.

Thanks in advance and love this tool!

Have you tried Take data from: =thisrow() ? I think $[Chemical] is a variable on this screen (Chemicals form) that is not related to the Tables, even though you may have a column of the same name, and would be of type Plain text. Usually the templates and demos are passing Rowlinks to the next screen.

I have. Get the same result, "VALUE", on the details page.

hmm maybe try this on Chemicals detail with condition = TRUE :grimacing:

Hi @JCoop, good question,

If I'm understanding you correctly, you are on the screen that just created a "Chemical" entry in Chemicals table, and now you want to go to the next screen and add more details about this particular chemical (location, etc...). If this is correct, I'll call what you are trying to do the "Save-and-Add-More-Data Wizard Pattern." A wizard because you are looking for a guided experience for your users or you want to do some automated steps that also need the row you just saved; you want them to enter something quickly and then add more details.

There are three ways to accomplish what you are trying to do, but only the third one is the wizard experience I'm talking about:

  1. Go back to a "list" of all Chemicals and have the user click on a button that takes them to a big edit screen with all the fields. You probably know about this, but it requires searching and it is not user friendly.

  2. By saving and revealing more fields (previously hidden) on the same page.
    You can stay on the same page and reveal more fields. To do this, set a hidden local variable (let's call it "EditMore") =TRUE, and have all the hidden fields in a block whose visibility =$[EditMore]. The EditMore variable =FALSE by default. This method saves you going to another screen and you can keep editing in place. However this is still not the nice wizard experience; also if you have some special logic for showing some fields conditionally based on the type of chemical for example on the same screen which can be complex.

  3. Going to a new page altogether. To do this you will need to FINDROW() that you just created, otherwise there is no THISROW() because you are not in a list, and $[Chemical] is just a local (not Shared) variable that is not a reference (ROWLINK) to the row you just created. So the record (aka. ROW) you are trying to pass to the next screen does not exist anywhere on the form for you to reference.

The short answer in your case is to replace =$[Chemical] in the "Take data from:" with a formula like this:

  • =FINDLASTROW(Chemicals,"Chemicals[Name]=$[Chemical]")
  • Assuming that in your table there is a Name column where you put the Chemical's name.

There is a problem with this approach. What if two people create the same chemical at the same time which one do you get? One way to work around this is to have two hidden variable fields on the form and corresponding columns in the Chemicals table: CreatedBy and CreatedOn. The first is =$[SYS_USER] in the form, and the second =NOW() in the form. Then you save these in the table and you now have who and when this record was saved, and have a lesser choice of encountering the "two-people-entering-same-chemical" problem. In this case your find row formula would look like this:

  • =FINDROW(Chemicals,"Chemicals[Name]=% AND Chemicals[CreatedBy]=% AND Chemicals[CreatedOn]=%",$[Chemical],$[CreatedBy],$[CreatedOn])

Because the navigation action is the last think you do on the screen, the local variables are guaranteed not to disappear on you, and by adding a bit more data you can get pretty close to a guarantee that no two people will enter the same data at the same time.

You can also use this formula, if you are doing multiple saves at the same time and then navigating onward. I have used this in a table where I create a Request, and have to add Attendees, related to the request I created, in another table (also from another table). You can do some amazing things with this pattern. Here is how that automation looks in my app (as an example). Notice the hidden CreatedBy and CreatedOn fields; also I do not use the $[Request] in my FINDROW, maybe I should?

Hope this helps,
DT.

Thanks for the help Daniel. I will definitely give approach 3 at try. It still seems odd that the newly created record can't directly be accessed by its unique id immediately after creation. Is this to prevent data latency issues? If that is the case, isn't it still possible to return a null value with the above method? What I mean is there any way for the search for the LASTROW() to outrun the writing of the new record? If not, why is a LASTROW() search different from a FINDROW() search. If there is no difference, I am back to my original question of why can't the newly created row be directly accessed?

Again, really appreciative of your help and Honeycode is absolutely amazing! This just seems like a gap in capability.

hi @JCoop,

Being able to get the ID/row of the record you just saved makes sense; I'll add it as a feature request for our product team to consider. Regards your other question: I've used FINDROW() and FINDLASTROW() in this case and they behave the same. FINDLASTROW() is a convenience method that goes to the bottom of the table and picks the last row entered, but neither of them finds (by default) the record entered by a given user, so you have to add the SYS_USER or something else to ensure you get the latest (or the exact one) entered by you - in the rare case that you have two people entering the same thing.

Hope this helps.
DT.

1 Like

Just wanted to do a quick update to let everyone know what the final solution looked like (also, let me know if there are other better ideas).

I have a button on the home page to add a new chemical to the inventory.

That takes you to the page where the "macro" data can be added.

Once the information is added, the Done button will turn blue (actually two buttons, but the blue one does all the work and is just hidden until all the data is entered, then the grey one is hidden). That button takes you to a details page for the for the newly created chemical.

This works because the row source for the InputRow on the details for is set using the FINDLASTROW() function.

From there the Add Lot button, opens the page for entering the detailed information, taking the data from the InputRow of this form and writing it to the linked Chemical content of the Lot form.

This is a two step approach, but it does allow the user to double check the initial data entry before moving on the entering the details, so it seems to be working well for us.

Thanks again for all the help from the Community on this!

1 Like

hi @JCoop,

Looks like it is coming together very well. One think I wonder about:

If the FINDLASTROW() is on a secondary screen should not the "calling" screen do the FINDROW and send the correct row to the next screen?

Other than that it seems nice.

Cheers,
DT.

Hey Daniel,

I'm not sure what you mean by "calling screen"? The workflow is as follows: New Chemical Form -> Chemical Details -> New Lots Form. The "Done" button on the New Chemical Form directs you to the Chemical Details, which is populated with the information that was just added via the FINDLASTROW(). The "Add Lot" button on the Chemical Details uses the InputRow to direct to the New Lots Form, which adds a linked record in the Lots table.

Are you saying to set up automation on the Chemical Details to automatically re-direct to the New Lots Form? Something that would basically just make the Chemical Details page blink on and then move to the New Lots Form without user interaction? If so, how would the automation be set up?

Thanks again for the interest in my little project. You guys have a pretty stellar team who obviously are deeply invested in the success of your customers.

Thanks again,
JC

hi @JCoop,

My only concern was that looking up the chemical, in a multi user app, on the second screen (or any screen for that matter) could give you he wrong chemical. I usually recommend that you look it up with more than just the name or just TRUE/FALSE. As it is FINDLASTROW() will return the last thing you entered, but if you have two people entering records you could be editing other person's record.

LMK if this makes sense.
Cheers,
DT.

So maybe combine FINDLASTROW() and the user? What would that formula look like?

Thanks again for your help!

JCoop

hi @JCoop,

Here is an example of a formula that I generally use:

=FINDLASTROW(MeetingRequest,"MeetingRequest[Title]=% AND MeetingRequest[CreatedBy]=% AND MeetingRequest[CreatedOn]=%",$[Title],$[CreatedBy],$[CreatedOn])

In this case I basically look up the MeetingRequest by Title, CreatedBy and CreatedOn. So I get the request that meets the Title, as well as who created it and when it was created.

You can pass the three variables from screen 1 to screen 2; or you can lookup the row with FINDROW as described above and pass one variable to the $[InputRow] of the second screen.

Here is what this looks like in what would be my screen 1 (where I only add a few things to the Meeting request, and then pass to screen 2 to add more info to the Meeting request):

Hope this helps,
DT.

Thanks for the example! I will see what I can implement with this method.

JCoop