SoMField(3)

πŸ“¦ version 3.1.3, in fedora 43, fedora 44

πŸ’– NAME πŸ’–

SoMField β€” okay so, bestie, this is the base class for fields that can hold multiple values. Not one lil lonely value, a whole squad of them. Mother of all multi-fields, no cap πŸ‘‘

Straight from the SoMField(3) page in the Library Functions Manual. Part 1 of 2, so buckle up πŸ’…

✨ SYNOPSIS ✨

#include <Inventor/fields/SoMField.h>

Inherits SoField.

Inherited by SoMFBool, SoMFColor, SoMFColorRGBA, SoMFDouble, SoMFEngine, SoMFEnum, SoMFFloat, SoMFInt32, SoMFMatrix, SoMFName, SoMFNode, SoMFPath, SoMFPlane, SoMFRotation, SoMFShort, SoMFString, SoMFTime, SoMFUInt32, SoMFUShort, SoMFVec2b, SoMFVec2d, SoMFVec2f, SoMFVec2i32, SoMFVec2s, SoMFVec3b, SoMFVec3d, SoMFVec3f, SoMFVec3i32, SoMFVec3s, SoMFVec4b, SoMFVec4d, SoMFVec4f, SoMFVec4i32, SoMFVec4s, SoMFVec4ub, SoMFVec4ui32, and SoMFVec4us. Like, the whole extended family showed up 🫢


🌸 Public Member Functions 🌸

  • virtual ~SoMField () β€” the destructor. She says her goodbyes and dips πŸ’”
  • int getNum (void) const β€” asks the field "how many of y'all are there?" πŸ”’
  • void setNum (const int num) β€” sets the count to num. Manifesting a specific number of values ✨
  • virtual void deleteValues (int start, int num=-1) β€” yeets values out, starting at start, num of them (with a default of -1, iykyk)
  • virtual void insertSpace (int start, int num) β€” carves out room at start for num fresh slots πŸŽ€
  • SbBool set1 (const int index, const char *const valuestring) β€” sets the value at index from a string. Returns an SbBool, so it'll let you know if it ate πŸ“
  • void get1 (const int index, SbString &valuestring) β€” grabs the value at index and drops it into valuestring
  • virtual void enableDeleteValues (void) β€” flips on the delete-values ability πŸ’…
  • virtual SbBool isDeleteValuesEnabled (void) const β€” asks "is delete-values turned on rn?" and answers with an SbBool

🌈 Public Member Functions inherited from SoField 🌈

These are all the vibes she got from her parent class. Every single one, no skipping:

  • virtual ~SoField () β€” destructor, bye boo 😭
  • void setIgnored (SbBool ignore) β€” set the ignore flag
  • SbBool isIgnored (void) const β€” is it ignored? asks and tells
  • void setDefault (SbBool defaultVal) β€” flag it as default (or not)
  • SbBool isDefault (void) const β€” is it default? πŸ‘€
  • virtual SoType getTypeId (void) const =0 β€” pure virtual, so the children gotta handle it themselves
  • SbBool isOfType (const SoType type) const β€” checks if it's the given type
  • void enableConnection (SbBool flag) β€” turn connections on/off
  • SbBool isConnectionEnabled (void) const β€” are connections enabled?
  • SbBool connectFrom (SoEngineOutput *master, SbBool notnotify=FALSE, SbBool append=FALSE) β€” connect from an engine output, with notnotify and append both defaulting to FALSE
  • SbBool appendConnection (SoEngineOutput *master, SbBool notnotify=FALSE) β€” append a connection from an engine output, notnotify defaults to FALSE
  • void disconnect (SoEngineOutput *engineoutput) β€” cut ties with that engine output πŸ’”
  • SbBool isConnectedFromEngine (void) const β€” connected from an engine or nah?
  • SbBool getConnectedEngine (SoEngineOutput *&master) const β€” hands you back the connected engine in master
  • SbBool connectFrom (SoField *master, SbBool notnotify=FALSE, SbBool append=FALSE) β€” connect from another field, notnotify and append both FALSE by default
  • SbBool appendConnection (SoField *master, SbBool notnotify=FALSE) β€” append a connection from a field, notnotify=FALSE
  • void disconnect (SoField *field) β€” unlink from that field
  • SbBool isConnectedFromField (void) const β€” connected from a field?
  • SbBool getConnectedField (SoField *&master) const β€” returns the connected field via master
  • int getNumConnections (void) const β€” how many connections total πŸ”’
  • int getForwardConnections (SoFieldList &slavelist) const β€” forward connections land in slavelist
  • int getConnections (SoFieldList &masterlist) const β€” connections land in masterlist
  • void disconnect (void) β€” the no-arg version, severs everything
  • SbBool isConnected (void) const β€” is it connected at all?
  • void setContainer (SoFieldContainer *cont) β€” assign the container
  • SoFieldContainer * getContainer (void) const β€” grab the container back
  • SbBool set (const char *valuestring) β€” set from a string
  • void get (SbString &valuestring) β€” get into a string
  • SbBool shouldWrite (void) const β€” should it be written out?
  • virtual void touch (void) β€” touch it, get the notifications going πŸ”₯
  • virtual void startNotify (void) β€” kick off notification
  • virtual void notify (SoNotList *nlist) β€” notify with nlist
  • SbBool enableNotify (SbBool on) β€” toggle notify on/off
  • SbBool isNotifyEnabled (void) const β€” is notify enabled?
  • void addAuditor (void *f, SoNotRec::Type type) β€” add an auditor f of type
  • void removeAuditor (void *f, SoNotRec::Type type) β€” remove that auditor
  • int operator== (const SoField &f) const β€” equality check, returns an int
  • int operator!= (const SoField &f) const β€” inequality check, also an int
  • virtual void connectionStatusChanged (int numconnections) β€” react to numconnections changing
  • SbBool isReadOnly (void) const β€” is it read-only?
  • virtual SbBool isSame (const SoField &f) const =0 β€” pure virtual "are these the same?" β€” children decide
  • virtual void copyFrom (const SoField &f)=0 β€” pure virtual copy, also on the kids
  • virtual void fixCopy (SbBool copyconnections) β€” fix up a copy, copyconnections tells it whether to bother with connections
  • virtual SbBool referencesCopy (void) const β€” does it reference the copy?
  • void copyConnection (const SoField *fromfield) β€” copy the connection from fromfield
  • virtual SbBool read (SoInput *input, const SbName &name) β€” read in from input under name
  • virtual void write (SoOutput *out, const SbName &name) const β€” write out to out under name
  • virtual void countWriteRefs (SoOutput *out) const β€” tally write refs into out
  • void setFieldType (int type) β€” set the field type to type
  • int getFieldType (void) const β€” get the field type back
  • SbBool getDirty (void) const β€” is it dirty? πŸ‘€
  • void setDirty (SbBool dirty) β€” set the dirty flag
  • void evaluate (void) const β€” evaluate it

