rmartin@clear.com (Bob Martin) (04/03/91)
Here is a question for all you X gurus. It was given to me by a freind of a freind. Please mail any replies to me and I will summarize in a week or so. Thank you..... And now for the question: I call XInternAtom(display, name, only_if_exists) with only_if_exists == False. This call will sometimes return None, but the book says that if only_if_exists == False it should always return a valid atom. Q: Does anybody know if it si valid under some condition for XInternAtom to return None? Thanks in advance.... -- +-Robert C. Martin-----+:RRR:::CCC:M:::::M:| Nobody is responsible for | | rmartin@clear.com |:R::R:C::::M:M:M:M:| my words but me. I want | | uunet!clrcom!rmartin |:RRR::C::::M::M::M:| all the credit, and all | +----------------------+:R::R::CCC:M:::::M:| the blame. So there. |
mouse@lightning.mcrcim.mcgill.EDU (der Mouse) (04/04/91)
> I call XInternAtom(display, name, only_if_exists) with > only_if_exists == False. This call will sometimes return None, but > the book says that if only_if_exists == False it should always return > a valid atom. > Q: > Does anybody know if it si valid under some condition for > XInternAtom to return None? Certainly if only_if_exists is True. If not, I don't think so, but can't be entirely certain. The Xlib document says The XInternAtom function returns the atom identifier associated with the specified atom_name string. If only_if_exists is False, the atom is created if it does not exist. Therefore, XInternAtom can return None. [...] The protocol document says InternAtom [...] This request returns the atom for the given name. If only-if-exists is False, then the atom is created if it does not exist. [...] Nowhere does it explicitly say that None is forbidden when only-if-exists is False, but there is to my mind a very strong implication to that effect in both documents. I'd say you have a bug, in either your program (ie, you're not really passing False), your Xlib (ie, it's passing the wrong values to the server or reporting the wrong value back to you), or your server (mishandling the request). Without more information I can't really do more than make wild guesses which. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu