Marking field as not editable in data sheet does not prevent pasting

Panorama X
1

When I do a search (either “Find” or “Select”) in the data sheet, I always use the keyboard. I realized that when I do a lot of searches in a row, I sometimes make a mistake and, instead of command-F, I type command-V, which pastes the contents of the clipboard into the selected field. Which is bad. So I was happy to find a way to lock the field, by removing the checkmark before “Editable” in the Properties pane. I checked and, indeed, I couldn’t type into that field. But later I noticed that, even if I couldn’t type into it, I could still paste into it. It was not locked. It wasn’t actually protected.

Is this normal? A non-editable field should, in my opinion, be totally protected from any change, be it by typing or pasting.

Is there a way to temporarily really protect a field from any change?

Using Panorama X Pro 10.1.1 with MacOS High Sierra 10.13.6

Ellen

2

Well, I have found a somewhat involved way to protect the contents of the field from being pasted over. My example uses MyField as the name of the field to be protected.

  1. Create a new field named dupMyField
  2. Now fill this field with the contents of the field you want to protect (MyField in this example)
    – Use the Morph tool with Morph Current Field… using the formula MyField
  3. In the field Properties panel for MyField under the Code tab place MyField=dupMyField
  4. From the Field menu choose Hide Current Field

Now you can no longer paste into MyField and if you need to change the value of MyField programmatically you will also have to change the value of dupMyField to match. The new field must be hidden or you could accidentally paste a value into that as well. Hmm, I guess you could keep that field showing as long as you enter the same type of code into its Code panel as well. That way one field will protect the other - but why not hide it?

I can not guarantee there is not a simpler way to accomplish this.

3

Thanks, Gary, that is probably a good way to protect a field at least semi-permanently. I’ll try it out next time I do a lot of work on the database.

I really don’t get the reasoning behind the way “non-editable” works. My first reaction was that I had missed something, my next one was to wonder if it was a bug or a feature :slight_smile: If it’s actually a feature, I’m curious about its purpose.

4

That seems like a bug. I’ve added it to the issue tracker.

5

Great, Jim. I’m always happy to find bugs, especially ones that will be fixed. Thanks.