hexagon logo

Inconsistencies Getting Field Values From Commands

I've been looking at how to get the field values from commands using GetFieldValue. There seem to be some inconsistencies depending on the command type and the type of value (array v. scalar).


1. For some fields like ID, if the command is not a DimensionCommand, HasField will return True for index values {-1, 0, 1, 2}. For DimensionCommand objects, {0, 1} return True. The value returned by calls to GetFieldValue will all be the same. Why does this happen? I would expect ENUM_FIELD_TYPES.ID to be a scalar value and thus only have a value at 0 (or 1 if we're 1-indexing).

2. Are arrays 0 or 1 indexed? It seems like certain fields have values from [1, N] while others have values from [1, N] as well as at 0. An example, for ENUM_FIELD_TYPES.THEO_X, if GetDataTypeCount returns 6, there will be values at {1, 2, 3, 4, 5, 6}, but also a value at 0, which for a Plane will be the location of the Plane. Other fields don't have values at 0 but do have an array of values.

3. GetDataTypeCountUniqueIndex Always returns 0

I'm not sure what the pattern is here. I feel like I'm missing something about how data in fields are represented. Any ideas why I would be seeing the above behavior?

Does does PC-DMIS distinguish scalar and array values? Why do some fields seem to be 1-indexed while also having values at the index 0?

  • Hello,

    I also used getfieldvalue before but ran into difficulties just like you did.

    I then switched to “command.getText()”. With the right code word, this command will give you exactly the values that are displayed in the edit window. Works better I think.​


    to the index...
    I think it's mostly 1 based.
    If you specify 0 or -1, instead of giving an error message, the largest or first index will be displayed. There are also fields that do not have an index; 0 is usually specified there

    If you export a pcDMIS program as "Basic" you will get, among other things, a bunch of command.setText() commands, the correct index is in there. You just need to convert these commands into getText, that gives you a good overview of where exactly the index is 0 or index 1..n is used​
  • Interesting. It would be really nice if the API was clear, functional and consistent. Seems to be quite a guessing game at this point unless I'm missing something about how to understand what indices exist for different fields and whether something is scalar or array-like.

    index | has field? | field value
    -1 F FALSE
    0 T 0 (has field should probably be false)
    1 T 23.223
    2 T 25.323
    3 T 0
    4 T 0
    (all zeroes from here on)​
    


    Here the field is MEAS_X, which doesn't show up in the VB version and GetDataTypeCount returns 0.
  • Hello,

    HasField Property tests whether a command has a specified field, in your test the field "MEAS_X" is present, so True is generated in every line.
    -1 is not an index therefore HasField generates an Error which it just shows as False.
    yes, you can't use HasField to test whether an index has a fieldvalue.



    For example, if you look at a circle, there will be multiple FieldValues of "MEAS_X".
    On index 0 the x value of the circle center is placed, and on 1..n then the x value of the first point and so on.
    There is no way to test via the 'automation' what is on which FieldValue index.



    But you have a quick method to get it out:
    Build a small pcDMIS program with a Auto-circle and press "Export as Basic"

    You will then get VBA commands like this:
    [...]
    retval = DmisCommand.PutText ("-251.124", MEAS_X, 0)  'x Value of the circle center
    retval = DmisCommand.PutText ("-6.998", MEAS_X, 1)    'x Value of the first point of the circle
    [...]
    

    The last number in this command is the index that you must enter in fieldvalue so that you can extract the correct data
    In principle it gives you the same value as getText and uses the same indexes
    That's why I switched everything to getText



    I believe GetDataTypeCount refers to whether a loop was used in pcDmis,
    means whether there are multiple instances of a "FieldValue".
    That's why I think it's always 0 in your test.​