SoDelayQueueSensor(3)

💖 SoDelayQueueSensor(3) — Library Functions Manual ✨

okay bestie, we're deep in the Library Functions Manual today and this one is a whole personality. let's get into it 🎀

---

🌸 NAME

SoDelayQueueSensor — the abstract base class for priority scheduled sensors. that's it, that's the vibe, and honestly? iconic. 💅

---

🦋 SYNOPSIS

#include <Inventor/sensors/SoDelayQueueSensor.h>

Inherits SoSensor. 🫶

Inherited by SoDataSensor, SoIdleSensor, and SoOneShotSensor — the whole girl group, no cap.

✨ Public Member Functions

SoDelayQueueSensor (void)
SoDelayQueueSensor (SoSensorCB *func, void *data)
virtual ~SoDelayQueueSensor (void)
void setPriority (uint32_t pri)
uint32_t getPriority (void) const
virtual void schedule (void)
virtual void unschedule (void)
virtual SbBool isScheduled (void) const
virtual SbBool isIdleOnly (void) const
virtual void trigger (void)

Public Member Functions inherited from SoSensor (the hand-me-downs but make them couture):

SoSensor (void)
SoSensor (SoSensorCB *func, void *data)
virtual ~SoSensor (void)
void setFunction (SoSensorCB *callbackfunction)
SoSensorCBPtr getFunction (void) const
void setData (void *callbackdata)
void * getData (void) const
void setNextInQueue (SoSensor *next)
SoSensor * getNextInQueue (void) const

⭐ Static Public Member Functions

static uint32_t getDefaultPriority (void)

Static Public Member Functions inherited from SoSensor:

static void initClass (void)

🎀 Protected Attributes

SbBool scheduled

Protected Attributes inherited from SoSensor:

SoSensorCB * func
void * funcData

---

💜 Detailed Description

SoDelayQueueSensor is the abstract base class for priority scheduled sensors. literally what it says on the tin, bestie.

So here's the tea: delay queue sensors get invoked upon various events not related to time occurrences. like, time is not the moment here. 🕐❌ wanna know which types of events can be surveilled by the builtin sensor types? go read the docs of the subclasses, because that's where that info lives. i don't make the rules.

The priority values can be used to queue events by their importance, so the sensors are triggered in the sequence you want. so you're basically the DJ and the priority is your setlist order. 🔥

The queue of delay sensors (i.e. instances of subclasses of SoDelayQueueSensor) will be processed as soon as either the run-time system is idle, or — if it is continually busy — they will be processed within a fixed amount of time. busy system still gets served, periodt.

That time interval is by default 1/12th of a second, but can be controlled with the SoSensorManager::setDelaySensorTimeout() interface. yes queen, you can tune it.

---

🧚 Constructor & Destructor Documentation

SoDelayQueueSensor::SoDelayQueueSensor (void )

Default constructor. the classic no-args entrance. 💅

Under the hood it references getDefaultPriority(), and scheduled.

SoDelayQueueSensor::SoDelayQueueSensor (SoSensorCB * func, void * data)

Constructor taking as arguments the sensor callback function and the userdata which will be passed the callback. so you hand it the function and the little bag of stuff to bring along. 🎒

See also: setFunction(), setData()

Under the hood it references SoSensor::func, getDefaultPriority(), and scheduled.

SoDelayQueueSensor::~SoDelayQueueSensor (void ) [virtual]

Destructor. the dramatic exit, as she deserves. 😭

Under the hood it references isScheduled(), and unschedule().

---

👑 Member Function Documentation

void SoDelayQueueSensor::setPriority (uint32_t pri)

Set this sensor's priority in the scheduling queue. When sensors are processed, high priority sensors will trigger before low priority sensors.

⚠️ IMPORTANT PLOT TWIST: a low number means a high priority. A sensor with priority 5 will trigger before a sensor with priority 6. yes, it's backwards from what your brain wants. it's giving chaos but it's actually fine.

