jsparkes@bwdls49.bnr.ca (Jeff Sparkes) (02/03/91)
I'm having a problem with Wcl thats a bit um, difficult to work around. There are two instances of the problem; I'll start with the simpler one first. Wcl programming is done on a callback basis, right? The problem is that an Xaw dialog has no callback. What I really want to do is have a callback in the OK button which says "call callback X with the value of the text field". It would probably be useful in some cases to specify the "src" widget for the callback. This is more generally applicable too. I have a list widget in which I select a field; then a command button is clicked which wants to call a callback with the value of the list widget. This seems to require a change in Wcl, to add a function to get the value of a widget. This would be something like WcRegisterValueFunction(). Or have I missed something obvious? -- Jeff Sparkes jsparkes@bnr.ca Bell-Northern Research, Ottawa (613)765-2503 Another feature is that the seats float, so that the airline can recover them if the plane crashes into the ocean. -- Dave Barry
rlh2@ukc.ac.uk (R.L.Hesketh) (02/04/91)
In article <jsparkes.665548362@bwdls49> jsparkes@bwdls49.bnr.ca (Jeff Sparkes) writes: > Wcl programming is done on a callback basis, right? The problem is >that an Xaw dialog has no callback. What I really want to do is have a >callback in the OK button which says "call callback X with the value of the >text field". It would probably be useful in some cases to specify the >"src" widget for the callback. If the OK button is a commandWidget then the callback is "callback". Callbacks can be passed the name of a widget as a string argument: *loadDialog.okButton.callback: load_file(*loadDialog.value) The load_file callback would be bound using: WcRegisterCallback(app, "load_file", load_file, NULL); and when called the client_data is a string "*loadDialog.value". This can be converted into the the Widget id using: void load_file(w, client_data, call_data) Widget w; XtPointer client_data, call_data; { Widget id = WcFullNameToWidget(w, (char *)client_data); ... } > This is more generally applicable too. I have a list widget in >which I select a field; then a command button is clicked which wants to call >a callback with the value of the list widget. Again you can pass the widget name as the client data. What would be useful is a GetValues interface for Wc which already has WcSetValuesCB() and WcSetValuesACT(). However to get an equivalent WcGetValuesCB() which would return a string when used in something like: fred.callback: do_something(WcGetValuesCB(*valueEntry.value)) the addition of TypeToString converters would be required for all the different application resource types. This would also be very useful for UI Builders etc but I fear we have missed the boat on this one. Richard
marbru@attc.UUCP (Martin Brunecky) (02/05/91)
In article <jsparkes.665548362@bwdls49> jsparkes@bwdls49.bnr.ca (Jeff Sparkes) writes: > > I'm having a problem with Wcl thats a bit um, difficult to work around. > There are two instances of the problem; I'll start with the simpler > one first. > > Wcl programming is done on a callback basis, right? The problem is >that an Xaw dialog has no callback. What I really want to do is have a >callback in the OK button which says "call callback X with the value of the >text field". It would probably be useful in some cases to specify the >"src" widget for the callback. > This is more generally applicable too. I have a list widget in >which I select a field; then a command button is clicked which wants to call >a callback with the value of the list widget. > This seems to require a change in Wcl, to add a function to get the >value of a widget. This would be something like WcRegisterValueFunction(). > > Or have I missed something obvious? > May be. First of all, Wcl does NOT try to do EVERYTHING. It does provide lots of convenience callbacks for frequently used operations (in my opinion just one more would be too many). It does NOT intend to give you (and everyone else) everything. It DOES show you HOW to write your own, special callbacks and/or action routines. It does NOT write your application for you. So, in your particular case, when you can identify your button by the instance name ( *dialog_box.button ), you can attach to it your very OWN, very specific callback: CallCallbackWithTextCB ( callback_name, text_widget_name ) Inside of this callback, you can call XtDirectConvert to translate callback_name into a callback list (callback list structure is public, you can use it to call the callback, or you may use XtCallCallbackList). You can also translate the tex_widget_name into widget ID (Either using XtNameToWidget OR the Wcl's enhanced functions, see WcName.c), querry the text, and THEN use XtCallCallbackList or simply call the callback directly. Note that at LEAST the Text widget querry is VERY widget set SPECIFIC. Also, your need(s) is(are) somewhat specific. Indeed, it is a very good idea: writing callback that can call another (already existing callbacks) by name. I am doing similar things ( callbacks activated when rubberbanding starts set-up the callback to activate when ribberbanding ends...). However, Wcl tries to be KISS and Widget Set INDEPENDENT. Provide the basic support needed by EVERYBODY, but NOT overwhelming Wcl users with hundreds callbacks most of which will be specific to a particular application. That should explain WHY a direct suppoprt for your callback should NEVER be part of Wcl. Though, indeed, it IS a good idea. -- =*= Opinions presented here are solely of my own and not those of Auto-trol =*= Martin Brunecky {...}sunpeaks!auto-trol!marbru (303) 252-2499 (sometimes also: marbru@auto-trol.COM ) Auto-trol Technology Corp. 12500 North Washington St., Denver, CO 80241-2404