Warning if user tries to edit a locked text display object

Panorama X
1

Sometimes, like this morning, I have edited a text display object, then found that the edits are not appearing in the form. I assume I made a mistake and edit it again. And the change still doesn’t appear. Eventually it dawns on me that it must be a locked object. Wouldn’t it be nice if as soon as I try to edit a locked text display object that I get some warning, such as a sound or a dialog?

It doesn’t seem fair that Jim should do any work to accommodate my mental lapses, but the net benefit to humanity might be considerable, and more people might crave Panorama, depending on how many others make this mistake from time to time.

2

Yes, I agree, that is a minor bug.

3

I’m not sure I would go as far as describing that as a bug, although in my case I keep all objects locked unless and until I’m actually editing one of them, because otherwise it’s so easy to move one inadvertently. Therefore it has become a reflex for me to unlock one before doing anything to it.

What I might describe as a bug is if you edit the blueprint of a form containing any locked objects (or, in my case, usually all locked objects) then click ‘Update form’ to update the changes, a new object will be created for any locked object. Thus any objects that were locked before editing the blueprint will be doubled. Any objects that were unchanged by the edit will be exact duplicates, except that the original is locked and the new copy is unlocked. If editing the blueprint caused a change to an object the original, locked object will still be there with the modified version, unlocked, on top.

If the form contains a large number of objects and the problem is not noticed immediately, it can be hard work to put it right!

4

I wouldn’t call it a bug either. I was just thinking that a warning could be added for people like me. It would be a nice touch.

5

in my case I keep all objects locked unless and until I’m actually editing one of them

You folks always find a new way to amaze me with how you use Panorama. I’m not saying that what you’re doing is wrong in any way - it’s just not something that would ever occur to me to do.

then click ‘Update form’ to update the changes

Here’s the code that does this:

if dlgResult="Ok"
    targetBluePrint = grabfilevariable(info("proceduredatabase"), "bluePrint")
    startgraphicschange "Blueprint Modification"
    selectallobjects
    deleteselectedobjects
    execute {local targetFormName targetFormName=}+quoted(targetForm)+{ shortcall restoreFormFromBlueprint rtn}+cr()+targetBluePrint
endif

So your bug occurs because deleteselectedobjects won’t delete the locked objects. I think the best solution would be to create a new statement that deletes all objects whether they are locked or not, and use that. However, that would bring up another point, which is that I think that blueprints don’t include whether or not each object is locked. So if all objects were locked, and you updated using a blueprint, now all objects would be unlocked.