SoPathSensor(3)

πŸ“¦
version 4.0.10 Β· 4 versions
, in fedora 43, fedora 44

πŸ’– SoPathSensor πŸ’– (Coin manual, section 3 β€” bestie edition)

okay so like. hi. you opened the manual page for SoPathSensor from the Coin docs, section 3, and honestly? iconic of you. let's get into it. 🫢


πŸŽ€ NAME πŸŽ€

SoPathSensor β€” the class that detects changes to paths. that's the whole vibe, that's the job. ✨


🌈 SYNOPSIS 🌈

#include <Inventor/sensors/SoPathSensor.h>

Inherits SoDataSensor. yes bestie, it's giving inheritance. πŸ’…

πŸ¦‹ Public Types

  • enum TriggerFilter { PATH = 0x1, NODES = 0x2, PATH_AND_NODES = 0x3 }

🌸 Public Member Functions

  • SoPathSensor (void)
  • SoPathSensor (SoSensorCB *func, void *data)
  • virtual ~SoPathSensor (void)
  • void setTriggerFilter (const TriggerFilter type)
  • TriggerFilter getTriggerFilter (void) const
  • void attach (SoPath *path)
  • void detach (void)
  • SoPath * getAttachedPath (void) const

🧚 Public Member Functions inherited from SoDataSensor

  • SoDataSensor (void)
  • SoDataSensor (SoSensorCB *func, void *data)
  • virtual ~SoDataSensor (void)
  • void setDeleteCallback (SoSensorCB *function, void *data=NULL)
  • SoNode * getTriggerNode (void) const
  • SoField * getTriggerField (void) const
  • SoPath * getTriggerPath (void) const
  • void setTriggerPathFlag (SbBool flag)
  • SbBool getTriggerPathFlag (void) const
  • SoNotRec::OperationType getTriggerOperationType (void) const
  • int getTriggerIndex (void) const
  • int getTriggerFieldNumIndices (void) const
  • SoNode * getTriggerGroupChild (void) const
  • SoNode * getTriggerReplacedGroupChild (void) const
  • virtual void trigger (void)

πŸ’œ Public Member Functions inherited from SoDelayQueueSensor

  • 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

⭐ Public Member Functions inherited from SoSensor

  • 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

πŸ”₯ Protected Member Functions

  • virtual void notify (SoNotList *l)

πŸ“ Protected Member Functions inherited from SoDataSensor

  • void invokeDeleteCallback (void)

πŸ‘‘ Additional Inherited Members

Static Public Member Functions inherited from SoDelayQueueSensor:

  • static uint32_t getDefaultPriority (void)

Static Public Member Functions inherited from SoSensor:

  • static void initClass (void)

Protected Attributes inherited from SoDelayQueueSensor:

  • SbBool scheduled

Protected Attributes inherited from SoSensor:

  • SoSensorCB * func
  • void * funcData

🌟 Detailed Description 🌟

The SoPathSensor class detects changes to paths. periodt.

So here's the tea: if you need to know when a path changes β€” like, nodes in the path got removed, or new nodes got added β€” you use this sensor and it sends you a notification. main character behavior fr fr. πŸ’…

You can also use this sensor to catch when some node in the path gets changed. lowkey so useful.

An SoPathSensor can also act as a delete-callback thing all by itself, with no regular notification-based callback needed. just so we're clear though: that delete callback fires when the SoPath instance itself gets deleted β€” not for anything you'd be monitoring in a path. don't get it twisted bestie. 😭


πŸ¦‹ Member Enumeration Documentation πŸ¦‹

enum SoPathSensor::TriggerFilter

This is the trigger filter, and it's the thing that decides whether the sensor triggers on path changes, on changes to nodes in the path, or on both. vibe check time. ✨

Enumerator

  • PATH β€” triggers on path changes only.
  • NODES β€” triggers on node changes only. and by "nodes" we mean nodes in the path, or nodes affecting the nodes in the path (aka nodes that update the state and are left of the node in the path). iykyk.
  • PATH_AND_NODES β€” triggers on both path changes and node changes. the full package, no notes. πŸ’–

πŸŽ€ Constructor & Destructor Documentation πŸŽ€

SoPathSensor::SoPathSensor (void )

Default constructor, the classic. use setFunction() later to set up your callback function. no rush, bestie. 🫢

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

Constructor that takes the sensor callback function and the userdata that gets passed to the callback, as parameters.

See also: setFunction(), setData()

SoPathSensor::~SoPathSensor (void ) [virtual]

Destructor. say bye bestie. πŸ‘‹


✨ Member Function Documentation ✨

void SoPathSensor::setTriggerFilter (const TriggerFilter filter)

Sets the TriggerFilter for this sensor.

The default is PATH_AND_NODES.

Since: Coin 2.0

SoPathSensor::TriggerFilter SoPathSensor::getTriggerFilter (void ) const

Returns the TriggerFilter for this sensor. the getter to your setter, the duo we love to see. πŸ’…

Since: Coin 2.0

void SoPathSensor::attach (SoPath * path)

Attaches the sensor to a path. whenever that path changes, the sensor gets triggered and calls the callback function. it's literally watching. πŸ‘€

When the SoPath instance gets deleted, the sensor automatically detaches itself. self-care.

See also: detach()

void SoPathSensor::detach (void )

Detaches the sensor from the path. and bestie, listen β€” as long as an SoPathSensor is detached, it will never invoke its callback function. it's off duty. not coming to the phone. πŸ“΅

See also: attach()

SoPath * SoPathSensor::getAttachedPath (void ) const

Returns a pointer to the path that's connected to the sensor.

See also: attach(), detach()

void SoPathSensor::notify (SoNotList * l) [protected], [virtual]

Called from the entity we're monitoring, when it changes. like, it tells you. 🫢

If this is an immediate sensor, the field and node (if any) that caused the change get stored, and you can grab them with getTriggerField() and getTriggerNode(). And if the trigger path flag has been set, the path down to the node is also found and stored, so you can retrieve it later with getTriggerPath().

See also: setTriggerPathFlag()

Reimplemented from SoDataSensor.


πŸ’€ Author πŸ’€

Generated automatically by Doxygen for Coin from the source code. not a human, not a bestie, just a doc generator doing its thing.


okay so that's the whole page!! Version 4.0.10, Thu Jun 25 2026 00:00:00 β€” that's the version and timestamp, slay. now go attach a sensor and monitor some paths, you got this. πŸŽ€βœ¨πŸ’–

πŸ“¦ where this page comes from