The in-basket 2

Last week, after developing what I thought was a very neat solution, I presented my work-in-progress, aka the In-Basket exam, to the occupational psychologist (OP). Whilst she was impressed, it transpires that the direction that I had taken was not the one that she wanted. She insisted on having an interface more reminiscent of an email program, with an inbox and an outbox, where letters move from one to the other. It also became clear that I would need a table of 'dramatis personae', data about the 'people' who sent letters to the examinee to be dealt with.

On Saturday I worked for several hours on the program, getting it to a fairly reasonable state. On Sunday, I worked on the 'reply' section, which was fairly difficult. Unfortunately, demands of the day job and the July heat imposed themselves on me and so I couldn't continue with the work until yesterday evening, when I completed the 'reply' code (it's not exactly how it should be, but it's good enough for now).

This morning I presented the new, improved program once again to the OP and this time got the seal of approval. Even so, there were a myriad of small changes needed, along with a major change: instead of using listviews with which I displayed the messages, I decided to be traditional and used dbgrids. This simplifies certain aspects of the code and makes it more dependable.

I've just finished about four hours of work on the program, in which I seem to have rewritten about 50% of the code. In order to 'celebrate', I entered into the database an exam in which the examinee receives about 15 emails and has to decide in which order to execute the various tasks. The exam program as written isn't totally conducive to this exam; there's no simple way to show the execution order and the emails don't have much content. Our exam is different from others which I have seen in that the examinee has to provide reasons for the actions which he took. I utilised this in order to provide the timetable for my actions.

This specific exam didn't utilise any of the 'reply' code (ie reactions to 'emails' which have already been sent) so I couldn't exercise this part of the code. Otherwise the exam program behaved very well, except for the strange fact that one email appeared twice. I'm not sure how this came about and I'm not sure how I'll debug this.

Whilst developing the program and utilising the 'instant message' feature, I noticed that an instant message was appearing twice. It took me a long time to figure out where this was coming from - as I'm writing what is effectively a real-time program with MDI forms, it's not always clear who is doing what. Eventually I unravelled the mystery: the main program has a timer which fires every minute sending a message to the inbox form, telling it to load any new messages. In MDI programs, the child forms are generally anonymous, so one has to write code like this

for i:= 0 to mdichildcount - 1 do

 mdichild[i].close

When one wants a specific form to execute something - for example, the inbox and outbox forms are unique and can receive messages, whereas the email forms are non-unique and don't have messages - one has to use a typecast. First one checks whether the child form is of the required type and then a typecast is used. I have seen similar code which does not use a typecast, instead using the 'as' keyword; at this stage, the type of the child is known and so it is perfectly safe to use a typecast, which requires less code and is faster than the 'as' approach.

My code:

for i:= 0 to mdichildcount - 1 do

 if mdichild[i] is TSomething

  then TSomething (mdichild[i]).DoSomething;

'As' code;

for i:= 0 to mdichildcount - 1 do

 if mdichild[i] is TSomething

  then with mdichild[i] as TSomething

   DoSomething;

In the specific case of the instant messages, the IM was displayed as a new MDI child form and unfortunately the newest child form becomes mdichild[0], whereas the form which was previously first in the array now becomes second. The timer code was

for i:= 0 to mdichildcount - 1 do

 if mdichild is TInbox

  then TInbox (mdichild).openmessage (minutes);

At the time of execution, mdichild[0] was the inbox and mdichild[1] was the outbox. The first iteration sent a message to the inbox and told it to open any extant messages. When it was the IM's turn, it appeared on the screen. At this stage, mdichild[0] is now the IM, mdichild[1] is the inbox and mdichild[2] is the outbox. On the second iteration of the timer loop, it was looking at mdichild[1] - which is still the inbox! So the IM display code got called again, resulting in two IMs on he screen. The solution was fairly simple:

for i:= mdichildcount - 1 downto 0 do

 if mdichild is TInbox

  then TInbox (mdichild).openmessage (minutes);

Tomorrow I'm going to write the program which displays the user's results. The main report will be in the form of a diary:

00:10 mins: message #1 opened

00:15 mins: message #2 opened

00:20 mins: message #3 opened

00:30 mins: message #3 answered

text of message #3

user's answer

user's reason

00:40 mins: message #1 closed

...etc.

In the test exam, in which all the emails are extant at the beginning of the exam and they have to be replied to in an optimum order, there is no option but to open all the emails at the beginning of the program and read them before one is able to formulate a plan. As it happens, I knew that there were a few emails which could be left unread at first, but I imagine that most examinees won't know this.