This is going to be a big week of posts, three posts to be exact. I’m heading to Houston, which means a lot of time on planes and time for writing. The foundation for the posts is a piece of IronPython code that checks and unchecks the checkboxes in a filter. I needed code to do this for a project I was working on last week. A Google search turned up this TIBCO community link. The second response was exactly what I needed.
Now, I’m on a bit of a learn IronPython kick, and I wanted to understand to how this was written. I started by looking up each piece of API in TIBCO’s API reference. In the past, the API reference read like Greek to me. But walking thru the API one piece at a time, combined with the other 16 hours I’ve put into IronPython, really helped me understand what each line of code was doing. I got really excited and started writing it up. Per usual, it was too long. So, now I’m on a plane breaking it down into 3 posts, for ease of consumption. Here’s how it’s going to go.
- Post 1 (this post) takes a high-level look at the code and explains how to modify it for different use cases. This will familiarize you with the code. I’ll also talk about objects versus syntax to build on the post I wrote last week on Learning IronPython.
- Post 2 will talk about the API in detail by explaining where each piece of the API is and how to navigate to it.
- Post 3 (include link) will explain what the code is doing and why. This is something I have shied away from in the past because I didn’t have the understanding to do so. I’m getting there one code snippet at a time, and you’re coming with me.
We are going to get to the code, but first, I want to clarify my requirements.
Ideally, I wanted one piece of code to check and uncheck all the checkboxes. The TIBCO article presented two code snippets, so I created two buttons with two sets of code, one for checking and another for unchecking. I’m going with this even though a slightly better iteration would be one code snippet with “IF” logic that looks to see if the boxes are checked and if they are, it unchecks them and vice versa. I’m going with two buttons for now. Gotta walk before you run.
Now, you can copy and paste the code from the TIBCO link, so I won’t include that here. I will show my screenshots so there is no question about spacing.
Next, let’s talk about code syntax versus object.
Last week, I discussed how to figure out if a particular word in the code is an object the developer created or part of the syntax. I suggested running a simple test by changing the name of the object. If the code still runs, it’s an object, not syntax. To build on that though, the equals sign usually signals an object. Keywords, like “as”, “for”, and “in” are also indicative an object is coming.
For example, the words circled in the screenshot below were created by the developer. They could be any word the developer chooses. Also, all of the other references to Filters are uppercase, indicating they are API references. That’s not to say that objects can’t be uppercase, but if all the API references are in uppercase, it makes sense to name objects in lowercase.
Now, I don’t want to just show you which parts of the code are objects. I want to explain why the developer created the objects. Generally speaking, developers create objects to make referencing things in code easier. I’ll use “filters” as an example. This object is only used one other time after creation in line 13. So, the two lines of code shown below illustrate the difference with and without the object.
Line 13 without an object —
checkBoxFilter = myFilter.FilterReference.As[Spotfire.Dxp.Application.Filters.CheckBoxFilter]()
versus Line 13 with an object —
checkBoxFilter = myFilter.FilterReference.As[filters.CheckBoxFilter]()
Here’s another example using “myPanel” from line 9.
Line 9 without an object —
myFilter = Document.ActivePageReference.FilterPanel.TableGroups.GetFilter("BudgetNode")
versus Line 9 with an object —
myFilter = myPanel.TableGroups.GetFilter("BudgetNode")
Next, let’s talk about how to modify this code for your own use cases.
Modifying for Different Scenarios
There are four modifications you might want to make to this code.
- Obviously, you’ll want to change the column name to your own columns of data.
- If there is more than one table in your analysis, you will most likely need to change the TableGroup index.
- You might want to account for Empty values.
- You might need to check and uncheck more than one filter.
First & Second Modifications
The first modification is the simplest to make. Just change the column name circled below. Next, the code “myPanel.TableGroup is telling Spotfire which table to get BudgetNode from. The number four is an index of table positions in the filter panel. The index values start at zero. My table is the 5th in the list as shown in the second screenshot below, so I need 4 in the index to get the column from the correct data table in the filter panel.
If the Boolean value is set to False, (Empty) will not be unchecked when the button is clicked. If you want (Empty) to be unchecked, set the value to True.
Line 15 checkBoxFilter.IncludeEmpty = False
Line 15 checkBoxFilter.IncludeEmpty = True
If you need to uncheck multiple filters, copy and paste lines 9 thru 19. Then modify the myFilter, checkBoxFilter, and value objects. Rename them something like mFilter1, checkBoxFilter1, and value1 so that they are their own distinct objects and don’t conflict with previously defined objects. Now, I am going to walk thru the API via this code example.
Lastly, you might have noticed the post introduced two code snippets but only followed one thru to this conclusion. The code snippets are similar enough that you should be able to make the same modifications described for both pieces of code.
The next post is going to dive deep into the API. Be ready to follow along. Click here to jump straight to it.
Content created with Spotfire 7.12.
Guest Spotfire blogger residing in Whitefish, MT. Working for SM Energy’s Advanced Analytics and Emerging Technology team!