swick@ATHENA.MIT.EDU (Ralph Swick) (05/09/90)
This applies equally well to R4... > XtGetSelectionValue does not inform the caller if there is no active selection. > Instead, it appears to call the callback procedure with a zero length and > NULL value pointer. This is the same result that occurs if there -is- a > selection, but the selection owner cannot convert into the desired target type. I'm going to hide behind the Inter-Client Communications Conventions on this question, too. In both cases the requestor receives the same underlying event; SelectionNotify with property equal to None. If there is no owner, the server generates the event. If there is an owner but the owner refuses the request for any reason, the ICCC require the owner to generate the identical event. The client (library) cannot distinguish the two, so XtGetSelectionValue must return the same result in either case. From an architectural point of view this is reasonable. The TARGETS mechanism allows a requestor to find out what data is available before requesting it. This should be sufficient granularity for most clients; a requestor shouldn't need or want to peek inside the black box to learn why there is no value available if TARGETS returns nothing. -Ralph.
rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (05/09/90)
If there is no owner, the server generates the event. If there is an
owner but the owner refuses the request for any reason, the ICCC require
the owner to generate the identical event. The client (library) cannot
distinguish the two
Actually, it could distinguish by looking at the send_event bit in the event.