Persistent dockable panel issue with 4.1 (1685)

[flashk]

Hi,

I'm updating a plugin to work with 4.1 and ran across a small issue with persistent dockable panels. Within the OnStartup function of my auto script, I create a persistent dockable panel and perform certain initialization only if the panel is visible (i.e. Panel.Common.Visible). In 4.1, the Visible attribute is always true during startup, even if it was previously closed. However, after the startup function is called the Visible attribute is restored to the correct value. I don't recall having this issue with 4.0 and earlier, but I'm not sure exactly which version this problem started happening.

Let me know if you would like me to provide more information.

[Ludek]

Hi, could you attach or refer to an example script demonstrating this?

[gege]

I think flashk is reffering to his (great) add-on MonkeyFlow. I have seen this behavior in MonkeyFlow and also other scripts using persistent panels.
Here is a screenshot to illustrate:



SCripts shown in screenshot above are: MonkeyFlow; Lyrics and Comment Viewer; WebSearch Panels.

[Ludek]

Yes, I think I see it now.

In 4.0.7:
- if I start MM when MonkeyFlow is disabled, the menu View -> [ ] Monkey Flow is correctly unchecked and checking it correctly initializes MonkeyFlow

In 4.1.0
- if I start MM when MonkeyFlow is disabled, the menu View -> [x] Monkey Flow is incorrectly checked and unchecking it has no effect and empty MonkeyFlow window is show, user needs to uncheck/check it again to properly initialize MonkeyFlow

To be fixed as: http://www.ventismedia.com/mantis/view.php?id=11680

[gege]

In 4.1.0
- if I start MM when MonkeyFlow is disabled, the menu View -> [x] Monkey Flow is incorrectly checked and unchecking it has no effect and empty MonkeyFlow window is show, user needs to uncheck/check it again to properly initialize MonkeyFlow

Yes, this is the same behavior I get.
Using Process Explorer, I discovered that, in fact, starting MM when MonkeyFlow is disabled, the MonkeyFlow processes are started, although they shouldn't!

[Ludek]

Fixed in build 1686 as http://www.ventismedia.com/mantis/view.php?id=11680

[flashk]

Great, thanks Ludek and gege!