myEvolv Classic – CorbiNet Blog

How To: Setup Multiple Subforms from the Same Form Family on a Single Parent Form

July 18, 2022July 13, 2022 Dean 1 Comment

When you put a Non Event Based Subform on Form, the database link between the parent form and the subform occurs on event_log_id. For example, if you have a Materials Provided subform on your event form, each row in that subform will create a row in the materials_provided table and the materials_provided table will have the event_log_id of the event it was added from. myEvolv uses that link to know which of the materials_provided rows to display on the parent form – only those that were entered on that specific event with the matching event_log_id.

When you use two or more subforms from the same form family on the same parent form, a complication arises. If you do not change the default behavior of the subforms, all of the subforms from the same form family show all of their rows from the form family table regardless of which specific subform was used to enter the information.

Here is an example. This form has two subforms on it – the top one is used to track the notifications that were made once per event. The bottom one is used to track notifications that must be made per child who were involved in the incident. Both of these subforms are created in the Materials Provided form family.

This is the form filled in but not saved. Each type of notification is in its rightful subform and there is one row per subform. After Save, the problem arises:

Both subforms now have both rows listed in them, each showing only the fields that are defined in their respective subform design (see the lack of Child column in the first subform). So what’s happening here?

“Out of the box”, a Materials Provided subform will pull all of the materials_provided database table rows that belong to this event – and both rows do because both subform rows were added on this parent event. But we want them to stay in their own subforms so that a user looking at this event after save can see the data organized in the intended manner.

Thankfully, myEvolv has a way to do this and it involved using the List Condition attribute for the form header used on these subforms.

The List Condition attribute allows you to put further filtering on the query that determines which rows will pull in on the subforms. It is literally the conditions for when to list a row in the subform and it acts like everything after “WHERE” in a SQL where clause. This means that there are a lot of possibilities for filtering – you can use any of the columns in the form family table to filter on and combinations of them.

For our example, I want to keep the event-level notifications in one subform and the child-specific notifications in the other subform.

To do this, I create a user-defined field of Regular String type in the Materials Provided form family and add it to both of my subforms. It can be left not visible on subform so that users don’t see it.

My custom database column is called udf_list_cond_filter

For the event-level notification subform, I give this column a default value of ‘event’ (see image below)

And for the child-specific notification subform, I use the same field setup the same way, but I give this column a default value of ‘child’

Now when a new row is added in one of the subforms, this column is getting the value of ‘child’ or ‘event’, depending on which subform is used. We will use that fact to filter using the subform’s list condition attribute.NOTE: you can use whatever terms you want for your default value and list condition logic, these are just what I chose for my example. The important thing is that it will match between the forms list condition and the default value.

On the event-level notification subform, my List Condition value will be

udf_list_cond_filter = 'event'

and on the child-specific notification subdorm, my List Condition value will be

udf_list_cond_filter = 'child'

This is telling the subform to only list a row from the materials_provided table if the event_log_id matches the parent event (already happening automatically) AND if the udf_list_cond_filter column has the matching value in it.

With this all setup, when I enter a new event with the same values as before, it will look the same after saving as it did before saving.

To make it clear what is at work here, the image below shows the udf_list_cond_filter fields visible on both subforms so you can see how they look behind the scenes.

This setup is extensible, allowing you to setup as many subforms from the same form family as you need to achieve your desired effect.

NOTE: This setup will not work retroactively on already-saved events because the new udf_list_cond_filter value on all rows that exist until you do this setup will not have a value set in them to filter on.

ARCHIVE How To: Default a Date Field Value Based on Another Date Field

June 2, 2016July 2, 2022 Dean 3 Comments

NOTE: THIS POST CONTAINS OBSOLETE CODE THAT WILL NOT WORK IN NX. I WILL KEEP THE POST AVAILABLE SINCE IT MAY PROVIDE SOME INSIGHT IN HOW TO USE JAVASCRIPT TO MANIPULATE MYEVOLV FORMS. YOU CAN FIND THE UPDATED VERSION OF THIS POST HERE.

When working on treatment plans in myEvolv, you will notice that many of the treatment plan component forms contain both a start date and a target completion date. One of the programs I was building a treatment plan for wanted to have the target completion date on the form but always wanted it to be 90 days from the start date. Instead of making each clinician calculate 90 days from the start date and fill it in themselves, I used this method to take the date value from the start date and update the target completion date field with a value that is 90 days later. I will walk you through the JavaScript that I used so that you can make adjustments based on your needs. The full snippet of JavaScript will be at the end.

two-fields

Where does the code go?

The first consideration is where to put the JavaScript. In this case, used the ‘On Change Script’ field property on the field that will be modified by the clinician, ‘start_date’. myEvolv provides us with access to 3 events that we can use to trigger our JavaScript handlers (the code we want to execute): ‘On Change’, ‘On Click’ and ‘On Load’. The ‘On Change’ event is fired when the value of the field has been changed. This is the most suitable event to use in this situation since I do not want the new date value to calculate until there is a value in the first date field. Furthermore, if a clinician makes a mistake entering the start date, I want the new date to recalculate when the clinician makes an adjustment. Both of these scenarios are covered when using the ‘On Change’ event.

Get the ‘start_date’

The first line of JavaScript code’s purpose is to get the value that has been placed into the ‘start_date’ field and convert it into a proper JavaScript Date object so that we can manipulate the date easily. I decalred a variable named date and set it to be a new Date object passing the value of the ‘start_date’ field as its argument:

