Assessment 1: Hints and Tips


There is no prefered solution to this assessment. However, if you choose to use a ComboBox, this page offers some advice. It also gives some tips on getting started.


ComboBoxes

Firstly, note that ComboBoxes do not have an init() method you can override. This means that you can't get the Application object into them directly when they start. If you want to deal with the Application object you will need another type of addin component to get that and either: 1) deal with the Application object and read and write to the ComboBox, or 2) setApplication inside the ComboBox to set up an appropriate Application instance variable. Either way, one or other of the addin components, if not both, will need to be Singletons.

Secondly, note that a lot of the methods in ComboBoxes are abstract, i.e. you'll have to write at least blank copies of them to get the code to compile.

Thirdly, note that the edit box at the top of a dropdown list can be got at through the ComboBox's hook instance variable. This variable is inherited directly from the ComboBox superclass. The variable implements a number of methods that might be of use (a link to its class can be found in the API for ComboBox).

Finally, it is worth noting that ComboBoxes can be frustrating to work with. Often the best bet is to keep a separate copy of all the data for this list, and to just rebuild the whole list in the ComboBox when you need to.


Planning your project

  1. First, think through roughly how your project will look and work. Draw and annotate short descriptions of how a user will use the tool. Think "would I find this easy to use" and "from the user's point of view, is each step there for a reason". Then think through what can go wrong -- and this is right from the beginning when the user opens Arc, through to what happens if they send a document to someone else. Having thought through these two aspects, draw up a UML of the classes and methods, but annotate it with rough ideas of what each class or method has to achieve. Your project will change as you go through and learn the capabilities of the classes, so you will need to revisit this plan, but you definitely need to start with something in place.
  2. Break the project into tasks ('essential', 'ideal', 'nice-to-have') and do the essential ones first. There is no point spending weeks getting a task list to save somewhere really clever (ideal) if it doesn't appear on the screen (essential). Start with something simple, like getting a hard-wired list into a ComboBox on the user interface, then move on to adding and removing items, before worrying about saving and loading them.
  3. When you come to start coding, remember the first rule of coding: Baby steps. Write a few functional lines at a time, and test them when you've written them. There is no point in ploughing on passed issues. Sort them out before you move on. If something is really stopping you moving forward, ask Andy for help.
  4. Finally, experiment. If you don't know how ComboBoxes work, just write a small addin using one and try out a few things -- see what gets outputted from different methods etc. Get familiar with the classes before you go on to use them in anger. It is better to understand things like how list item indexes change when items are removed before you code, than it is to suddenly discover things didn't work as you thought they did half way through coding.