Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages


home | help
SoDelayQueueSensor(3IV)()			     SoDelayQueueSensor(3IV)()

       SoDelayQueueSensor  -- abstract base class for sensors not dependent on

       SoSensor	> SoDelayQueueSensor

       #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

       Delay queue sensors are separate	from  timer  queue  sensors  (see  So-
       TimerQueueSensor)  and provide methods for setting the relative priori-
       ties of the sensors in the delay	queue (sensors with higher  priorities
       will be triggered first).

       Sensors	with  non-zero	priorities  are	 added to the delay queue when
       scheduled, and are all processed	once, in order,	when the  delay	 queue
       is  processed,  which  normally	happens	as part	of your	program's main
       loop (see SoXt::mainLoop() or SoDB::doSelect()).	Typically,  the	 delay
       queue  is processed whenever there are no events	waiting	to be distrib-
       uted and	there are no timer queue sensors waiting to be triggered.  The
       delay  queue  also has a	timeout	to ensure that delay queue sensors are
       triggered even if there are always events or timer sensors waiting; see

       Sensors	with  priority 0 are treated specially.	Priority 0 sensors are
       triggered almost	immediately after they are scheduled, before the  pro-
       gram  returns  to the main loop.	Priority 0 sensors are not necessarily
       triggered immediately when they are scheduled,  however;	 if  they  are
       scheduled  as part of the evaluation of a field connection network they
       may not be triggered until the evaluation of the	network	 is  complete.
       Also, if	a priority 0 sensor is scheduled within	the callback method of
       another priority	0 sensor, it will not be triggered until the  callback
       method  is  complete (also note that if more than one priority 0	sensor
       is scheduled, the order in which	they fire is undefined).

     void		 setPriority(uint32_t pri)
     uint32_t		 getPriority()
	  Sets/gets the	priority of the	sensor.	Priorities can be  changed  at
	  any  time;  if  the  priority	 is  changed to	zero and it is already
	  scheduled, the sensor	is immediately triggered and removed from  the

     static uint32_t	 getDefaultPriority()
	  Returns the default delay queue sensor priority, which is 100.

     virtual void	 schedule()
	  If  this sensor's priority is	non-zero, adds this sensor to the list
	  of delay queue sensors ready to be triggered.	This is	a way of  mak-
	  ing a	sensor fire without changing the thing it is sensing.

	  Calling schedule() within the	callback function causes the sensor to
	  be called repeatedly.	Because	sensors	are processed only once	 every
	  time	the  delay  queue  is processed	(even if they reschedule them-
	  selves), timers and events will still	be processed. This should  not
	  be  done  with  a priority zero sensor because an infinite loop will

     virtual void	 unschedule()
	  If this sensor is scheduled, removes it from the delay queue so that
	  it will not be triggered.

     virtual SbBool	 isScheduled()
	  Returns TRUE if this sensor has been scheduled and is	waiting	in the
	  delay	queue to be triggered. Sensors are removed from	the queue  be-
	  fore their callback function is triggered.

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



Want to link to this manual page? Use this URL:

home | help