Use ExecuteCustomMethod for Better Code

I’m in the process of upgrading some of my xem files and one of the things I’m doing a lot of is using ExecuteCustomMethod to simplify both my global script library and a lot of my code.  Many of the functions I write end up being accessible in the context menu both for the base object (e.g. Table), a package, and the model.  In the past, I’ve either wrapped the common bits of code into the global tab or I’ve duplicated it into methods at the various levels.

Both of these approaches have problems. Putting everything in the global script  tab leaves me with an enormous stack of code to go through when I’m making changes.   On several occasions, I’ve managed to break a unit I wasn’t intending to change at all with a fat finger while doing my editing.  It also separates the code from the object it’s working on, which for a complex XEM file makes maintenance a bit more difficult.

Copying the method code from the base object, to the package and model methods is easier.  It keeps the volume of code in my global script tab more manageable and makes seeing what the method at each level is doing easier, but it leads to the inevitable slips where I update some copies but not all of them.   Plus, as a former programmer, it’s hard to do without feeling guilty.

The solution (in case you didn’t read the post name) is ExecuteCustomMethod.  It allows me to avoid the problems (and guilt) associated global methods and code duplication.  I write my methods for an object, and then re-use them elsewhere by calling ExecuteCustomMethod.

If I want to put a method on a table DoSomething, I can call that method elsewhere with:

Table.ExecuteCustomMethod("<XEM Name>.DoSomething")


Now I have all my code associated with tables in one place, and I can call them from anywhere without duplication. There are a few issues. I can’t return a value and I can’t pass parameters. There’s an easy solution to this problem.  If I have to pass a parameter or get a a value back, I can always use a global (a model level ExtendedAttribute). This sounds like a bad idea, but for the types of things I would normally control with a parameter, and extended attribute may be a better idea anyway, since I can use it to store user preferences between executions.  Return values are a little more problematic, but you’ve gotta do what you’ve gotta do.

Now I have most of my custom code associated with the object it acts on and my global script tab is reserved for functions or subroutines which need to return a value or aren’t object specific (my output function for example).

Best of luck, and I hope ExecuteCustomMethod saves you some time or trouble in the future too.