Custom Form creation

cfapress wrote on Tuesday, February 03, 2009:

Hi All,

Does anyone know of a free open-source solution like this one?
(check out the live demo)

http://www.customformdomain.com/features.html#

I started coding something but have been really bogged down. I’m relying on jQuery and finding myself buried in DOM hell. It would be nice to find that somebody else has already built something free and available. I’d like to integrate a really nice form builder into the OpenEMR project so that people can more easily create their own custom forms and reports.

Jason

mike-h30 wrote on Tuesday, February 03, 2009:

I just kicked off a custom form project for our office and used Mark Leeds’s script  “contrib/forms/formmaker/formscript.pl” .

This script worked great!!  I used it to convert our Adobe Reader editable PDF forms in our office to web forms.   I then added some coding to print the data stored in the openemr db back onto the PDF.  

-Mike

omo66 wrote on Tuesday, February 03, 2009:

For me the openEMR formmaker worked but did not save checked boxes
e.g after submitting form, I clicked the encounter to see only text area was saved.
PS:
I tested Jason’s form example2, it has mysql error when submit was clicked.

markleeds wrote on Tuesday, February 03, 2009:

Omar:

That problem with formscript.pl was fixed but missed the release .  Download newest version from cvs.

omo66 wrote on Wednesday, February 04, 2009:

Thank you Jason,
No It is real, the formmaker does’nt handle the check-boxes correctly…
I checked the DB, it seemed to save all complete data correctly.
When you try to view the form, it will only show text fields filled out while check boxes will remain unchecked. So if submit the form after adjusting the text fields this will reset original saved data and make all check boxes as unchecked.

There error must be within view.php?

markleeds wrote on Wednesday, February 04, 2009:

Omar,
You are right, I thought you meant the other checkbox problem.  I just tried out a form.  We’ll have to fix that view.php problem.  Sorry.

mbrinson wrote on Wednesday, February 04, 2009:

About 2 years ago I had updated the formmaker script to address this problem.  Did that version never get put into CVS?
Or maybe there was a problem with it that I didn’t come across…

Works fine for me, although I haven’t used it in quite a while now.  Do you remember that e-mail conversation Mark?  I know it’s been a very long time since I’ve contributed anything to the project, so you might not remember…

cfapress wrote on Wednesday, February 04, 2009:

I agree that Mark’s formmaker.pl is a very nice script. I’m looking to develop something that a user can work with, not a developer. Thus a WYSIWYG interface is preferable. I’m still tinkering with jQuery and the HTML DOM but have found it pretty frustrating.

Jason

markleeds wrote on Wednesday, February 04, 2009:

Mike Brinson!

I am glad that you are here because I lost my old emails and I was trying to figure out what new feature you added.  It makes sense to me that it is in view.php, because that stuff doesn’t look familiar to me.  I committed your version on 9/23/06.  You can read the cvs log at:

http://openemr.cvs.sourceforge.net/viewvc/openemr/openemr/contrib/forms/formmaker/formscript.pl?view=log

Jason:

I agree it would be good to make a user configurable form.

One thing to consider is that users should not have control over the database.  The only alternative I can think of is to save all form data in a text field.  Then you need another database field to save form configuration. 

All form elements should have drag/drop capability and the user should be able to add and remove any elements. There should be a lock button to lock the form in place.  We could have a bunch of these forms in the forms directory, maybe 5-10 of them.  Users can register as many as they need and use the nickname feature in admin to give them unique names.  ACL can be used to limit who has access to configuring the forms.

It’s a big job, but definitely possible.

mike-h30 wrote on Saturday, February 07, 2009:

The quotes are missing in the "value" attribute of an "input" field created by current "formscript.pl" (v.1.14)in "view.php."   The result is that ONLY the first word in the database column displays in the input field and leaves out the rest of the text.   Current "formscript.pl" creates the value attributes as:

value=<?PHP_CODE?>

