Notifications
Clear all
Topic starter
MEL Visibility - Time of firing.
I have set up a visibility region based on MEL code. The code watches for office visit order entry E&M and preventative OV codes. then the visibility is a true or false. This reminds providers to enter order with color coding prior to signing the visit note.
Visibility region 1 is:
ORDERSPlaced() == TRUE
Visibility region 2 is:
(ORDERSPlaced()) == FALSE
MEL code in the white space is as follows:
/* Function for order button visibility */
{!fn ORDERSPlaced(){
dordnewArray = getfield(ORDERS_NEW("list"))
for c = 1, c < size(dordnewArray),c = c + 1 do tmpstr = toupper(dordnewArray[c]) if (match(tmpstr,"OFC") > 0 OR match(tmpstr,"2011") > 0 OR match(tmpstr,"PREVENTIVE") > 0) then
return TRUE
endif
endfor
return FALSE
}
}
This code and visibility region combo works just fine except the visibility region only changes or fires when I move from 1 tab to the next in this form or I move to another form and return. I would like the visibility region to fire as soon as orders are entered without leaving the tab.
I would appreciate any help.
PS I just noticed that I used different syntax for my visibility regions in terms of parenthesis. I left this because this is how the form is functioning now for the purpose of this question.
Thanks JJC
Posted : January 5, 2020 8:10 am
All you need to do is pass an argument to trigger its evaluation. Instead of
ORDERSPlaced() == TRUE
Try
ORDERSPlaced(ORDERS_NEW()) == TRUE
Any changes to orders would update ORDERS_NEW(), which would in turn re-evaluate your visibility region.
Posted : January 6, 2020 1:27 am
Michael's advice is correct, but there is more.
1) Declare ALL variables in your function as local, otherwise they will be seen by other code and potentially be affected by other code using the same variable names. (i.e 'local c' and 'local tmpstr' and 'local dordnewArry')
2) Check the help file for 'getfield'. Unless you intended the code to break up the list of orders based on comma, space, semicolon or tab, the syntax is missing something... 😉
I'm old school, and so is MEL. I do not recommend returning out of a loop without first naturally ending it with either natural termination (all iterations complete) or using 'break'. While you can 'get away' with it today, I believe there is an opportunity for instability that I prefer not to allow. Just a personal preference.
Posted : January 6, 2020 2:16 am
Topic starter
Thanks guys,
Lee, I declared my local variables and I am working on cleaning up my coding.
Michael, passing the orders new argument work like a charm.
Again much thanks,
Jack
Posted : January 6, 2020 10:37 am
Glad to help, Jack!
Arguments are often not given much consideration aside from their usefulness for passing values inside of a function. In reality, arguments have a dual purpose:
1) Pass values for use into the function using the assigned variable name
2) To act as a trigger for firing the function, making it essentially a watcher expression (the method you are now utilizing).
The second purpose is a blessing as much as it is a curse. While extremely useful for actively updating content, it also has a downside of triggering the function when any one of the arguments used are updated in the form. While this is actually desired behavior, if the code is not written well, it can create a serious amount of recursion in that each argument has the ability to cause the function to be triggered as each argument value is changed.
The best way to manage this is to either utilize buttons to fire the potential trigger heavy code (most hate this approach), create and use 'sub-variables' that only change when certain conditions are met or wrap the function call within conditional logic to control when the function should be fired. Without these types of 'controls' in place, a function with multiple arguments that are refreshed/updated (i.e. obsterms) potentially could be triggered repeatedly. This creates a lot of processing for the EMR and potentially can impact performance, even if it is just a little bit (all those bits can really take a byte out of performance - sorry could not resist it).
The good news is that with a single argument, as in your case, this is limited naturally, but I did want to make you aware of the potential to impact performance so that you can logically devise methods to minimize it should you expand to multiple arguments.
Posted : January 7, 2020 7:36 am
