Notifications
Clear all
Topic starter
I'm still new to VFE and trying to determine if there's a way I can add personal notes to myself in VFE. What happens is, I'll create a form, then the doctor will ask for a change and I'll make it, then he'll ask for another, or several more change(s) and I'll make that/those and each time (if doing anything new to me or major revisions) I'll increment the form name (PMHX, PMHX2, PMHX3, etc.). But there are also several times I may be asked to undo something and I can't always tell at a glance from withing the form what change(s) I made in which version. I'd like to be able to document to myself within the form what changes I've made.
Posted : January 15, 2018 5:20 am
We frequently keep change notes at the top. We add a comment block where myself and other developers can document the changes.
Comments are surrounded by /**/ or one line as //
/* Anything in here is commented out */
/* Version 3 */
/* Added a checkbox for no pain */
/* fixed rendering on PMH */
/* Version 4 */
/* fixed error from PMH rendering in version 3 */
Posted : January 15, 2018 5:28 am
We also keep a copy 1-2 versions back; just in-case we need to look at the code from last version.
-James
Posted : January 15, 2018 5:29 am
I also use the comment tags mentioned above to make notes in my code. If don't want to put these notes in the white board, you can also make notes in the "Form Description" box on the Form Information window (double-click in a blank area of the form.).
If you click the + next to the field, it will expand the text box so you can see more of the comments you are typing. At the bottom of that window it states,
"Information stored in this section is for reference and tracking purposes only. It is not included in the clinical kit or transferred to the EMR."
Posted : January 15, 2018 6:11 am
I agree with James, ours usually looks like:
/*****************************************************************************************************/
/* Modified by: Date: Change: */
/* --------------- ---------- -------------------------------------------------------------------- */
/* Gene Pincomb II 12/20/2017 Created. */
/* Gene Pincomb II 12/26/2017 Added Questions for Brief Intervention, Teen Intervene, and Outside */
/* Treatment. */
/* Gene Pincomb II 12/28/2017 Added Data Display for Previous CRAFFT Score, Brief Intervention */
/* freeform boxes, and secton containing Substance Abuse Education and */
/* Behavioral Health Referral fields. */
/*****************************************************************************************************/
Posted : January 15, 2018 6:15 am
Topic starter
Awesome. Thanks for the assist!
Posted : January 17, 2018 6:06 am
One line comments in MEL are C style only as far as I know so //
Posted : January 18, 2018 6:16 am
There is a section in the form properties where you can insert extended comments regarding a form as well. I generally enter all versioning information there. This information will be included in the .txt file created for the form to make it easy to review from outside Visual Form Editor or to send a list of changes to someone else.
Inline comments in the code can be made using /* */ or // as noted above.
If you want to track form changes (and have some technical experience), I would strongly recommend using a git repository. I didn't actually set mine up, but I don't think this is terribly difficult. You can then review any changes that are made to the clinical kit files between versions and check in new versions. You would probably want to keep all of the files associated with the form in the repository. It is unable to do comparisons on the .dlg files because they are not text files. It has some difficulty with .EFM file changes when you insert an item as it sometimes gets confused about which lines correlate, but you can usually figure out what was added by looking at the .TXT file comparison. It is very easy to see changes in the code in the XLW and XLT files.
I have been doing this for a couple of years and find it very helpful.
Posted : January 18, 2018 8:22 am
I want to add a few things to this. First, I have had issues where commenting on one line with // has actually broken my code, so I only ever use /* */ to comment.
Second, we add changes to the top of the code window as suggested, but I go one further and use the comments at every single function or even within functions to explain how certain pieces work. I've found that there's no such thing as too many comments, especially because it's really hard to remember why I made a choice a week ago, let alone six months ago. This prevents re-work as you don't have to make the same mistakes again in order to determine why you made a choice in the past, and it helps with handing off the work to another team member.
Posted : March 6, 2018 7:08 am
