If Panorama 6, LockFields could be used to prevent editing of a record. There doesn’t appear to be a similar command in Panorama X.
In looking for an alternative, I tried forcelockrecord but that single command is met with an error message: Cannot set parameter value because parameter 1 does not exist.
I just tried forcelockrecord and forceunlockrecord; both worked as intended.
Tom, Jim is referring to editing a field on a form, not locking a record. I have run into this as well. It’s funky, but I put a button over the field(s) and put a message like “This field(s) can not be edited.” in the procedure tab.
Hmmm, before posting I checked to be sure that no .ModifyRecord or .CurrentRecord existed so I don’t know where the error is coming from.
The database is not shared, if that matters, and I tried forceunlockrecord which did not get an error.
Both the forcelockrecord and forceunlockrecord have this bit of code in their procedure:
Now since neither statement uses any parameters they should both display an error if you are not connected to the server. I believe this use of a non-existing parameter is a bug in the two statements and should probably be replaced with a warning instead.
Thanks Gary, clearly it requires that the database be shared. So my quest for a replacement for LockFields will remain unfullfilled.
I’m confused. Are trying to prevent editing fields in a form or editing a record? Forcelockrecord locks a record until it times out. LockFields locks individual or multiple fields in a record.
I have circumstances in which a record is not to be edited. LockFields was the exact solution and could be turned on or off as needed…lockfields dbinfo(“Fields”,"") to lock them all or lockfields “” to unlock them.
By the documentation it seemed like forcelockrecord resulted in being the equivalent of lockfields dbinfo(“Fields”,"") although its intent is to simulate the record lock that occurs when another user is editing the record.
lockfields would also eliminate the need for your “funky” solution to locking fields.
I am confused. I do not see a command LockFields in the Help. Is this a command that is not documented?
This is a Panorama 6 statement that is not available in Panorama X.
Agreed, but it is no longer available.
I’m afraid this entire discussion is based on a false premise. There has never been any feature that prevents editing of a record, with the lockfields statement or any other way.
The lockfields statement did just what the name says – it prevented the editing of entire fields. Those fields would be “locked” for all records, not for an individual record. (Note that this use of the word “lock” is non-standard compared to all other uses of that term in Panorama, see my PS at the bottom of this post.)
This statement was a hack that I put together for the Track Magic project. Probably none of you remember that, but it was a tool written in Panorama to assist with working on Ruby on Rails. One component of Track Magic was that it allowed a Panorama database to be synchronized with an SQL Rails database. This required two extra fields in the database, which were managed by the Track Magic code. If the contents of these fields was changed manually, synchronization would be broken, so lockfields was implemented so that these fields could not be manually disturbed even if the data sheet was open. What I really wanted to do was add a field property that prevented the field from being edited in the data sheet. But the data structures in Panorama 6 made it nearly impossible to add a new field property, and since this was a small side project I came up with the relatively quick and dirty hack of the lockfields statement. If you read the old documentation you can see the compromises in this statement – most notably that it doesn’t account for changes in the database structure. The recommended use case was to use the .Initialize statement to set it up each time the database opens. The intent was that you would set it up once when the database opened, and never use this statement again unless you added or deleted a field, or rearranged fields. (If you did rearrange fields and didn’t use lockfields again, the wrong fields would be locked – as I said, it was a hack.)
The Track Magic project never went anywhere, so I didn’t need this feature any more. But I still thought it was a good idea, so in Panorama X I implemented it the correct way, as a field property. There’s no programming required, just un-check the Editable option.
This property can also be accessed and modified in code, using the EDITABLEINDATASHEET property.
Note that this option only affects the data sheet. The documentation for the old LockFields statement claims that it affects both the data sheet and forms, but I’m pretty sure that is a documentation error. Since this feature was really intended to permanently lock out a field, the thought was the the form would be designed to take care of that (either by not including the field or using a display object instead of an editor object).
Over the years, it has been suggested more than once that Panorama include a feature to make individual records non-editable. For example you might want to make it so that an invoice can’t be modified once it has been printed. However, this is a very tricky feature to implement and I’ve never really figured out a good way to do it. I understand the appeal of this concept, and if some point I figure out a reasonable way to implement it, I will do it.
P.S. The choice of the name lockfields was probably unfortunate. It probably should have been something like DisableEditingOfFields. Panorama (and other databases) already used the term “lock” for something else (preventing multiple users from editing the same data simultaneously), so this name choice could cause confusion, as it did today.
Actually it did lock editing in forms too. That’s where I put it to use. The fact that it locked all records didn’t matter because only one record was accessible in the forms where I applied it. And it was easy to turn it on or off via a simple procedure as the database was in use. So intended or not, it was a perfect solution and worked reliably on a daily basis within a set of shared databases over a period of years.
Separate read and write forms can be created, but it was really, really nice to just have a lock/unlock button on a form so that editing critical data was clearly a deliberate intent.
That how it was used here as well.
Interesting. I have no recollection of doing that.
Since I have no memory of it, I just tried it to see how it works. It appears to cause clicks on Text Editor and Data Cells to be completely ignored (if they are linked to the locked records). It also prevents tabbing into a “locked” field (I thought I might have ignored that, but I didn’t, good for me). But since it is a “hack” feature, it’s not quite complete, it doesn’t prevent use of data buttons, pop-up menus or list objects that are linked to a locked field.
I think what you are suggesting is that you usually keep all the fields locked, then require users to explicitly press a button before editing. Then perhaps you automatically re-lock after a timer, or when the current record changes. I have a thought for how this could be somewhat reasonably done, which I’ve written up for future consideration.
I’m always pleased when you have a thought… oh, wait, I know that to be never ending. Future consideration is great though. I’ll take it.