var date = new Date(document.getElementById('start_date').value);

Calculate a New Date

Now with the date entered by the clinician converted to a Date object, I can perform some calculations on the date using the ‘getter’ and ‘setter’ methods built in to JavaScript Date objects. In my scenario, I need the ‘target_date’ field to be +90 days from the ‘start_date’ so I used the getDate() and setDate() methods:

date.setDate(date.getDate() + 90);

If I wanted to do +3 months instead, I would use the getMonth() and setMonth() methods:

date.setMonth(date.getMonth() + 3);

If I wanted to do +1 year, I would use the getFullYear() and setFullYear() methods:

date.setFullYear(date.getFullYear() + 1);

There are also methods for getting and setting hours, minutes, seconds, and milliseconds, but I am dealing with Date Only fields in this scenario.

Format the New Date

Now that the date object has my new date stored in it, I need to put that value into the ‘target_date’ field. However, the date in the date object is not formatted in a way that myEvolv’s date fields like so I need to pull the individual date elements from the object and build a string value to place in the date field. I accomplish this first by declaring variables for the month, day and year:

var mm = date.getMonth() + 1;//+1 is needed because in JavaScript Date objects, January is 0
var dd = date.getDate();
var yyyy = date.getFullYear();

Now I declare a new variable called formatted_date and set its value to a concatenated myEvolv-friendly string:

var formatted_date = mm + '/' + dd + '/' + yyyy;

Set the ‘target_date’

Next I can put this string into the field on the form. Since I will do a few things to the ‘target_date’ field, I am going to create a variable called target_date to refer to it more quickly:

var target_date = document.getElementById('target_date');
target_date.value = formatted_date;

Awaken the ‘target_date’ Field

You might think that you are done here because the new date has been loaded into the form, however, because I used JavaScript to update the value of ‘target_date’, the form itself does not recognize that a change has been made to ‘target_date’ which is indicated by the form label and field value text turning red. Even though the value is in the form field, upon saving, the form will not recognize the field as having a new value and will not include it in its save operation. One way to fix that is to manually click in the ‘target_date’ field and then click out of it so that the form recognizes a change in the value of the field but that is un-intuitive and error-prone. Luckily, JavaScript provides a method for simulating this with the focus() and blur() methods to use on form fields:

target_date.focus();
target_date.blur();

With these two lines at the end, after the new date value has been filled in on the ‘target_date’ field, the field label turns red which means that the form has recognized that its value has changed and it will include the change when the form is saved.

two-fields-filled

One Caveat

You may be inclined to disable the ‘target_date’ form field so that clinicians cannot change the value after it has been calculated. I was unable to get that to work, however. When a form field is disabled, it is excluded from being saved so for now it would seem that you have to keep the form field modifiable. If you used ~~this same~~ similar* code in the ‘On Change Script’ property for ‘target_date’, you could prevent the ‘target_date’ from being changed by effectively reverting any attempts at changing the ‘target_date’ manually.

*You will need to also add some JavaScript to validate that the ‘target_date’ has been changed because if you just put this exact same code in the ‘On Change Script’ property for ‘target_date’, you will end up in an infinite loop when ‘actual_date’ is changed on the form and you will crash the browser.

The Full Code

var date = new Date(document.getElementById('start_date').value); date.setDate(date.getDate() + 90); var mm = date.getMonth() + 1; var dd = date.getDate(); var yyyy = date.getFullYear(); var formatted_date = mm + '/' + dd + '/' +yyyy; var target_date = document.getElementById('target_date'); target_date.value = formatted_date; target_date.focus(); target_date.blur();

ARCHIVE How To: Default Value in Picklist Field

May 26, 2016July 2, 2022 Dean 1 Comment

NOTE: An updated version of this post for myEvolv NX is available here: How To: Default Value for Picklist Field

You may find that a myEvolv form that you wish to use contains a picklist field that cannot be done away with even though the user is always going to be selecting the same item. For instance, you may have a treatment plan for a program where there is only one category of goals but you have to select that category manually anyways. Just like other fields in myEvolv, you have the option of setting a default value for a picklist field but it is a little trickier to setup than it is for text and date fields. Defaulting values for picklist fields where there are no real choices to be made will save your clinicians time when doing their work in myEvolv.

Some picklist fields have both a button that opens the picklist dialog and a place to type a code, which allows for faster entry for users who know the codes.

You might think that you can designate a default value in the form designer in the same way that you designate a default value in a text field since there is a sort of text field available. If you try that, however, you will find that this does not work. The difference is that this field is actually used to store a foreign key value and so the default value must be a foreign key (the GUID) and not the description or code values for the item that you wish to default in. Remember to place it within single quotes as you would a default text value.

In my example, I needed the GUID for a custom treatment category named “Day Treatment”. Looking at the field properties for this picklist field, I see that the Lookup table that is being used is ‘Problem Category Lookup – Not Safety Plan’, which tells me that I need to take a look at the ‘problem category’ table.

I pulled that table into Crystal Reports and made a quick and dirty report that shows the problem_category_id and the description and grabbed the GUID that corresponds with my Day Treatment category.

With the GUID used as the default value on the picklist field, now ‘Day Treatment’ is the default value on the treatment plan whenever a new Category component is added to the treatment plan.