Is there an easy fix to allow the textarea field in layout based forms to expand vertically as well as horizontally in ver 5.0.2? The handle at the bottom right corner of the text box used to be able to do this in prior versions. It is helpful for users to see their entire composition while entering text. In layout the height need only be set at 3 lines but the user may need 20 lines to complete an entry. It makes no sense to have to set it to 20 in layout mode.
hi @Joel, couldn’t confirm this bug on the 5.0.2.2 demo at https://seven.openemr.io/f/openemr/interface/login/login.php?site=default
what browser is in use?
I am running 5.0.2(1) in Firefox 75.0
-Joel
am remembering your other post now and thinking there’s something else going on with your install
might want to test with xampp with php @ 7.3
Before updating, downdating, php to 7.3 I went back to my test installation of xampp 7.4.4 openemr 5.0.2(1) [Windows 10] to reproduce the problem of no vertical expanding in LBF textarea fields with the bottom corner handle. No Problem! Then I noticed that the layout theme was light, default theme. I changed the theme to cobalt or anything else and opened a LBF - No vertical expanding in any textarea! changed theme back to light and textarea expanded ok. Everyone seems to like cobalt of powder blue around here. Maybe cuz of the UNC Tarheels! Its going to be hard telling everyone they have to use the default theme. IMHO I think its a bug in 5.0.2(1). If you can’t reproduce it I will look into loading up PHP 7.3.
Stephen,
Two things. First the minor one, then a new major problem with billing in 5.0.2(1). Let me know if I should open a new topic for the 2nd problem here.
-
Could you reproduce the problem with not being able to expand textarea boxes in LBFs when other than default theme was selected?
-
Batch payment under Fees crashing when entering payments. This one is hard to explain. After entering several payments I got this message and could go no further:
“None of the Top Distribution Row Can be Completly Blank.
Use Delete Option to Remove.”
(Yes, there is a typo in the error message)
The encounter field was empty in the top distribution row and I could not enter any more payments. I also noted that the allocated amount did not add up to the total amount of check entries made. It seems there was a disconnect between payments and EOB invoices which had all been created properly. I deleted the entries in Batch Payments and tried again. Same thing but crashed after only one successful entry.
I took your advice and installed XAMPP/PHP 7.3.16 from Apachefriends. I am not sure how this should have been done but in the end it did not help. After the reinstall I made sure all the check entries were deleted, charges returned to the encounters, and EOB Invoices cleared. That happend by deleting the check entry in Batch Payments. Then I tried to reallocate the check using the batch payments and crashed payments again.
Here is briefly how I “re-installed” openemr in XAMPP 7.3.16
-made backup of c:\xampp
-ran mysqldump to make a dumpfile of the database
-deleted c:\xampp and ran the xampp 7.3.16 exe
-moved my \openemr\ directory to the new xampp\htdocs
-made recommended changes to php.ini
-created an openemr database with phpmyadmin
-ran mysql to restore the dump file
-ran sql_upgrade.php to upgrade the db from 5.0.1 (did not get any errors)
Logged into openemr OK. Then tried to reallocate checks in batch payments as mentioned above. Payments crashed. That is where I am right now. Not knowing what to do next.
-Joel
FYI, don’t know if this helps but this is what the Edit Payment screen looks like after distributing one payment in the initial “Payments” allocation screen following the saving of check info. Distributing this one payment crashed the “Payments” screen and I returned here by searching for the payment. Note the missing data hence the error:
“None of the Top Distribution Row Can be Completly Blank.
Use Delete Option to Remove.”
None the less, the payment was processed for the patient encounter and the EOB invoice completed.
Thank you for looking into this.
-Joel
Yes. I set those before running sql_upgrade.php. The only difference is that I set memory_limit = 1024 since my emr_backup.tar was 492 MB. Also, the last setting in that list “mysqli.allow_local_infile = On” is remmed out in php.ini so I left it that way.
I just now went back and removed the semicolon from in front of “mysqli.allow_local_infile = On” just in case that would somehow be the problem. Then, stopped and started Apache and MySQL. Unfortunately that semicolon was not the problem.
I am going back to various backups to see if I introduced the “virus” in the last couple of weeks but cant find anything. I backup C:\xampp\ every night. I did notice that in 5.0.2 if I distribute all the payments of a check all at once I don’t notice any problem. The encounters are paid and the eob invoices are completed correctly. [BTW, I file all claims manually and input payments to oemr manually. I havn’t figured out yet how to create a X12 file that NC Medicaid likes. So I don’t use the Billing feature in oemr to create claims or get 837P files]. Anyway, If I quit the process after entering a few payments then go back to Fees:Batch Payment later and search for a check then continue distributing payments in the “Edit Payment” window, that is when it crashes. It’s like there is a disconnect between the Edit Payment window and the EOB Invoices, or whatever table provides the two their data.
I’ll continue to trouble shoot on this end and fill you in, maybe it will help you figure out what’s going on.
-Joel