nick@deccan.dec.com (Nick Tsivranidis) (02/22/90)
OK, so the moral of the story is that there is no CLIENT_DATA attribute in the widgets. Thanks for the many hacks, but I already have an association object that associates 2 kinds of things together (in this case widgets and objects). I was just looking for a better way to do this (use less memory and run faster). Anyway, I guess I would like to register a request that somebody adds this very important attribute to the Core widget class. It can make life (and programming) a lot simpler. - Nick - P.S. Somebody (klee?) said that they think that the Motif widget set has a CLIENT_DATA attribute. Can you be more specific? I can't find it in the doc.
schoeller@kobal.enet.dec.com (Dick Schoeller) (02/22/90)
> P.S. Somebody (klee?) said that they think that the Motif widget > set has a CLIENT_DATA attribute. Can you be more specific? I > can't find it in the doc. > Try XmNuserData. Dick Schoeller | schoeller@4gl.enet.dec.com Digital Equipment Corporation | 603-881-2965 110 Spit Brook Rd., ZKO2-3/R56 | "Either Judaism has something to say to the Nashua, NH 03062-2642 | world or it has nothing to say to Jews." | - Dennis Prager
klee@wsl.dec.com (Ken Lee) (02/22/90)
In article <8542@shlump.nac.dec.com>, nick@deccan.dec.com (Nick Tsivranidis) writes: > P.S. Somebody (klee?) said that they think that the Motif widget > set has a CLIENT_DATA attribute. Can you be more specific? I > can't find it in the doc. According to my Motif manual, all the basic object classes (i.e., XmGadget, XmPrimitive, XmManager) except Shell have a XmNuserData resource of type caddr_t. You can put a pointer to anything you want in here. This resource is inherited by all the non-shell Motif widgets and gadgets. DECwindows Toolkit widgets have a similar resource called DwtNuserData. According to the DECwindows manual, this "specifies any user private data to be associated with the widget." Ken Lee DEC Western Software Laboratory, Palo Alto, Calif. Internet: klee@wsl.dec.com uucp: uunet!decwrl!klee
davidh@dent.Berkeley.EDU (David S. Harrison) (02/22/90)
In article <8542@shlump.nac.dec.com>, nick@deccan.dec.com (Nick Tsivranidis) writes: > > OK, so the moral of the story is that there is no CLIENT_DATA > attribute in the widgets. Thanks for the many hacks, but I > already have an association object that associates 2 kinds of > things together (in this case widgets and objects). I was just > looking for a better way to do this (use less memory and run faster). Please be careful when you ask for a feature like this -- you might get it! It turns out most people assume you can implement this by adding a pointer to the structure and forgetting about it. Unfortunately, this isn't sufficient. Imagine you have a program composed of multiple packages. Each one would like to associate data with widgets. Oops, with only one pointer field these packages will trounce on each other. Some designers then react by adding more generic pointers to the structure. Now these packages have to have some protocol for choosing which pointer they use. Further, those applications not using these associations pay for the memory consumed in all cases. Another alternative is adding a list of generic pointers to the structure each keyed by some sort of context identifier. However, now the lookup of this information is no longer a simple dereference but a linear lookup (albeit a short one on average) and all widgets still have this linked list field even though information is rarely associated with all of them. A common alternative is to implement a hash table that looks up client specific information given a reference to the widget. It is not that much slower than the linear lookup and only consumes memory for associations actually used. We have now arrived full circle back to the current implementation supplied by X: context tables. I can imagine other implementations that might be better but I don't think the added complexity is warranted unless the association table is shown to be the bottleneck in your application. In any case, I don't think the correct solution is to jump in and add a field to the core widget structure. David Harrison UC Berkeley Electronics Research Lab (davidh@ic.Berkeley.EDU, ...!ucbvax!ucbcad!davidh)