instead of putting quotes:

value="<?PHP_CODE?>"

//From formscript.pl  Displays FIRST word only from DB Field.
<tr><td> <? xl(“Your db field name”,‘e’) ?> </td> <td><input type=“text” name=“your_db_field_name” value=<?php $result = chkdata_Txt($obj,“your_db_field_name”); echo $result;?>></td></tr>

//Need to add quotes in “value” attribute to get entire database field to display
<tr><td> <? xl(“Your db field name”,‘e’) ?> </td> <td><input type=“text” name=“your_db_field_name” value="<?php $result = chkdata_Txt($obj,“your_db_field_name”); echo $result;?>"></td></tr>

-Mike

omo66 wrote on Sunday, February 08, 2009:

thank you Mike, This will help me finish the consult-form I started creating for my office new consults notes.
I will run the script to make new file and test you recommendations.
I started using the old form maker released 9-23-2006. This old release has also a major bug. It did not save first text field to database unless script did run through view.php to activate mode==edit.

omo66 wrote on Monday, February 09, 2009:

it did not work.

mbrinson wrote on Friday, February 13, 2009:

I haven’t looked at this in a LONG time, and when I last used it it did work.

That code that Mike posted looks like it should do the trick, but that is to my untrained eyes.
Was there any change in your results after you tried the new code omo66?  I know you said it doesn’t work, but does it not work “differently” than it didn’t work before?  :slight_smile:

mbrinson wrote on Friday, February 13, 2009:

I was looking through formscript.pl again and I can’t figure out why it wouldn’t be checking the boxes for you.

It all centers on line 291:

function chkdata_CB(&$obj, $nam, $var)
    {
        $objarr = explode(’,’,$obj{$nam});
        foreach ($objarr as $a)
            {
                if ($a == “$var”)
                    {
                        $result = “&quot;checked&quot;”;
                    }
            }
        return $result;
    }

So, the value=“checked” should come back with quotes already surrounding it in the $result variable.  Shouldn’t be a need to put them around the $result as mike-h30 was saying.  As I looked through it was having vague recollections of this maybe having something to do with the CGI qw(:standard) at the beginning of formmaker.pl    I remember researching that quite a bit to figure out the syntax for all of the return statements for the tables such as:  $return .= Tr(td($label),td(scrolling_list(-name=>$field_name, -values=>$_, -size=>scalar(@$_))))."\n";

The whole -size=>scalar blah blah… it was all very specific and maybe that has to do with it returning the quotes or not.

Man, looking through the code it amazes me that I actually put a lot of that stuff together.  No way I’d be able to do it again.  (If that doesn’t instill great confidence confidence in the existing code for the script, I don’t know what will.)    ;^ )

Sorry for not being any help…

markleeds wrote on Thursday, March 12, 2009:

Omar,

I have addressed the issues with view.php and I think your problems will be resolved with this update.  The changes are in formscript.pl, so you have to run it again on your template file to regenerate your form.  Back up your existing form if you have made changes to it and replace it with the new form.  I am sorry it took so long to get around to fixing this, but I don’t have much free time these days.  It was not too hard to fix once the problem was identified.

I don’t know if cvs is working yet, so you can get it for now at http://mjl69.com.

Mark

omo66 wrote on Thursday, March 12, 2009:

Mark,
Thank you very much for the fix. It was very kind of you to do this and I appreciate your contributions.
FEEDBACK:
CAMOS helped me alot to write office notes. Now I use instead my own forms.
I did not use CAMOS as ordering system but I will do so after upgrading CAMOS to auto-save the new order as PDF automatically into EMR docuemnts with logs to track all orders so the PA could follow up on results.
I studied to script of form creator and thought that problem was inside explode function with missing positive negatives of check boxes. I will have to check the new fix.
Thanks again. 

voipbound wrote on Friday, March 13, 2009:

should we share forms created or is there a thread for that already?