What effects does setwavelock for a wave have other than causing wavelock to return saying the lock is held?
Is there any purpose in using this along with wave reference counting and OBJINUSE?
You would use it if you want to prevent modification of the wave by a user any time in the future. It's not so much used to say 'hold on I'm not done with this wave yet, wait your turn', but to say 'no one can modify this wave ever unless they ask nicely, even if I'm not using it' (a user can just unlock the wave if they want to modify/kill it, but the presence of the lock should be a signal that maybe they aren't meant to do this). Wave reference counting is internal, and done automatically. SetWaveLock does keep the reference count above zero, but I think it's more about giving the user some control over wave lifetime/security.
The XOP SetWaveLock callback does the same thing as the SetWaveLock Igor command. SetWaveLock was created to provide a way to prevent the user from killing a wave. An example use case is a wave used by a background task. However, SetWaveLock is not much used. I don't think SetWaveLock affects the wave's reference count.
OBJINUSE was created before SetWaveLock existed to provide an XOP a way to prevent the user from killing a wave that the XOP uses intermittently, for example from an IDLE message, which is analogous to the background task use case. OJBINUSE does not affect the wave's reference count.
I recommend using OJBINUSE from an XOP rather than SetWaveLock as the user can unlock any wave at any time but cannot pull the rug out from under OJBINUSE.
Reference counting was created much later than OBJINUSE and SetWaveLock. I think Larry created it when he created wave waves (waves that hold wave references) to prevent a wave reference held in a wave from becoming stale. A wave with a non-zero reference count can be killed but it is not deleted until the reference count goes to zero. As explained in Chapter 7 of the XOP Toolkit manual under "Killing Versus Deleting a Wave", killing a wave means removing it from the list of accessible waves whereas deleting a wave means freeing the memory occupied by the wave. Deferring the deletion of the wave until the reference count reaches 0 prevents crashes if something, such as a wave wave, is holding a reference to a wave that has been killed.
You would use it if you want to prevent modification of the wave by a user any time in the future. It's not so much used to say 'hold on I'm not done with this wave yet, wait your turn', but to say 'no one can modify this wave ever unless they ask nicely, even if I'm not using it' (a user can just unlock the wave if they want to modify/kill it, but the presence of the lock should be a signal that maybe they aren't meant to do this). Wave reference counting is internal, and done automatically. SetWaveLock does keep the reference count above zero, but I think it's more about giving the user some control over wave lifetime/security.
May 9, 2024 at 06:01 pm - Permalink
The XOP SetWaveLock callback does the same thing as the SetWaveLock Igor command. SetWaveLock was created to provide a way to prevent the user from killing a wave. An example use case is a wave used by a background task. However, SetWaveLock is not much used. I don't think SetWaveLock affects the wave's reference count.
OBJINUSE was created before SetWaveLock existed to provide an XOP a way to prevent the user from killing a wave that the XOP uses intermittently, for example from an IDLE message, which is analogous to the background task use case. OJBINUSE does not affect the wave's reference count.
I recommend using OJBINUSE from an XOP rather than SetWaveLock as the user can unlock any wave at any time but cannot pull the rug out from under OJBINUSE.
Reference counting was created much later than OBJINUSE and SetWaveLock. I think Larry created it when he created wave waves (waves that hold wave references) to prevent a wave reference held in a wave from becoming stale. A wave with a non-zero reference count can be killed but it is not deleted until the reference count goes to zero. As explained in Chapter 7 of the XOP Toolkit manual under "Killing Versus Deleting a Wave", killing a wave means removing it from the list of accessible waves whereas deleting a wave means freeing the memory occupied by the wave. Deferring the deletion of the wave until the reference count reaches 0 prevents crashes if something, such as a wave wave, is holding a reference to a wave that has been killed.
May 11, 2024 at 05:05 pm - Permalink