I have had occasional issues with VFE, let's call it the compiler step of VFE, that I think is worth bringing to the attention of others.
VFE creates global variables tied to each OBS("VALUE") that is used in text translation. It occasionally uses the same global variable for multiple OBS resulting in two fields being tangled together on the form. I have had this issue over multiple versions of VFE. We are now on VFE 7.04.
For example, today I found this in a .XLT file. Note the global variables have the exact same name:
{global F4124_1458173991_965 = OBSNOW("NEWBORN SCRE") ""}{global F4124_1458173991_965 = OBSNOW("LEAD SCREENI") ""}
It's very hard to catch these errors without extensively testing the form each time it is saved, or without examining the files before each import.
I have used VFE for years, literally hundreds of forms and thousands of obsterms/document variables, without ever having this problem. Suggest you contact Logical Innovations.
Can you confirm whether the form that you found this issue in was build with 7.04 or whether that is just the release that you are currently using, but this is an older form? There was an intermittent problem reported in the past, but I believe this was fixed prior to the 7.0 release.
Unique identifiers are generated using the license number and current time. Previously we waited a millisecond (based on tick counts) when creating the unique identifier before creating the string. We were never able to actually reproduce this. However, we felt that in certain situations (? on fast computers) the milliseconds retrieved from the time might still be unchanged due to rounding. Now we query the actual time and verify that the milliseconds have changed. The milliseconds are the last 3 digits in the number. In the example you posted these are identical for both variables. I can't think of how this could occur with the way our code is currently written.
If you can verify the information above we could try to review again and potentially add additional checks in our next release.
Thank you for reporting this. If you have any additional concerns or suggestions regarding Visual Form Editor please don't hesitate to contact [email protected].
Hi Mike, thanks for checking in. I am 90% certain the form was built with 7.04. I am judging that based on the date the form was last modified (March 2016) compared to the date of our 7.04 installer file (December 2015).
That's interesting to hear how you are generating the unique identifiers. Sounds reminiscent of the Centricity database's unique identifiers :). It does sound like rounding of milliseconds could cause issues. For what it's worth our machine is a Windows 7 virtual machine and it's possible it's running very fast.
Why do you query the time for each unique identifier? It seems like a guaranteed solution to this problem would be to query the time once when you're starting to compile, and then append a number that you increment for each new global variable. For example, if I hit Save, the global variables generated would be:
global F4124_1458173991_965_1
global F4124_1458173991_965_2
global F4124_1458173991_965_3
...etc.
Do you still have the original files (including .dlg) that created the problem?
Did re-saving the form with 7.04 solve the problem?
If it did, I suspect that it wasn't previously saved with 7.04. This is because starting with 7.00 Visual Form Editor would maintain the global variable names for observation term references between saves in order to facilitate comparison of file changes using version control. Also as noted above, when seeking to assign a unique identifier there was a check to make sure the milliseconds changed (e.g. from 965 to 966 in the example above).
I have reviewed and updated the code to now use a time stamp and a counter as well as perform additional checks to make sure that they have changed between creation of unique identifiers. In addition I have added functionality to force Visual Form Editor to recalculate all unique identifiers (in the unlikely chance that there are somehow two in an existing form that are identical).
These changes will be available in our next release. In the meantime, if you have the .dlg and clinical kit files available and would like me to review them I would be happy to do so.