Path: utzoo!attcan!uunet!aplcen!samsung!cs.utexas.edu!sun-barr!newstop!sun!argv From: argv@turnpike.Eng.Sun.COM (Dan Heller) Newsgroups: comp.windows.x Subject: Re: XView XV_KEY_DATA problem Message-ID: <142696@sun.Eng.Sun.COM> Date: 19 Sep 90 00:28:22 GMT References: <1990Sep17.211239.24614@flood.uucp> Sender: news@sun.Eng.Sun.COM Organization: O'Reilly && Associates Lines: 85 In article <1990Sep17.211239.24614@flood.uucp> bruce@crock.uucp (Bruce Beisel) writes: > I just ran into a problem with XView's XV_KEY_DATA attribute. It seems > the XView toolkit attaches data to some of the object it creates. > This is fine until you happen to choose the same key as the toolkit. > I attached a pointer with KEY=1 to a panel which is what XView uses to > attach the panel's private structure. Bingo -- this is a problem that has yet toi have found a resolution. The "proposed" solution is xv_unique_key(), but this is not adequate. The function itself simpley returns the value of a static int that starts at 0 is is incremented upon each call. In your case, you could have called xv_unique_key() and been returned "1" or any other number that may or may not already be used by the xview object in question. ...and that's precisely why I won't document the function. Also, as you've noticed, all of the internal XView functions do not use the function. Unless *everyone* uses that function to generate a key, it's a shot in the dark whether or not the key returned has already been used by someone else. I documented that you should choose sufficiently large and random numbers as keys. Until another *reliable* method is given, it will remain this way. How should this be fixed? The internals for XView should note every time someone has added a key to any particular XView object. xv_unique_key() should take an object as a parameter and return a key that has been guaranteed not to have been used by this object. Therefore, if you add a key_data to an object using "1" or "1001" or the value returned by xv_unique_key(), the key value will be remembered so that the next call to xv_unique_key() will be sure not to return a key currently being used. This way, if you don't use xv_unique_key() but one of your own, you assume the risk of having a key-name clash. Proposed API: int xv_uniq_key(object) Xv_object object; Note 1: the same key may be used across multiple objects without interferring with other objects' data stored by the same key. Note 2: having the "key" used be represented by a global variable defeats the purpose of the key. If you say, extern int menu_key = ???; /* doesn't matter where this value comes from */ Menu menu = ???; xv_set(object, XV_KEY_DATA, menu_key, menu, NULL); You have successfully stored the menu pointer in the key data for the object. However, in order to retrieve that menu later, you need the value of menu_key, so it must be a global variable. Well, think about it.... if you're using a global variable to store a key, then why not use the same global variable to store the menu instead and not bother with the xv_set(), xv_get() and the XV_KEY_DATA stuff altogether. I feel the best solution is for keys to be pre-defined constants such as: #define MENU_KEY 1010101 /* any number */ XView should define a limit where "user key values" are guaranteed not to be used internally by the XView toolkit. If that value was 100 (for example), then you can manage the key uniqueness yourself quite sufficiently. By using constants, you are less likely to create non-unique keys used by XView internally or by yourself in other portions of the application. BTW, this can't be done now because XView uses certain "attribute" enumerated types as "key data" for some objects -- those values are sufficiently large as well. I recommend something in the range between 100 and 10000. > Does anyone know what keys are taken by XView and should therefore be > avoided. I could not find a list in the XView Programming Manual from > O'Reilly & Associates. There is no list since this information is not guaranteed to be the same across all invocations. -- dan ---------------------------------------------------- O'Reilly && Associates argv@sun.com / argv@ora.com Opinions expressed reflect those of the author only.