fineberg@ANTARES.MCS.ANL.GOV (07/06/89)
How do I tell which button has been pressed within the callback routine of a command widget. Also, is it possible to call different routines depending on which button has been pressed. Sam Fineberg fineberg@mcs.anl.gov
argv%eureka@Sun.COM (Dan Heller) (07/07/89)
In article fineberg@ANTARES.MCS.ANL.GOV writes: > How do I tell which button has been pressed within the callback routine of > a command widget. Also, is it possible to call different routines depending > on which button has been pressed. You can't. However, since the call_data of the callback routine is NULL, one would think (nudge nudge) that the implementors of the command widget would pass something -useful- (wink wink) in its place.... like a pointer to (or a copy of) the event struct which initiated it.. This is a hint to widget-writers. If you're going to call XtCallCallbacks from inside your widget, please take care to pass useful information in the call_data parameter. NULL is not useful. If nothing else, pass the event structure since the callback function has no idea what happened to cause the callback to be called. dan <island!argv@sun.com> ----- My postings reflect my opinion only -- I represent no company's opinions.
kit@EXPO.LCS.MIT.EDU (Chris D. Peterson) (07/07/89)
> In article fineberg@ANTARES.MCS.ANL.GOV writes: > > How do I tell which button has been pressed within the callback routine of > > a command widget. Also, is it possible to call different routines depending > > on which button has been pressed. eureka!argv@sun.com (Dan Heller) writes: > You can't. However, since the call_data of the callback routine is NULL, > one would think (nudge nudge) that the implementors of the command widget > would pass something -useful- (wink wink) in its place.... like a pointer > to (or a copy of) the event struct which initiated it.. Actually the call data for the command widget is Undefined, the current implementation just happens to be NULL :-) The answer to the original question is that there is no way to determine which button was pressed from inside the callback routine, and the fact the the event is not passed is not a bug, but a feature. This helps to abstract the functionality of the program away from its feel. If you want to have two seperate actions taken on the command button it is possible, it is just not supported by the command widget's notify proceedure and callback list. The correct way to code something like that is to define a couple of global application action proceedures (ActionOne and ActionTwo) with XtAppAddAction(). Then bind these actions to a set of default events using a translation table in your application's app-default file. test*foo.translations: #override \ <Btn1Up>: ActionOne() unset() \n\ <Btn2Up>: ActionTwo() unset() This way the user is still able to bind these actions to other mouse buttons, or even key presses if he wants that behavior. I have personally found the action routines to be much more flexible than the callback mechanism and have gone to using them almost exclusively in my applications. > This is a hint to widget-writers. If you're going to call XtCallCallbacks > from inside your widget, please take care to pass useful information in > the call_data parameter. NULL is not useful. I disagree. I would not like to see any widget writer just randomly pass through information that breaks the abstraction barrier of his/her widget set. Just because the application writers have not read the manual about the use of action proceedures. > If nothing else, pass the event structure since the callback function has no > idea what happened to cause the callback to be called. GOOD. I don't see why it has to know anyway. If an application writer is using the event structure to determine which action to take then she/he is breaking the abstraction barrier set up by the Xt Intrinsics Translation management mechanism. And drastically reducing user customizability. Chris D. Peterson MIT X Consortium Net: kit@expo.lcs.mit.edu Phone: (617) 253 - 9608 Address: MIT - Room NE43-213