mckay@ECN.PURDUE.EDU ("Dwight D. McKay") (12/12/90)
I'm trying to setup a SurrogateHelpFile for messages which displays a chomp inset. I've got the file setup and entered some events. It looks great when I start up messages. However, the inset never seems to get updated while messages is running! Must I quit messages and restart it again whenever any of my calendar files are changed so that the chomp inset will be current? --Dwight D. McKay, ECN Workstation Software Support --Purdue University, Engineering Computer Network --Office: MSEE 104f, Phone: (317) 494-3561 --mckay@harbor.ecn.purdue.edu --or-- ...rutgers!pur-ee!mckay
nsb@THUMPER.BELLCORE.COM (Nathaniel Borenstein) (12/12/90)
This is not a Messages bug, but, properly speaking, it is a CH*MP bug.
(However, that doesn't get ME off the hook, since I'm the author of
both!) The bug is that once a program is started and is running the
ch*mp code, it never again checks to see if any of the data files (the
files on your champpath preference, if you have one) have changed. In
other words, if you add events, you won't see them until you exit &
restart the program. You will see this same bug if you use ez to view a
chomp inset, as well.
This could, of course, be fixed. The code is all in atk/champ. In
fact, here's an inefficient but simple fix: In the file
atk/champ/match.c, add the following to the very beginning of the
procedure "FlagEventsMatchingDate":
struct eventnode *preven = NULL;
for (en=RootEventNode; en ; en=en->next) {
if (en->event) free(en->event);
if (preven) free(preven);
preven = en;
}
free(preven);
RootEventNode = NULL;
ReadDatesFromChampPath(NULL);
Note that I haven't tested the above code, but I believe it should fix
the problem. The only thing is, it is very inefficient -- it rereads
all your champ files every time, rather than only when they change. To
do it right would be a little more work, but would all be localized to
the two files match.c and read.c, and should be within the abilities of
most C programmers. (Note that no ATK knowledge is required, as this is
all in the non-ATK part of the code.) I trust that if anyone actually
gets motivated to fix this "right" they will pass the code back to the
ITC...