πŸ’œ Static Public Member Functions πŸ’œ

  • static SoType getClassTypeId (void) β€” the class type id, static style
  • static void atexit_cleanup (void) β€” cleanup at exit, doing its lil housekeeping 🧹
  • static void initClass (void) β€” init the class

πŸ¦‹ Static Public Member Functions inherited from SoField πŸ¦‹

  • static void initClass (void) β€” init the class
  • static void initClasses (void) β€” init ALL the classes
  • static void cleanupClass (void) β€” cleanup the class
  • static SoType getClassTypeId (void) β€” the class type id

πŸŽ€ Protected Member Functions πŸŽ€

  • SoMField (void) β€” the protected constructor, for the inner circle only
  • virtual void makeRoom (int newnum) β€” make room for newnum values

🌸 Protected Member Functions inherited from SoField 🌸

  • SoField (void) β€” protected constructor
  • void valueChanged (SbBool resetdefault=TRUE) β€” value changed, with resetdefault defaulting to TRUE
  • virtual void evaluateConnection (void) const β€” evaluate the connection
  • virtual SbBool readConnection (SoInput *in) β€” read a connection from in
  • virtual void writeConnection (SoOutput *out) const β€” write a connection to out
  • SbBool isDestructing (void) const β€” is it in its destructing era? πŸ’€

πŸ’… Protected Attributes πŸ’…

  • int num β€” the number
  • int maxNum β€” the max number
  • SbBool userDataIsUsed β€” whether user data is used

⭐ Additional Inherited Members ⭐

Public Types inherited from SoField:

enum FieldType { NORMAL_FIELD = 0, EVENTIN_FIELD, EVENTOUT_FIELD,
    EXPOSED_FIELD }

So that's NORMAL_FIELD = 0, EVENTIN_FIELD, EVENTOUT_FIELD, and EXPOSED_FIELD β€” the whole enum, every member accounted for πŸ‘‘


🌈 that's a wrap on part 1, bestie β€” part 2 is coming right up, don't go anywhere πŸ’–

✨ Detailed Description ✨

Okay bestie, listen up β€” the SoMField class is the base class for fields that can hold multiple values. πŸ’…

Every field type that may contain more than one member value inherits from this class. And SoMField? It’s abstract, bestie. You can’t just instantiate it and expect main character energy. πŸ¦‹

Use setValue(), setValues() or set1Value() to set the values of fields inheriting SoMField, and use getValues() or the index operator [] to read values. Example code:

SoText2 * textnode = new SoText2;
textnode->ref();

// Setting multi-field values. /////////////////////////////

