Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!rutgers!husc6!cfa!wyatt From: wyatt@cfa.UUCP Newsgroups: comp.windows.x Subject: Re: Re: Problems with XGetDefault() and Xrlib? Message-ID: <527@cfa.cfa.harvard.EDU> Date: Fri, 8-May-87 11:14:39 EDT Article-I.D.: cfa.527 Posted: Fri May 8 11:14:39 1987 Date-Received: Sat, 9-May-87 08:32:51 EDT References: <3940010@hpcvlo.HP.COM> Organization: Harvard-Smithsonian Ctr. for Astrophysics Lines: 33 > > I do not claim first hand knowledge of this situation, But somebody > here (HP-corvallis) did look into the situation. It turns out the > defect is likely to be a design defect in the XGetDefault() library > routine. Here's what I've been told: > > The XGetDefault() routine saves the first instance of the program > argument. Then XGetDefault uses this saved initial instance of your > program name string for all subsequent calls. [...] > [...] you were locked out from calling XGetDefault() using any > other program name. This is clearly an example of a routine doing > extra work that is not desirable. I've looked into it too, and it doesn't work quite that way. What happens is that the data base (/lib/X/Xdefaults, then ~/.Xdefaults) is opened and read onthe *first* call to XGetDefaults. All lines beginning with `.', or with the first string given (usually argv[0]) are read and put into a binary tree for subsequent searching. Thus, subsequent calls do not re-read the database file, and are very fast at finding the information, which is very good, but there is NO WAY to re-open the file to get another database set with a different identifier string. There is also no way (other than a symbolic link ahead of time) to look anywhere besides ~/.Xdefaults or /lib/X/Xdefaults. I believe the V11 resource manager addresses these problems. -- Bill UUCP: {seismo|ihnp4}!harvard!cfa!wyatt Wyatt ARPA: wyatt@cfa.harvard.edu (or) wyatt%cfa@harvard.harvard.edu BITNET: wyatt@cfa2 SPAN: 17410::wyatt (this will change in June)