SODATASENSOR(3iv)

✨ SoDataSensor ✨

okay bestie, welcome to the SoDataSensor page from the 3IV manual 🎀 this one's an abstract base class and it's literally the blueprint for every sensor that glues itself to a part of your scene graph and yells at you when that thing changes. main character energy fr 💅

---

🌸 NAME 🌸

SoDataSensor — the abstract base class for sensors attached to parts of a scene. like, the concept of a sensor, not the sensor itself, iykyk 🦋

---

🧬 INHERITS FROM 🧬

SoSensor > SoDelayQueueSensor > SoDataSensor

it's giving family tree. three generations deep, all iconic 👑

---

📜 SYNOPSIS 📜

#include <Inventor/sensors/SoDataSensor.h>

methods that come from SoDataSensor itself:

void                setDeleteCallback(SoSensorCB *function, void *data)
SoNode *            getTriggerNode() const
SoField *           getTriggerField() const
SoPath *            getTriggerPath() const
void                setTriggerPathFlag(SbBool flag)
SbBool              getTriggerPathFlag() const

methods it inherits from SoDelayQueueSensor:

void                setPriority(uint32_t pri)
uint32_t            getPriority()
static uint32_t     getDefaultPriority()
virtual void        schedule()
virtual void        unschedule()
virtual SbBool      isScheduled()

methods it inherits from SoSensor:

void                setFunction(SoSensorCB *callbackFunction)
SoSensorCB *        getFunction() const
void                setData(void *callbackData)
void *              getData() const

---

💫 DESCRIPTION 💫

so data sensors detect changes to scene graph objects — that's paths, nodes, or fields — and then they trigger their callback function the moment that object changes. that's the whole vibe. no cap 🫶

data sensors also hand you a delete callback, which gets called just before the object your sensor is attached to gets deleted. cute, right?

⚠️ but bestie listen — that callback should not try to modify the object in any way. like, none. because core dumps may result 😭💀 do not test this.

and then — priority zero data sensors also come with methods you can call inside your callback function to figure out exactly which node, field, or path set off the sensor. detective mode fr 🔍✨

---

🛠️ METHODS 🛠️

void setDeleteCallback(SoSensorCB *function, void *data)

sets a callback that'll be called when the object your sensor is sensing gets deleted. it's the goodbye text of callbacks 🥲

---

SoNode * getTriggerNode() const

SoField * getTriggerField() const

if this is a priority 0 data sensor, it returns the node/field that got modified and caused this sensor to trigger. slay.

it returns NULL if the sensor wasn't triggered because a node/field changed — for example, if schedule() was called on the sensor instead — or if this sensor isn't a priority 0 sensor at all. 🙈

heads up though: one single change to the scene graph can cause multiple nodes or fields to get modified (field-to-field connections said "not me minding my business"), so the node or field you get back might not be the only one that changed. ⭐

---

SoPath * getTriggerPath() const

void setTriggerPathFlag(SbBool flag)

SbBool getTriggerPathFlag() const

if this is a priority 0 data sensor, this returns a path to the node that caused your sensor to trigger. 🦋

but here's the tea — recreating that path to the node that changed is relatively expensive, so you have to call setTriggerPathFlag(TRUE) before the sensor is scheduled. if you don't call it, or if the sensor wasn't triggered because a node changed, this returns NULL. and it also returns NULL if this isn't a priority 0 sensor. so many NULLs, so little time 💀

---

👀 SEE ALSO 👀

SoNodeSensor, SoPathSensor, SoFieldSensor, SoDelayQueueSensor

go read those next bestie, they're all in their own lane and they all ate 🌈

---

that's the whole page!! ty for coming to my ted talk, this was SoDataSensor(3IV) and yes the manual name is doing a little double appearance moment at the bottom like a signature 💖 mwah, go forth and sensor responsibly, ily 🎀✨