DATE FILE(S) DESCRIPTION =============================================================================== 5aug99 nbrowser.c Yet another for the "how could this ever have worked?" file. Read it and weap. In RSLBroser::EnumTFiles and ::EnumGFiles, the implemenation was return Xfilelist->Enum()->GetData()->ConstConvert(); for X = t or g, respectively. I.e., we're simply passing the Enum buck down to StrList::Enum. But hey, idiot, when Enum() returns NULL, just as it should at the end of the list, what then does Enum()->GetData() return? DUH!!! The appropriate fix is thus StrListElem* sle = Xfilelist->Enum(); if (sle) { return sle->GetData()->ConstConvert(); } else { return NULL; } Now, as to how this ever worked, the context is that we've changed to the new list classes, and so somehow the old imple of the local list classes must have let this code get by somehow. Exactly how I can't really figure, but such is the world of C++. 10mar99 several Changed use of old list classes to the support lib list classes. Initially, the appropriate code changes were made, but it didn't work. After some updates to the support list class, specifically removing the pure virtual functions and giving them default noop implementations, things were made to work, as described in the 5aug99 entry above. For details of the support list updates, see the LOG file there. 21nov98 ? This is more on the recurring problem of line and char positions being off. Run on *.rsl in classes/205/ grades/comm-front-0030/m7-specification/*.rsl. When the 3rd and 4th lines of Connect in the 'Operations' list are selectd, the display is off by one line (as we've seen before) in the telnet.rsl file window. Also, when the 4th line of Connect is selected, the 3rd line in the 'Operations' list is also (erroneously) selected. These would seem to be at least somewhat related problems, and both need to be fixed. 5dec97 Makefile Added -lgen flag to link in Solaris regex library. Also added -DSOLARIS so that std-macros++.h would not declare bool. 22apr93 sted.h Commented out #include . For some reason, this include was causing the following conflict: /Net/blackbird/home/gfisher/441/examples/iv/text-edit/sted.c In file included from /usr/pkg/gnu/lib/g++-include/sys/stat.h:7, from /Net/blackbird/home/gfisher/441/examples/iv/text-edit/sted.h:66, from /Net/blackbird/home/gfisher/441/examples/iv/text-edit/sted.c:4: //usr/include/sys/stat.h:90: conflicting types for `unsigned short int umask (...)' This does NOT occur when sted is made by itself in the iv/examples/text-edit dir. Evidently, somewhere earlier stat.h must get included in the context of building the browser. I could not spot where this happened, and removing the include of stat.h seems to fix things, so we leave it at that (for now). browser.{h,c} Reencountered (and solved) the problem of a class derived from Tray not being able to declare any VBox's or HBox's in its member functions. The f---ing piece of s--- tray def has its own member functions named VBox and HBox, who the f--- knows why. Hence, any use of VBox or HBox as type names in a member function freaks the compiler out -- it thinks you're trying to use a member function name as a type name. Never mind that the compiler could give a better error msg in this circumstance, that the iv lib declares such fucntions in Tray is TOTALLY BOGUS. 10may93 menu* The behavior of the menus was bogus. Specifically, button-down in the bar didnt work as it should. In order to have the pulldown appear, you had to buttondown on the pulldown name in the bar, leave the name in the upward direction, the reenter the name. Then, once the menu was up, the items didnt work as they should. They blinked *very* quickly usually imperceptibly) when entered, but didnt stay black. The fix was to install the n*.{h,c} files directly into the pkg version of libivX11.a. Apparently, there were linkage problems using the selected local .h and .o files, while trying to link with the rest of the lib. I suspect the cruxt of the prob was that lib files linked to the orig menu.h, box.h, and scene.h, while the browser linked to the local versions. Even with no globals in the orig .h's, function and member offset must have been screwed up, leading to bogus behavior. Lesson: In general, it remains unclear with gnu how to replace lib code, particularly extant .h's, with local code safely, where safely means that extant lib.a was linked with the orig .h's and the local .o's are linked to the new .h's. It may not be possible (or even desirable) to do this at all, but I have not thought it out completely clearly yet. 12may93 rstrbrowser.c In EntityStrBrowser::Handle, we must check, essentially, that e.target = this before calling UpdateCurEntity. This is done actually by checking if done = false. The reason for this is that we stay in this (and most other) handlers "one click too many". I.e., the event loop in this Handle keeps going until e.target != this. But, this condition is caught while still in the version of Handle that should not handle the event. To account for this, as soon as e.target != this, the event is Unread, done is set to true, and the handler exits, so that whatever other handler is active will handle the unread event. Given this, it would be an error to call UpdateCurEntity unless done == false. Unfortuneately, this error manifests itself in a rather subtle way. Viz., if we click successively on the obj str browser, thence the op str browser, thence back to obj, we're still in op's Handle until we recogize that e.target != this. And, in this state, Selection(0) returns -1, since evidently, the str browser somehow goes unselected when we leave it. I suppose we really can't expect better behavior from Selection in this case, but the error was, as noted, subtle. Lesson: iv event handling is subtle and (necessarily?) fragile. It's not clear if other event handling systems are as bad, but I think much of the fragility may be due to C++. This is probably my anti-C++ bias showing thru. 12may93 rtexted.c Took out the following from EntityTextEd::ScrollToName, since it meant that if the user manually scrolled the text ed (i.e., with a scroll bar), the currently selected entity would not be moved back to if clicked again (get it?): /* * If the given entity is the one currently displayed, we're outta * here. if (curSym == newSym) return this; 24may93 browser.{h,c} Added RSLBrowser::Run. See the comment in browser.h main.c for complete details and rationale. 7jun93 lstrbrowser.{h,c}Added complete new version of iv's StringBrowser, in order to add functionality for horz scrolling. This most likely could be done the "right way" by specialization instead of copying, but let's just do it for now. Major hack in lstrbrowser.c is maxwidth = p->width = l * stdfont->Width("n") / 4; where in particular the / 4 is just an empirical number that makes the horz scroll bar size correctly. Obviously should be fixed.