SODELAYQUEUESENSOR(3iv)

💖 SoDelayQueueSensor 💖

okay bestie, so this is the manual page for SoDelayQueueSensor from the 3IV manual set — yes, that manual, the one you keep opening in a terminal at 2am. it's the abstract base class for sensors that don't depend on time. no clocks, no ticking, just vibes and priority order. periodt.

---

🌈 INHERITS FROM 🌈

SoSensor > SoDelayQueueSensor

so like, it's a SoSensor at heart, but with a whole extra personality layer. the way inheritance works is giving glow-up 💅

---

✨ SYNOPSIS ✨

#include <Inventor/sensors/SoDelayQueueSensor.h>

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 🦋

okay so. delay queue sensors are a completely separate squad from timer queue sensors (peep SoTimerQueueSensor if you wanna meet them). what this class brings to the table is methods for setting the relative priorities of the sensors chillin' in the delay queue — and the rule is simple: sensors with higher priorities get triggered first. no cap. 👑

sensors with non-zero priorities get added to the delay queue when they're scheduled, and they all get processed once, in order, when the delay queue is processed. and when does that happen? normally as part of your program's main loop (check out SoXt::mainLoop() or SoDB::doSelect()). typically the delay queue gets processed whenever there are no events waiting to be distributed and no timer queue sensors waiting to be triggered. but bestie, there's also a timeout on the delay queue, so that delay queue sensors actually fire even if events or timer sensors are always hanging around waiting — see SoDB::setDelaySensorTimeout(). the queue said "i will not be ignored." 💀

now. sensors with priority 0 are the special ones, the main characters 🎀. priority 0 sensors get triggered almost immediately after they're scheduled, before the program even returns to the main loop. BUT — and this is the important part — they're not necessarily triggered immediately when scheduled. if they get scheduled as part of the evaluation of a field connection network, they may not be triggered until that network evaluation is complete. also, if a priority 0 sensor is scheduled inside the callback method of another priority 0 sensor, it won't be triggered until that callback method is done. and one more thing, heads up: if more than one priority 0 sensor is scheduled, the order in which they fire is undefined. chaos, honestly. 🙈

---

💅 METHODS 💅

• void setPriority(uint32_t pri)
• uint32_t getPriority()

sets / gets the priority of the sensor. you can change priorities whenever you want, any time, no rules. BUT if you change the priority to zero and it's already scheduled, the sensor gets immediately triggered and removed from the queue. so like, know that before you do it. 🫶

• static uint32_t getDefaultPriority()

returns the default delay queue sensor priority, which is 100. that's the baseline. the factory setting. the no-makeup selfie of priorities. ✨

• virtual void schedule()

if this sensor's priority is non-zero, it adds this sensor to the list of delay queue sensors ready to be triggered. it's a cute lil way of making a sensor fire without changing the thing it's sensing. iconic behavior honestly.

calling schedule() inside the callback function makes the sensor get called repeatedly. and because sensors are processed only once every time the delay queue is processed (even if they reschedule themselves), timers and events will still get processed. balance restored. 🌸

⚠️ do NOT do this with a priority zero sensor, because an infinite loop will result. like, actual infinite loop. we do not stan. 💀

• virtual void unschedule()

if this sensor is scheduled, it gets removed from the delay queue so it will not be triggered. ghosted. 👻

• virtual SbBool isScheduled()

returns TRUE if this sensor has been scheduled and is waiting in the delay queue to be triggered. note that sensors are removed from the queue before their callback function is triggered — so by the time the callback runs, the queue has already moved on. glow-up timing. 💖

---

👀 SEE ALSO 👀

SoTimerQueueSensor, SoDataSensor, SoFieldSensor, SoIdleSensor, SoOneShotSensor, SoNodeSensor, SoPathSensor, SoSensorManager

---

and that's the whole page, bestie!! 🎀 it's from the SoDelayQueueSensor(3IV) manual page, and the footer was just SoDelayQueueSensor(3IV)() with no version or date filled in — an empty slot, a mystery, a little enigma for us to ponder. go forth and schedule responsibly. 💜🦋✨