Interacting with Multiple Iteration forms is the most complicated ScriptLink task by far. This is due, in large part, to the data model not being intuitive at first glance and limited documentation. Over the next few weeks, we will be looking specifically at some basic multiple iteration interactions. This week, modifying a value found in an existing row.
There are a number of reasons that you might want to set or change the value of a field in myAvatar: Setting default values dynamically, storing a computed value, or even correcting or appending a value. In my ScriptLink work, I have had each of these use cases. In the previous articles, we looked at how to read field values. Now, let’s set them.
Last week, we read a value from a myAvatar Form and based on that value changed the message returned to the user. This method works well for most myAvatar forms, however, there are additional considerations to make with forms that contain one or more multiple-iteration tables. That’s what we will cover today.
While a “Hello, World!” example may be good for demonstrating how a solution is built, it typically isn’t very useful. This certainly describes our ScriptLink project so far. We can provide the myAvatar user a popup that reads “Hello, World!” and that is about it. For the next few articles, we are going to look at working with the form data from myAvatar. Today, we are going to read a value from a myAvatar form.
Last week, we added NLog to our .NET ScriptLink project to generate debugger log entries. Having NLog now configured and in place we can consider additional targets for the log entries. These targets include: the console, file, mail, databases, and more. Today, we are going to expand our configuration to use a file target, setup filters, and auto-archiving.
Our solutions will often behave unexpectedly. To understand how and why the behavior occurred requires information. Without it we may find ourselves in the position of a reported issue that cannot be understood let alone replicated. This is where logging comes into play. When done well logging can provide the information you need to identify and correct issues without compromising performance.
In my last post, we looked at using interfaces to support the multiple versions of the OptionObject without writing duplicated code. Interfaces are great for creating methods that can consume or return multiple concrete classes such as our OptionObjects. However, in C# at least, you can’t implement any common functionality through interfaces. They are simply contracts that define what the concrete classes are to implement. What if there was a common method that we wanted to extend our OptionObjects with? Welcome abstract classes.
I first started working with myAvatar ScriptLink during the days of the OptionObject (v1). Shortly after, an updated version, OptionObject2, was released with some additional valuable properties. I completely missed the announcement of this version and didn’t stumble on it until well after the OptionObject2015 version was released. So I was using OptionObject in production, but I wanted to upgrade to a newer release without writing duplicate code. Inheritance became my solution and a foundation of the design of the AvatarScriptLink.NET library.
We’re back this week discussing another option for managing your .NET ScriptLink code: GitHub. GitHub is a popular platform for managing code, especially for open sources project. My first attempt at an open source ScriptLink library was managed there and is still available. I even manage my addon for World of Warcraft on GitHub. However, GitHub is not just for open source projects.
It can be easy for developers when working alone to overlook using a code repository. Especially, if like me, they started out just hacking things together to get a task done quickly. This impulse to just check a task off of our list can motivate us to overlook tasks like testing and checking in changes. It may cost a little extra time up front, but it will save you a lot of time later when things go awry.