Best practices checking for objects in collections

Best practices checking for objects in collections

rjay75
Collaborator Collaborator
454 Views
4 Replies
Message 1 of 5

Best practices checking for objects in collections

rjay75
Collaborator
Collaborator

I have some commands in which I add a button to the context menu in certain situations. Depending on the situation the button may be added or removed.

 

I'm alternating between using iterating through the definitions on the object they belong and if I have access to the it such as events that expose the commandbar object I iterate through it's buttons. If I don't I use a try/catch on the ControlDefinitions. Iterating through that causes an unacceptable pause.

 

I've always thought using exceptions to test objects is expensive but the delay breaks the users flow due to the pause.

 

What is the correct way to test for this?

 

I also run into this situation because I have different addins that add different sets of controls from a common set of dlls depending on the use context. Try/Catch works but is that the recommended way to test for things. I often need to test  for the existance of things such as parameters (I have some plugins which will recreate sets of needed user parameters and some have hundreds if they don't exist already) and try/catch seems to be the best method.

0 Likes
455 Views
4 Replies
Replies (4)
Message 2 of 5

barbara.han
Alumni
Alumni

Can you paste a code sample here to explain what is the exact problem? I think using try/catch in the piece of code of iterating collection is expensive, maybe checking if some property is null(or nothing) would work, or checking Type of the object would avoid later problems...What is the unacceptable pause in your case?

Barbara Han
Developer Technical Services
Autodesk Developer Network
0 Likes
Message 3 of 5

rjay75
Collaborator
Collaborator

Here's an example where the button definition is created when a command is run for the first time. Each time after it doesn't need to be recreated. I'm thinking now I can create it when the add in is first loaded.

 

            //Setup Done Menu Button
            ControlDefinition btDone = null;
            try
            {
                btDone = appInventor.CommandManager.ControlDefinitions["jtnft_BtnDonePicking"];
            }
            catch (Exception)
            {

                //Do Nothing No Button Found
            }
            if (btDone == null)
            {
                //Add Button Here Defintion here
            }

Originially it iterated the list testing for a definition by that name. That took about 2-3 seconds to do everytime the dialog opened.

 

The other time this method is used is in adding UI elements to the ribbon. I have several addins that I want to add buttons to a common Ribbon panel. Because the order that any of the elements can be added may be different the panel they need to add to may or may not exist so it will have to create it. 

0 Likes
Message 4 of 5

xiaodong_liang
Autodesk Support
Autodesk Support

Hi,

 

I am not sure try/catch is the best practice, but it is the best way to me. As I know, only Attribute of Inventor API provides AtrubiteManager which could do some quick search. For other collections, you have to iterate to find if the item exists. Try/catch allows you to ask the internal code to do searching which is faster than iteration.

 

0 Likes
Message 5 of 5

xiaodong_liang
Autodesk Support
Autodesk Support

In addition, for iteration, for each is more efficient than iterating using Count and Item.

0 Likes