From: danielle@chama.eece.unm.edu (Danielle Argiro)
Newsgroups: comp.soft-sys.khoros
Subject: Re: Plot Data-subform crashes
Date: 14 Aug 92 20:58:23 GMT


	Hi there,

	Thought I would add my $0.02 to this discussion --
	I'll summarize real quick rather than including the
	previous messages in their entirety.

	Marcus Hennecke had problems because he moved the Plot Data 
	cantata UIS file while cantata was running, resulting 
	in a seg fault by cantata.  

	Brad Castalia (correctly) summed up the problem by noting
	that UIS files are order/position independant, and that
	changing a UIS file while cantata is running will cause
	it to encounter bad references and crash.  He suggested
	restarting cantata to fix the problem.

	Marcus Hennecke then mailed back, saying that he was still
	having problems, that he event logged out and logged back
	in again.  He thinks that something else was wrong:

} I have. Many times. I even logged out and back in. But it didn't help at
} all. Something else must have been corrupted, too. But it doesn't show in
} the modification dates.
} 
} Marcus
} hennecke@microelectronic.e-technik.th-darmstadt.de
}-- End of excerpt from Marcus Hennecke

	Something Marcus said earlier, though, leads me to think the
	problem may be with a toolbox installed at their site: 

} What makes the crashes really strange is this: Everything works fine again
} when the number of guide pane buttons in our self-made toolbox is either
} reduced by at least one or increased by several buttons. Our current
} work-around is this: we have simply doubled the number of guide pane buttons
} in our toolbox subform (currently, there is only one), so that each button
} is there twice. 
}
}-- End of excerpt from Marcus Hennecke

	UIS files are never supposed to have only one guide button on a 
	subform.  It must always be two or more, although the errorchecking
	in Khoros 1.0 is insufficient to catch this and print an error 
	message.  The reasoning is that if you do not need more than one
	guide button, then a single pane is suffient -- no guide buttons
	are necessary.   Also, I have seen one case where a guide pane
	with several guide buttons caused cantata to crash because
	none of the (-g) lines had their 'selected' field set to 1,
	indicating the (associated) default pane for the subform.  Again,
	error checking was insufficient to catch this case.  Is it
	possible that either of these situations in your UIS file for your
	installed toolbox is affecting cantata?  Just a shot in the dark,
	Marcus, but worth checking out, anyway ...

	Also, Brad's note deserves a response:

On Aug 12,  1:18pm, Bradford Castalia wrote:
} Subject: Re: Plot Data-subform crashes
} 
} [Khoros Group pls note: while I realize that a significant commitment
} has already been made to the current UIS syntax and structure, and
} backwards compatibility will be very important for Khoros 2, much of
} the order/position dependencies (e.g. -g and -p lines) is a *really bad
} idea* and should, if at all possible be improved for the next major
} release. This, and the exceedingly cryptic, minimalist, inflexible
} syntax, makes understanding and managing these files very difficult
} (such arcania feels like assembly, if not machine, language
} programming).]
} 
}-- End of excerpt from Bradford Castalia

	Well, on this front, I have to give one of those marvelous 
	"yes and no" responses.  The "down" side:  the fundamental
	UIS syntax and structure is not going to change.  Yes, its
	cryptic, even exceedingly so, and yes, it is inflexible.
	However, we have made a commitment to the UIS the way it
	stands, and will be sticking with it in the future. A few
	modifications for Khoros 2.0 will require an update of UIS files.

	The "up" side:  Khoros 2.0 will have *much* better error
	checking than Khoros 1.0 - hopefully this will help alleviate
	some of the problems with the UIS.  Also, we have managed to
	eliminate a great deal of the order/position dependancies
	(ie, conductor-generated code depending on the position of
	a UIS line to work correctly).  But, -g and -P lines are still
	matched by their order of appearance.  The only way (i can
	think of) to do this otherwise is to require a variable on
	the -g line that must match the variable of its corresponding
	-P line *exactly*.  If we implement this for Khoros 2.0, however 
	=> backwards compatibility of UIS files becomes difficult to
	provide.  Opinions, please?  Or other ideas?

	Something else to look forward to: we are planning to develop 
	(probably not in the first release of Khoros 2.0, however) 
	a direct-manipulation GUI builder.  When this direct-manipulation 
	GUI builder is available, the user will no longer need to have much, 
	if any, manual interaction with the UIS file -- thus eliminating any 
	problems stemming from its complexity or unreadability.  
	
		~ danielle

       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
       ~   Danielle Argiro - danielle@bullwinkle.eece.unm.edu   ~
       ~   Software Design & Development, The Khoros Group      ~
       ~   Room 110, EECE Building, UNM;  Albq, NM 87131        ~
       ~                                                        ~
       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~