Hi Etienne,

The reason why your example above doesn’t work is because the defaults are calculated when the form loads and at time of loading txt1 doesn’t contain anything so therefore the uppercase of txt1 also returns an empty string.

You’re on the right track with your rule which bascially checks to see if txt1 has been populated and then you can set what should appear in txt2.

As for setting default values.  Yes - context variables work because they’re known at time of form load but there are plenty of other dynamic items that can be set - basically anything else in the formula builder such as dates etc.

Also what are you trying to do with txt2?  If it’s simply to get the uppercase of txt1 and never be editable by the person entering data into the form, I’d create a form variable instead with the uppercase formula in it.  Then you can reference this formula in a label on the form and also from the workflow.  If you need the field to be editable after it has been calculated then you will need to use the rule as you have described in your post.

Cheers,

Chris

Thanks Chris

What I don’t understand then is why is it possible to do this for the other properties, like Visible or Required. 

If I set the Visible property to be the Yes/No based on other fields from the form using a formula, it won’t have any value to begin with when the form is loaded. But as things change in the form, it may or may not become visible. I guess I’m misinterpreting the “default value” with what could be named “current value”, which doesn’t exist or at least is not showing as an available property.

My specific use case was as follows: 

I have a drop down connected to external data set (SQL but doesn’t really matter), the data set represents a set of user with properties ID, Name and Email.

On selection of a record, I want to retrieve the Email property for the selected record and store it so I can use it later in the workflow. 

What I ended up doing was creating an external data variable with the filter based on the item selected in the drop down, which works, but I’m wondering if this is the correct/preferred way of doing this. 

Hi Etienne,

Yep - you got it.  The default value is calculated only once (during form load) whereas the other properties such as visibility are always recalculated.

If you’re wanting to get that email property from the data set then there are a few ways to do it:

1. If you don’t need to know the person’s name and only want to know the email then you could choose to display the person’s name but save the email like this:

2. However what I’d usually do is display the name and save the unique identifier such as the ID.  Then you can create a second data source variable (DSV) and filter your results based on what was selected in the data lookup control.  That DSV can return multiple attributes such as email, name, phone etc and you can choose to display them in the form or save them as form variables.  Once you have saved them as form variables you then can access them from the workflow
3. Another method is to look up the data from the workflow.  So you still have the data lookup control and save the ID but then in the workflow you use the query action (e.g. Query a SQL Table) and pass the ID saved from the data lookup control as one of the conditions.

So in your case, I wouldn’t need the 2nd field and use either the email address saved in the data lookup control or save the ID in that control and lookup the other values that you need.