SOLVED !!
To recap, if a certain form was open, a field was being cleared, and I was seeing four triggers in the log, every time I did an up or down record. (As mentioned above, to track this down I created a .ModifyRecord procedure, and had it zlogalways info(“trigger”).
I finally discovered a Text List form object that was trying to do a “look up” from a second database. Because that second file was not open, and in fact it didn’t even exist in the folder, an empty value would get stored into the field.
By “look up” what I actually mean is that the Text List object had the Value set to the field, and the Content Data database was set to a nonexistent file. By deleting that Text List object I got rid of two of the triggers I was seeing in the log.
BUT, I was still getting the remaining two triggers in the log, even after I had very laboriously deleted EVERY object from the form, a few at a time, until there was nothing left, a blank form. I would do a select all on the form and I saw nothing selected. I finally tried doing a select all on the form, and then the delete key, and the triggers went away. So there was something invisible on the form. How did I find it?
First I went back to editing the form and did an Undo, so that the invisible thing came back. Then I looked in the Objects panel, after doing a select all on the form, and a Text List object was indicated in the Objects panel, the right-most tab. But it was invisible. So, I went to the Measurements panel, and found that this text list object was zero pixels wide and zero pixels tall. Aha! I could then expand the size so that I could see the thing. And why was this object clearing my field? The Value setting was the field that was getting cleared, and the Content Data database was blank. Very similar to the first Text List object that was deleting data.
(After I finally found this thing, I reset the size to zero wide and zero tall, and I found that when I did a select all I could see a tiny dot, which got bigger when I zoomed in. I had tried zooming in before and never saw anything, but in any event, it’s extremely easy to miss something that tiny.)
I’m wondering if there might be some upgrades to Panorama that could help avoid this kind of problem.
-
Maybe a warning should appear whenever you edit a form that says: “You have one or more objects that are very tiny (less than 5 pixels wide and 5 pixels tall).” I assume it would be a bad practice in general to purposely create objects like that, and we would certainly want to know if they were created by accident. (I just chose 5 pixels as an example limit.) OR, much simpler, add an indicator in the tool bar that says how many objects are currently selected. I would immediately have been able to see that there was an object selected, even if I couldn’t see it. This would also help when you might have objects way over to the right side or way far down in the form, that you don’t see in the normal size of the form.
-
This one may be much trickier to circumvent, but it seems that a Text List set to a field, with either no database connected or a nonexistent database connected, will result in data loss just by scrolling through the database. Not sure how best to catch or avoid that problem.
Yes, the first TL object was showing a warning that the connected database was not open, but of course we still don’t want data being deleted just because a file got closed. And the 2nd TL object was so tiny no warning could be seen. But after I expanded the size, no warning was given anyway, since it was not connected to any file.
Note that this set of files was written by me many years ago for a client, who then modified it himself over the years, and is now having me convert it to Pan X, so that’s how strange things have crept in.