Steve Mumford looks at how changes in data structure affect the operation of a program

Last month I introduced some of the details behind the planned user interface for our label design application - it became clear to me that a method of editing involving a master template was necessary in developing the ease of use I was after.

The idea of having a parent label, whose properties are inherited by its children, affects the scheme of data storage quite radically, especially if those children can 'disown' their parents and develop their own characteristics later on in their lives. This month I'll be looking at the data structures themselves and seeing how changes in those structures can influence the manner in which the program is likely to operate.

As outlined above, the master label is designed to pooi together all the general features of a set of labels and allow the user to create a type of form that eases prolonged data entry. In this way, we simplify the process of label creation while retaining the flexibility to add or delete elements to specific labels later on.

What sort of information do we need to store on the master label? Some major features will be shared between master and offspring labels, such as the graphics and text field lists, but some features will be held by the master label alone.

These would include global features like label size as well as extra information that isn't relevant for the children - with automatic importing of data in mind, the order in which the fields are to be filled could be stored here. I was keen to be able to disconnect a newly created label from the influence of its master so that any 'unusual' labels could be created without having to alter the master and upset formatting elsewhere.

Implementing this would mean having a flag for each label to indicate whether or not it was still under direct control, so as soon as one label 'opted out', changes made to the master would no longer be echoed there. However, how do we provide each new label with the information from its parent and what changes would occur when a label was removed from this hierarchy?

It would be wasteful to copy the information across into each new label as it was created, and updating the children when the master was altered would be a time-consuming business as the list of labels would have to be scanned and the changes echoed in every label in the set.

Instead, it would be better to link to the contents of the first label, either directly by entering a pointer to the master object's linked list in that of the child label or, in a more abstract fashion, by calling a separate procedure to display the rest of the information after the main bulk of the label had been drawn. In this way, a change made to the master label would be automatically propagated throughout the list, without the application having to do a great deal of work.

In a situation where one label wanted to break free, the graphics and text elements of the master could be copied directly over to the new label and added to its own lists - it would then have a standalone copy of the master, and would be free to change, move or delete them as appropriate. Returning a label to the control of the master would be harder as we'd need to remember which fields were inherited; however, a simple flag as part of the text object would help us around that problem.

To sum up, all unmodified sections of the label would be stored as part of the master's description and everything else would be part of the child's. Considering the format of the master label again, it would be advantageous to be able to include fields as part of the master label description that were automatically copied over to the child as an editable field. In this way, it would be possible to create new labels with non-editable text strings alongside pre-positioned editable fields, again easing the process of data entry for the user.

The data structures that we are to use must be able to cope with a variety of scenarios, some of which I have outlined above. They must be able to deal with offspring labels being disconnected, changed and then reconnected to the master, and alterations made to the master should propagate quickly and seamlessly.

I hope I've been able to show that the format of the data structures has a profound effect on the shape of the application. That's all for this month, I'll see you next time.