Access to DesignResultsTables

[Mr. Bodo Hasubek 3]

Hello all,

 

I generated a whole bunch of FDesignResultTables commonly know as the result tables shown after an optimization or ensemble investigation run.

Now I would like to collect all that data into one table, in which I consolidate several design runs into one line etc. This in general is not a problem, since all the values of the FDesignResultTables can be easily accessed. It possible for example to generate a script file that would do this task for me, since I know how to generate the names of the FDesignResultTables I would like to access. Obviously all FDesignResultsTables are somehow attached to the main scope of the application, because they can be diectly accessed in the command line.

 

However, it would be much more practicable if I could leave out the step with the script generation and directly iterate through a the list of all FDesignResultsTables from within a script, read the names and/or type (in case other object types are in this list as well) an decide what to do with it.

 

Is there an internal object that I can access that holds all the FDesignResultTables (and possibly others)?

 

Thank you,

Bodo

[Mr. Arne Bergmann 27]

DISCLAIMER: The following post contains information that we do not recommend to use for various reasons (explanation will follow at the end) and that may break in the future (another explanation will follow)!

 

Yes, there is a way. An internal command exists that gives you all objects: getManageds() which returns an objectlist. In a feature you can use it to access all FDesignResultsTables:

fobjectlist list(getManageds())

foreach (FDesignResultsTable table in list)
  echo(table.getName())
endfor

This would print the names of all FDesignResultsTables that exist. The "echo"-part could be replaced with your actual logic. If you are not familiar with the foreach-loop, see the documentation of FFeatureDefinition. As with all loops, they can only be used in features (not in fsc scripts). An alternative to the foreach-loop would be to use the castTo command, however, the foreach version is a lot cleaner, less typing and better performance:

fobjectlist list(getManageds())

unsigned i(0)
while (i < list.getCount())
  FDesignResultsTable table(list.at(i).castTo(FDesignResultsTable))
  if (!(!table))
     echo(table.getName())
  endif
  i += 1
endwhile

So, now the explanations for the disclaimer:

 

1. Why is not recommended to use the getManageds() command (in persistent features)?

By using that command you (may) break the client/supplier mechanism. This can lead to undefined behavior and state of your project. It can cause infinit recursions, for example. Consider a feature that gets a 3dpoint as input. So the feature is a client of the point. Now, it uses the getManageds command to change the x-values of all 3dpoints in the project. By doing that it will silently become a supplier of all points, without that relationship being tracked. This is not good!

You should be on the safe side, though, when you use it in a transient feature or only execute commands on the objects returned by getManageds() that do not alter the objects, which leads us to number two:

 

2. In what way may my feature break in the future when I use getManageds()?

In future versions of CAESES, it will not be possible anymore to call a command on the objects returned by getManageds() that change the object (in order to avoid the problem described above). While this makes the "You should be on the safe side" part of the explanation above still valid, it might be hard as a user to actually identify those commands that do not alter the object (sometimes it is not as clear as it may seem).

 

Since you only want to extract data from the tables, you should be on the safe side, however, please keep the above in your head when using getManageds().

[Mr. Bodo Hasubek 3]

Hello Arne,

 

a million thanks for the answer - and the warnings.

 

Regards,

Bodo