TabPanelObject and GraphicsMode

It’s hard to know if this is a bug or a scenario in need of a guardrail.

I’ve got a form making a lot of use of TabPanelObjects and it’s working marvelously. One thing I run into continously is that while editing the form in GraphicsMode I often click on objects in the panel and edit them as well, sometimes extensively. Going back into data mode the panel performs according to the changes until I click to another panel. At that point, the edited panel reverts to the settings that were current the last time I edited the panel in its own separate window. Changes made in the “parent” form are lost.

Either that editing should be retained or not be permitted in a panel unless it is in the panel form itself.

Don’t do that!!

I mentioned this issue in slide #8 of the Tab Panels class. I would suggest leaving the main form in Data mode if possible, so that you aren’t tempted to do this.

The way that Tab Panels work is by copying the objects from the source form into the panel. Once they are copied, there is nothing to distinguish them from any other object. So Panorama has no way to know that it should prevent you from making changes – at that point it’s just an ordinary object as far as Panorama can tell.

Hmm, I suppose Panorama could turn on the “lock” attribute for the copied objects. Ok, I’ve submitted this as an issue.

I don’t think there is any downside to making this change, but if anyone sees a problem with this please speak up. Maybe it should be an option.

I never intend to but while working in GraphicsMode on the parent form, especially when testig aspects of a panel, it’s just too easy to slide in and start making tweaks there. The lock is a perfect solution.

I have done that more than once while working with forms containing Tab Panels. I would not want to have the objects in the Tab Panels locked since it would prevent the ability to change objects on the fly temporarily (bring to front, send to back, change colors or moving objects to new positions.) To me, ideally, you would get a warning if you started to edit the objects within a Tab Panels while in graphics mode - just enough of a heads-up to remind you to go to the source form to make the changes. I have more than one file using these methods already and they would break terribly if the Tab Panels objects were locked. My Wild Emojis file which I showed you some time ago is just one example that relies on this ability to a very large extent. What is nice about the current method is that you always start from the same condition no matter how the objects were altered on the fly the last time the database was used.

Possibly if Jim can add an option to not lock but with the default being locked, that would do it. As it is, it’s just to easy to do a lot of desired editing only to lose it.

I can actually live with it as-is, but I see it as a pitfall for many others down the road.

I agree with that and think if a simple alert would pop up and tell you that permanent changes must be made in the source form and not directly in the Tab Panel that most problems would be avoided.

This would be extremely difficult to do. And I think the UI would be horrible.

I will have to double check this, but I’m 99% sure that locking an object does not affect the ability of a procedure to modify the object, it only disables changes thru the user interface in graphics mode. I’m pretty sure statements like changeobject ignore the lock status.

I tried an example with a locked object and tried to use changeobject to change the color and the front to back order and neither change worked at all.

Well, I did say 99% and not 100%. I think this could possibly be considered a bug. It does show how the programming interface and the graphical user interface actually use the same underlying code.

Anyway, I promise any change I make here will not break Wild Emoji’s, though maybe you might have to click one check box.

Thank you! Now I"ll be able to sleep tonight.:relieved: