MGI Panel Manager Persistent Window Position Race Condition

[rwunderl]

I don't know how many people use the MGI Panel Manager for their panel management needs, but I've recently started using it heavily and very much like it. However, I almost immediately ran into an issue using the Persistent panel position type.

I have several Window panels up at the same time, and they all get closed at the same time. They all have their Window Position object set to a Persistent Position child class. This executes a Pre-Close Action VI when the panel is closed via the Window:Close method. The Persistent Position:Pre-Close Action method opens an ini file to save the window bounds as a string under a "unique" key name in the ini file. (I say "unique" because the ID can be provided by the user and there is no internal check to see if it is truly unique.) The "Window Positions.ini" file is created automatically if it does not already exist, the position key for the panel is stored, and the changes are saved.

This all appears to work nicely iff the Window Positions.ini file already exists. In my example, I have three panels running that use the Persistent Position class. All of these VI's are called asynchronously with reentrancy. Let's call them A, B, and C. A and B are the same VI; C is a different VI but very similar code. I close them all "simultaneously" by sending them all a user event (in a For Loop that does nothing but use Generate User Event) that triggers the Close method. The Window Positions.ini file is created as expected, but only contains the position keys for panels A and C. If I run and stop the application again, the Window Positions file contains the positions of A, B, and C as expected (and the A and C positions do change if the windows were moved).

So the issue seems to be that all of these functions are calling the Pre-Close Action method that opens the Window Positions.ini file at the same time. Unfortunately, the Pre-Close Action method is set to Shared clone reentrant execution. This allows it to simultaneously open a reference to the same ini file.

The fix for me was to change the reentrancy setting of the Pre-Close Action method to Non-reentrant execution.

Just wanted to put this out there in case anyone else has the same issue. Hope it helps.

[prettypwnie · Accepted solution]

Thank you for reporting this. It should be fixed in version 2.0.3 now.

In the future, you can always submit additional issues on the gitlab page, and even make a merge request with your own fix: https://gitlab.com/mgi/gpm-packages/panel-manager/-/blob/master/CONTRIBUTING.md

[rwunderl]

Thank you for the fast response and the link. I did not know about the GitLab page. I had just used the VI Package Manager to get the "latest" package, which is only version 1.0.1.4 (dated 3/30/2018). Not sure how many versions back that really is or what the other code differences may be. The LabVIEW Tools Network and your website (which also points to the Tools Network) both point to VIPM as the source for the code. Perhaps MGI could advertise the GitLab page so people would benefit from having the latest bug fixes.

Still, kudos for the Pre-Hide method. I had not exposed this weakness yet, but it would have come up soon enough as I do hide panels when they are not in use (but still running in the background).

[prettypwnie]

Oh right, I forgot about VIPM hehe, I usually use GPM... But you're right we should update the VIPM package at some point, and make the gitlab page more visible.

[rwunderl]

Actually, it would make more sense for you to make the GPM page more visible (on your own site). I didn't know about that either. Sounds interesting.

I've spent years not liking VIPM because of the global installs (even if per LabVIEW version), breaking older projects, and transporting the code to other machines just to find missing dependencies. What a hassle.

So I just unzip the .vipm files and add the content directly into my projects. Sounds like that's exactly what GPM does for a living. I'll have a look. Thanks for the tip.

[prettypwnie]

Oh yeah dude if you normally move the VIPM code into your project manually, you will LOVE GPM!!