bruce@crock.uucp (Bruce Beisel) (09/18/90)
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. 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. - Bruce Beisel
cflatter@ZIA.AOC.NRAO.EDU (Chris Flatters) (09/18/90)
> 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. There is an (apparently) undocumented function in XView: xv_unique_key() which returns an unused attribute key. Xv_unique_key is used extensively inside XView objects to allocate keys but there are at least two instances (panel and text) where keys are #define'd to 1. I don't know if there is a good reason for these exceptions or whether they are oversites. In practice it makes no difference since xv_unique_key does not return 1 if you have created some XView objects. It is possible that xv_unique_key() is intended for internal use only but it does have uses at the application level. In addition to guaranteeing a unique key for XV_KEY_DATA it is also a good way of assigning client IDs for the notifier. Chris Flatters cflatter@nrao.edu
mike@ste.dyn.bae.co.uk (Mike Heley) (09/18/90)
> 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. I also hit this problem on moving code from XView 1.0.1 to XView 2.0. This code makes extensive use of the XV_KEY_DATA attribute on most of the objects in XView. The keys started off at 1. I found that the panel object in XView 2.0 merrily overwrites your valuable data at KEY=1. > 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. Naahhh! Surely it should just have a bug id! I thought this was for me to use, not Sun. -- Mike Heley mike@ste.dyn.bae.co.uk British Aerospace Dynamics +44 438 752432 Stevenage, UK "Schizophrenic? I'm bleedin' Quadrophenic!" - The Who, 1973. --
argv@turnpike.Eng.Sun.COM (Dan Heller) (09/19/90)
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.