// Set the first value of the SoMFString field of the SoText2 node.
// The field array will be truncated to only contain this single value.
textnode->string.setValue("Morten");
// Full contents of the SoMFString is: [ "Morten" ]

// The setValue() method and the = operator is interchangeable,
// so this code line does the same as the previous line.
textnode->string = "Peder";
// Full contents of the SoMFString is now: [ "Peder" ]

// Set the value at index 2. If the field value array contained
// less than 3 elements before this call, first expand it to contain
// 3 elements.
textnode->string.set1Value(2, "Lars");
// Full contents of the SoMFString is: [ "Peder", <undefined>, "Lars" ]

// This sets 3 values of the array, starting at index 5. If the
// array container had less than 8 elements before the setValues()
// call, the array will first be expanded.
SbString s[3] = { "Eriksen", "Blekken", "Aas" };
textnode->string.setValues(5, sizeof(s) / sizeof(s[0]), s);
// Full contents of the SoMFString is now:
//     [ "Peder", <undefined>, "Lars", <undefined>, <undefined>,
//       "Eriksen", "Blekken", "Aas" ]

// Note also that the setValues() call will *not* truncate a field
// container if you use it to change a subset at the start:
SbString n[4] = { "Dixon", "Adams", "Bould", "Winterburn" };
textnode->string.setValues(0, sizeof(n) / sizeof(n[0]), n);
// Full contents of the SoMFString is now:
//     [ "Dixon", "Adams", "Bould", "Winterburn", <undefined>,
//       "Eriksen", "Blekken", "Aas" ]

// Inspecting multi-field values. //////////////////////////

// This will read the second element (counting from zero) if the
// multivalue field and place it in "val".
SbString val = textnode->string[2];

// Gives us a pointer to the array which the multiple-value field
// is using to store the values. Note that the return value is
// "const", so you can only read from the array, not write to
// it.
const SbString * vals = textnode->string.getValues(0);

// Modifying multi-field values. ///////////////////////////

// You can of course modify multifield-values by using the set-
// and get-methods shown above, but when you're working with
// big sets of data, this will be ineffective. Then use this
// technique instead:
SbString * modvals = textnode->string.startEditing();

// ... lots of modifications to the "modvals" array here ...

// Calling the finishEditing() method is necessary for the
// scene graph to be updated (and re-rendered).
textnode->string.finishEditing();

The reason it is more effective to wrap many modifications within startEditing() / finishEditing() is because we avoid the stream of notification messages which would otherwise be sent for each and every modification done. Instead there will just be a single notification about the changes, triggered by the finishEditing() call. Slay β€” one notification instead of a whole chaotic group chat. ✨

The correct manner in which to pre-allocate a specific number of field values in one chunk is to use the SoMField::setNum() method, for instance in advance of using the startEditing() and finishEditing() methods. The field values will be uninitialized after expanding the field with the setNum() call.

Be aware that your application code must be careful to not do silly things during a setValues()-triggered notification. If you have code that looks for instance like this:

// update set of coordinate indices at the start of e.g.
// an SoIndexedFaceSet's coordIndex field..
ifs->coordIndex.setValues(0, runner->numIndices, runner->indices);
// ..then truncate to make sure it's the correct size.
ifs->coordIndex.setNum(runner->numIndices);

As setValues() might leave some elements at the end of the array that typically can be invalid indices after the first statement is executed, something can go wrong during notification if you have application code monitoring changes, and the application code then for instance triggers an action or something that tries to use the coordIndex field before it’s updated to it’s correct size with the setNum() call. Not cute, bestie β€” do not let that happen. 😭

(Notification can in this case, as always, be temporarily disabled to be on the safe side:

somefield.enableNotify(FALSE);
somefield.setValues(...);
somefield.setNum(...);
somefield.enableNotify(TRUE);
somefield.touch();

This will guarantee that the setValues() and setNum() pair will be executed as an atomic operation.)

When nodes, engines or other types of field containers are written to file, their multiple-value fields are written to file in this format:

containerclass {
  fieldname [ value0, value1, value2, ...]
  ...
}
Coordinate3 {
   point [
      -1 1 0, -1 -1 0, 1 -1 0,
      0 2 -1, -2 0 -1, 0 -2 -1,
   ]
}

Some fields support application data sharing through a setValuesPointer() method. setValuesPointer() makes it possible to set the data pointer directly in the field. Normally (when using setValues()), Coin makes a copy of your data, so this method can be very useful if your application needs the data internally and you’re just using Coin for the visualization. Example code:

myapp->calculateCoordinates(SOME_LARGE_VALUE);
SbVec3f * mycoords = myapp->getCoordinates();

SoCoordinate3 * mynode = myapp->getCoordinateNode();
mynode->point.setValuesPointer(SOME_LARGE_VALUE, mycoords);

