Sounds like your file may be damaged. Try recovering it to see if any problems get found and fixed and test the recovered copy to see if it behaves differently. If it turns out your file was damaged, best practice is to replace it with an undamaged back up copy instead of using the recovered copy.
If you want to enagle a scroll bar on a text field without allowing it to editable, you can set up a calculation field that copies the value of this field and put it on your layout with the scroll bar option selected--though better design would be to break up your log entries into separate records in a related table instead putting so much data into the field that you need to scroll it.
No problems detected.
0 Recover built a new database without detecting any problems. It would be safest to copy only the most recent work from the recovered file into a backup copy of the original file, instead of using the recovered file going forward.
0 Note: Recover only checks the data blocks of the file and generates a new file from that data. The Consistency Check checks all blocks of the file, and may find more problems in the original file than Recover does.
0 File blocks: scanned and rebuilt 1055 block(s), dropped 0 invalid data block(s)
0 Schema: scanned fields and tables; no problems found
0 Structure: scanned; 0 item(s) modified
0 File size after recovery is 4345856 bytes
But did you test the recovered copy? Sometimes it "fixes" a problem without reporting it--particularly if rebuilding an index solved the problem.
if a sort or search has been performed and a new record is created without unsorting the records or refreshing the records (show all records), records get created without coresponding related records which should be created by script. This results in fields that are usually are auto-filled are given a null value.
My bad! Never switched back to browse mode on one of my my layouts and tried creating and commiting an new record.
Concerning the frozen windows, I have tried testing the the recovery file and can't get it to crash out. So seems to be fixed. However this problem only happens once in a blue moon anyway.
Another point is that I'm developing on a windows machine and have never experienced the problem.
The solution is to be run and is being tested on a mac. It is this machine where the crashes have occured so far. I am developing in FM Pro Advanced 10 but the solution is being tested in FM Pro 11.
You might save a clone of your original file and import your data into it and test. If a rebuilt index is fixing the problem, this file, which hasn't been recovered, may also work for you.