# First user-based control locking mechanism \[Ignition 8\] **URL:** \ **Category:** Ignition\ **Tags:** perspective\ **Created:** [October 9, 2024, 2:52pm UTC](https://forum.inductiveautomation.com/t/first-user-based-control-locking-mechanism-ignition-8/97025 "2024-10-09T14:52:46Z")\ **Posts on this page:** 1\ **Showing post:** 2
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [October 9, 2024, 3:18pm UTC](https://forum.inductiveautomation.com/t/first-user-based-control-locking-mechanism-ignition-8/97025/2 "2024-10-09T15:18:25Z")
See this similar recent discussion: > [@Closing Vision Window instance on separate clients](https://forum.inductiveautomation.com/t/closing-vision-window-instance-on-separate-clients/96905/2): > > This is extremely difficult and fragile, as described. Instead, consider allowing the window to always be opened, but all of its features disabled by default. Then, set up a couple memory tags. One to hold the client ID of the client "in control", and a second to contain a datetime timeout value. Enable the controls on the window while the particular client's ID matches and the timeout timestamp is greater than now(). Use a button on the window to "claim" control by writing the current clie… That one is for Vision, but a similar technique would be reasonable for Perspective (using session ID instead of client ID). One big caveat: If your application needs any kind of jog functionality, **Perspective** cannot do it. (It cannot ensure a jog command turns off when a button is released.) It is non-trivial to make reliable in **Vision** , but is at least _ **possible** _. Search this forum for "Momentary" for detailed discussions of **why**. (Some quite heated.) --- _[View the full topic](https://forum.inductiveautomation.com/t/first-user-based-control-locking-mechanism-ignition-8/97025)._