Path: utzoo!attcan!uunet!mcsun!ukc!cam-eng!nhr From: nhr@eng.cam.ac.uk (N.H. Russell CUED) Newsgroups: comp.lang.eiffel Subject: Re: Usage of winpack library classes. Message-ID: <15879@rasp.eng.cam.ac.uk> Date: 24 Oct 90 16:28:08 GMT References: Sender: nhr@eng.cam.ac.uk Organization: Cambridge University Engineering Department, UK Lines: 36 I attempted to use the WINPACK library to write an interactive interface to some artificial neural network software. Although the package should in principle be very useful in building screen based interactive interfaces with nested menus, I found the package quite difficult and cumbersome to use for reasons I outline below. As the documentation suggests this package is not as polished as the remainder of the Eiffel library. Also the class documentation describing how text is displayed in a window is wholly inadequate. (I have not yet tried the TEXT_EDITOR class.) In fact the whole mechanism of updating the text associated with a window is inadequate --- it is only suitable for text that does not change very often since the only simple and reliable way to update text and ensure it is displayed properly is to bodily update the textual attribute with `associate_text'. (In order to incrementally update the textual attribute and display it I had to plough through the Eiffel sources, and the method turns out to be messy.) What is required is the facility to treat a text window as a pseudo-terminal, integrated into the i/o library so that it is a descendant class of a generic STREAM base-class, after having restructured the FILE class so that it is centred on such a STREAM base-class. This would enable conventional i/o via read/write calls to be performed on a window, and new lines would cause the text to scroll (by default) when a window is full. I haven't yet been able to determine whether it is possible to have scrolling text in a WINPACK window. I also discovered the following bug: Text with an empty embedded line causes the call to "twt.sub_string(start_pos, end_pos-2)" at line 168 to fail. A prior check for an empty line: "if start_pos <= end_pos-2 then ..." cures the problem.