SOONESHOTSENSOR(3iv)
β¨ SoOneShotSensor β¨
okay bestie, gather round, because today we're learning about SoOneShotSensor from the 3IV manual π (yes that's the manual name, she's fancy, we love her)
π¦ INHERITS FROM π¦
SoSensor > SoDelayQueueSensor > SoOneShotSensor
it's giving family tree moment, the lineage is immaculate π
πΈ SYNOPSIS πΈ
#include <Inventor/sensors/SoOneShotSensor.h>
π Methods from class SoOneShotSensor:
SoOneShotSensor()
SoOneShotSensor(SoSensorCB *func, void *data)
~SoOneShotSensor()
π Methods from class SoDelayQueueSensor:
void setPriority(uint32_t pri)
uint32_t getPriority()
static uint32_t getDefaultPriority()
virtual void schedule()
virtual void unschedule()
virtual SbBool isScheduled()
π Methods from class SoSensor:
void setFunction(SoSensorCB *callbackFunction)
SoSensorCB * getFunction() const
void setData(void *callbackData)
void * getData() const
π DESCRIPTION π
so a one-shot sensor is literally the "do it once and dip" queen β¨ She gets triggered once after you schedule her, when the delay queue gets processed. periodt.
and here's the iconic part: like all delay queue sensors, one-shot sensors with a non-zero priority are just added to the delay queue when scheduled. If you schedule them again before the delay queue is processed? nothing happens π«Ά and they are guaranteed to be called only once when the delay queue is processed. no cap.
ngl the classic example: a one-shot sensor whose callback function redraws the scene might get scheduled whenever the scene graph changes and whenever a window-system event reporting that the window changed size occurs. By using a one-shot, the scene will only be redrawn once even if a window-changed-size event occurs just after the scene graph is modified (or if several window-changed-size events occur in a row). it's giving efficiency, it's giving taste π
calling schedule() inside the callback function is a genuinely useful way of getting something to happen repeatedly as often as possible, while still handling events and timeouts. main character loop energy πβ¨
β οΈ okay so, a priority 0 one-shot sensor isn't very useful, bestie. scheduling it is exactly the same as directly calling its callback function. like why are you even here at that point π
π₯ METHODS π₯
SoOneShotSensor()SoOneShotSensor(SoSensorCB *func, void *data)β creation methods π the second one takes the callback function and the data to be called when the sensor is triggered.~SoOneShotSensor()β destroys the sensor, freeing up any memory associated with it after unscheduling it. she cleans up after herself, we stan π§
π SEE ALSO π
SoIdleSensor, SoDelayQueueSensor
go read those too bestie, iykyk π
and that's the whole vibe, fr fr π this was SoOneShotSensor from the SoOneShotSensor(3IV)() page β that's the source/version + date footer right there, consider yourself signed off on π mwah, slay, go schedule something (once) β¨
π¦ where this page comes from
- debian bookworm: inventor-doc 2.1.5-10+dfsg-2 Β· LGPL-2.0-or-later
- debian trixie: inventor-doc 2.1.6+ds-2 Β· LGPL-2.0-or-later
- ubuntu jammy: inventor-doc 2.1.5-10-24
- ubuntu noble: inventor-doc 2.1.5-10+dfsg-2.1build2 Β· LGPL-2.0-or-later
- ubuntu questing: inventor-doc 2.1.6+ds-2
- ubuntu resolute: inventor-doc 2.1.6.1+ds-1 Β· LGPL-2.0-or-later
- ubuntu stonking: inventor-doc 2.1.6.1+ds-1 Β· LGPL-2.0-or-later
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms