Creating step properties dynamically?

[knight2]

Hi

I wonder if anyone can give me some advice on this. I’m not that familiar with the way step properties work so hope this makes sense.

I’ve created an Edit VI step that displays various menu options for controlling the way the Post step executes. The step type is configured such that all output values from all options are passed into the step properties. However, since one of the menu options enables a further 6 more and since, for each instance of the step, I don’t select this top level option very often, I wondered if there’s a way of creating step properties only when required. I’m guessing that each time I select a new instance of the step, memory is allocated for the properties and it seems a bit of waste when most of the time, these extra options aren’t being used but space is still being reserving for them. I’m wondering if passing an array of clusters might be the solution, but is there a better way?

Thanks

Bruce

[~jiggawax~]

Someone at NI can correct me if I'm wrong here but if I understand it correctly instantiations of types only create memory space when they are not the default value.  So the definition is the only thing that will use the memory.  All instances will only use what is not default in the definition.

Therefore you will only take the memory hit for the definition.  I would recommend against dynamically adding properties to a step.  It seems you would be causing type conflicts by doing this. 

Arrays are a great way to get dynamic varying properties.  This is evidenced in the Message Popup step.  If you look at the button information it is stored in an array of clusters.

Hope this helps,

[knight2]

Hi jiggawax

Thanks for your reply - that's answered my question. I was really just concerned about allocating memory space unnecessarily, but sounds like there is no problem if the step property values are defaulted.

Thanks

Bruce

[dug9000]

---

@knight2 wrote:

Hi

I wonder if anyone can give me some advice on this. I’m not that familiar with the way step properties work so hope this makes sense.

I’ve created an Edit VI step that displays various menu options for controlling the way the Post step executes. The step type is configured such that all output values from all options are passed into the step properties. However, since one of the menu options enables a further 6 more and since, for each instance of the step, I don’t select this top level option very often, I wondered if there’s a way of creating step properties only when required. I’m guessing that each time I select a new instance of the step, memory is allocated for the properties and it seems a bit of waste when most of the time, these extra options aren’t being used but space is still being reserving for them. I’m wondering if passing an array of clusters might be the solution, but is there a better way?

Thanks

Bruce

---

Type instances in memory still use additional memory for their properties even if they are the same as the type definition. However when saved to a sequence file on disk, only differences from the type definition are saved to the file (it's somewhat a form of compression in that redundency is removed). Thus you are correct that memory usage will be unnecessarily increased for steps which do not need these properties. How significant that is is debateable, six simple properties don't use that much memory, but if you anticipate your users creating a lot of these steps it might add up. There are two main ways you can implement dynamically adding properties to your instances.

1) You can create a container property on your type definition and set its Unstructured flag. This allows the instances to have any properties inside this container and their properties underneath the container do not have to match the type definition. You can then propgrammatically add and remove properties from this container in your substeps. One down side to this is that there is no easy way to make existing instances conform to anything in the type definition for properties under the unstructured container because changes to those properties will not affect existing instances. One way to mitigate this somewhat is to use an instance of a custom data type as the main thing you add as a subproperty of the unstructured container. That way you can enforce and change the structure of those properties by modifying the custom data type.

Or

2) Use arrays. Array bounds and sizes can differ between instances and the type definition, so you can dynamically increase or decrease the array size in your instances as needed.

Hope this helps. Let me know if you have any follow up questions.

-Doug