Be aware that your field should be a read-only field when you set the data like this. If you write to the field, the values in your application array will be overwritten. If you append values to the field, a new array will be allocated, and the data will be copied into it before appending the new values. The array pointer will then be discarded. Read-only means read-only, periodt. πŸ’…

Also note that whenever you change some value(s) in the array, you must manually notify Coin about this by calling SoField::touch(). For our example:

SbVec3f * mycoords = myapp->getCoordinate();
myapp->updateCoordinate(mycoords);
SoCoordinate3 * mynode = myapp->getCoordinateNode();
mynode->point.touch(); // this will notify Coin that field has changed

You can use SoMField::enableDeleteValues() to make Coin delete the array for you when the field is destructed or the array pointer is discarded because it isn’t needed anymore (e.g. when the array size is changed). The array will be deleted using the C++ delete[] operator, so if you use it, your array must be allocated using the C++ new[] operator.

SoMField::enableDeleteValues() is supported only to be compatible with later versions of TGS Inventor and we don’t recommend using it. It can have undefined results on the Microsoft Windows platform. Allocating memory in the application and destructing it in a DLL can be a bad thing, causing mysterious crashes, if you’re not very careful about how your application and DLLs are linked to the underlying C library. Undefined results? Mysterious crashes? That’s giving horror movie, not slay. πŸ’€


πŸ‘€ See also πŸ‘€

  • SoSField

πŸ›  Constructor & Destructor Documentation πŸ› 

SoMField::~SoMField () [virtual]

Destructor in SoMField does nothing. Resource deallocation needs to be done from subclasses. So don’t expect this destructor to clean up your mess β€” that’s a subclass job, bestie. 🧹

SoMField::SoMField (void ) [protected]

Constructor. Initializes number of values in field to zero.


πŸ“š Member Function Documentation πŸ“š

int SoMField::getNum (void ) const [inline]

Returns number of values in this field. Simple. Iconic. No notes. ✨

void SoMField::setNum (const int numarg)

Set number of values to num.

If the current number of values is larger than num, the array of values will be truncated from the end. But if num is larger, the array will automatically be expanded (and random values will be set for the new array items). Random values? Yeah, she’s chaotic like that. πŸŽ€

void SoMField::deleteValues (int start, int numarg = -1) [virtual]

Remove value elements from index start up to and including index start + num - 1.

Elements with indices larger than the last deleted element will be moved downwards in the value array.

If num equals -1, delete from index start and to the end of the array.

Reimplemented in SoMFEngine, SoMFNode, and SoMFPath.

void SoMField::insertSpace (int start, int numarg) [virtual]

Insert num "slots" for new value elements from start. The elements already present from start will be moved "upward" in the extended array.

Reimplemented in SoMFEngine, SoMFNode, and SoMFPath.

SbBool SoMField::set1 (const int index, const char *const valuestring)

Set the value at index to the value contained in valuestring. Returns TRUE if a valid value for this field can be extracted from valuestring, otherwise FALSE.

If index is larger than the current number of elements in the field, this method will automatically expand the field to accomodate the new value. Accommodate, but make it fashion. πŸ’…

void SoMField::get1 (const int index, SbString & valuestring)

Return the value at index in the valuestring string.

void SoMField::enableDeleteValues (void ) [virtual]

Can be used to make Coin delete the array pointer set through a setValuesPointer() call. See SoMField documentation for information about the setValuesPointer() function.

This method is a TGS extension (introduced in TGS OIV v3.0) and is supported only for compatibility. We suggest that you don’t use it since it can lead to hard-to-find bugs.

Since

  • Coin 2.0
  • TGS Inventor 3.0

SbBool SoMField::isDeleteValuesEnabled (void ) const [virtual]

Returns whether SoMField::enableDeleteValues() has been called on a field. The result is only valid if setValuesPointer() has been called on the field first.

This method is a TGS extension (introduced in TGS OIV v3.0) and is supported only for compatibility. We suggest that you don’t use it since it can lead to hard-to-find bugs.

Since

  • Coin 2.0
  • TGS Inventor 3.0

void SoMField::makeRoom (int newnum) [protected], [virtual]

Make room in the field to store newnum values.


🧬 Member Data Documentation 🧬

int SoMField::num [protected]

Number of available values.

int SoMField::maxNum [protected]

Number of array "slots" allocated for this field.

SbBool SoMField::userDataIsUsed [protected]

Is TRUE if data has been set through a setValuesPointer() call and set to FALSE through a enableDeleteValues() call.


πŸ’– Author πŸ’–

Generated automatically by Doxygen for Coin from the source code.


And that’s the whole vibe, bestie! This page was brought to you by Coin, Version 3.1.3, and the SoMField(3) manual β€” no date on the footer, just timeless icon energy. Stay slaying those multi-fields! πŸ’…βœ¨πŸ¦‹

πŸ“¦ where this page comes from