Sensors with priority 0 have a special meaning in Coin/Inventor. They are called immediate sensors, and will trigger immediately after the current notification chain has finished. Priority 0 sensors should be used with care, since they might lead to bad performance if you do some processing in the sensor callback. so like, don't do a whole essay in there, bestie. 💀

See also: getPriority(), getDefaultPriority()

Under the hood it references isScheduled(), schedule(), and unschedule().

Referenced by SoWriteAction::beginTraversal().

uint32_t SoDelayQueueSensor::getPriority (void ) const

Returns sensor scheduling priority. the number, the whole number, nothing but the number. 💅

See also: setPriority(), getDefaultPriority()

Referenced by SoSensorManager::insertDelaySensor(), and SoDataSensor::notify().

uint32_t SoDelayQueueSensor::getDefaultPriority (void ) [static]

Returns the default scheduling priority value. The default sensor priority is 100. that's the factory setting, the original fit, the base model. ✨

See also: getPriority()

Referenced by SoVRMLScript::notify(), SoDelayQueueSensor(), and SoDelayQueueSensor(). (yep, twice — she said what she said.)

void SoDelayQueueSensor::schedule (void ) [virtual]

Put the sensor in the global delay queue. This means it will be triggered either when the CPU is idle, or when the specified delay queue time-out is reached. either way, she's showing up. 🦋

See also: SoDB::setDelaySensorTimeout(), unschedule(), isScheduled()

Implements SoSensor.

Under the hood it references SoDB::getSensorManager(), SoSensorManager::insertDelaySensor(), and scheduled.

Referenced by SoDataSensor::notify(), and setPriority().

void SoDelayQueueSensor::unschedule (void ) [virtual]

Remove sensor from the delay queue, without triggering it first. no callback, no goodbye, just gone. 🙈

See also: schedule(), isScheduled()

Implements SoSensor.

Under the hood it references SoDB::getSensorManager(), isScheduled(), SoDebugError::postWarning(), SoSensorManager::removeDelaySensor(), and scheduled.

Referenced by SoFieldSensor::detach(), SoPathSensor::detach(), setPriority(), and ~SoDelayQueueSensor().

SbBool SoDelayQueueSensor::isScheduled (void ) const [virtual]

Check if this sensor is scheduled for triggering. are we on the list or are we not on the list. 👀

See also: schedule(), unschedule()

Implements SoSensor.

Under the hood it references scheduled.

Referenced by SoFieldSensor::detach(), SoPathSensor::detach(), SoSceneManager::render(), setPriority(), unschedule(), and ~SoDelayQueueSensor().

SbBool SoDelayQueueSensor::isIdleOnly (void ) const [virtual]

Returns a flag indicating whether or not the sensor should only be triggered if the application is truly idle, and not when the delay queue is processed because of the delay queue timeout. so like — only when it's actually quiet, not when the timer just ran out. she has standards. 💅

See also: SoDB::setDelaySensorTimeout()

Referenced by SoSensorManager::processDelayQueue().

void SoDelayQueueSensor::trigger (void ) [virtual]

Trigger the sensor's callback function. the moment we've all been waiting for. 🔥

Reimplemented from SoSensor.

Reimplemented in SoDataSensor, and SoFieldSensor.

Under the hood it references scheduled, and SoSensor::trigger().

Referenced by SoSensorManager::processDelayQueue(), and SoDataSensor::trigger().

---

🍓 Member Data Documentation

SbBool SoDelayQueueSensor::scheduled [protected]

TRUE if the sensor is currently scheduled. that's the whole flag, she's either booked or she's not. 🎀

Referenced by isScheduled(), schedule(), SoDelayQueueSensor(), SoDelayQueueSensor(), trigger(), and unschedule().

---

💜 Author

Generated automatically by Doxygen for Coin from the source code. (yes, a robot wrote this, and honestly? she ate. 🤖✨)

---

and that's the whole page, bestie — this one's from Coin, Version 2.5.0, SoDelayQueueSensor(3), mwah, take care of her 🫶💖