[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference bulova::decw_jan-89_to_nov-90

Title:DECWINDOWS 26-JAN-89 to 29-NOV-90
Notice:See 1639.0 for VMS V5.3 kit; 2043.0 for 5.4 IFT kit
Moderator:STAR::VATNE
Created:Mon Oct 30 1989
Last Modified:Mon Dec 31 1990
Last Successful Update:Fri Jun 06 1997
Number of topics:3726
Total number of notes:19516

393.0. "window widget input needed" by NEXUS::B_WACKER () Mon Mar 13 1989 13:09

If this is a repeat, stupid or whatever, please excuse because we've 
had a 1 week programming overview class, no time to really work with 
it and now have to support customers who've been doing nothing but 
decwindows for the last year.

Problems are with a WINDOW widget within a scroll window within a 
popup dialog box.  V5.1.

First, he says the callback structure for an expose event is wrong 
with some large number for reason,0 for event, and a large number that 
looks like window.  He's sending code to reproduce, but if it is a known
bug/fixed we'd like to know.

Second, he needs to get mouse position and clicks from a Window widget
and has not been able to coax it out.  He's not inclined to make his 
own widget, so does anyone have any pointers on what's required to 
change it to accept input?

Third, does anyone have a program that we could use internally to dump 
entire widget data structures so we can see what their xlib level 
characteristics are?

Bruce

T.RTitleUserPersonal
Name
DateLines
393.1Some answersSDSVAX::SWEENEYRoads? Where we're going we don't need..roadsMon Mar 13 1989 17:5918
Aren't these programming questions supposed to go to
SHPLOG::DECWINDOWS_PROGRAMMING?  Oh, well.

First, this is not a "known bug".  If the code indeed shows the result you
report, then it should be QAR'ed.  Customers, of course, can submit SPR's

Second, he needs to define translations for the window widget.  Check the
documentation for how to define and override the translations.

Third, a program only knows of its own widget structure.  Widgets "live" in the
address space of an application.  Windows on the other hand "live" in the
server and programs exist for examining the servers _window_ tree.  You can't
look at another application's widget instance tree.

Examples of programs which examine their own widget instance tree exist as well.
I wrote one which propagates font and color changes from the top level down to
children and popup children.  That ELKTRA::DW_EXAMPLES.

393.2More specifics, pleaseNEXUS::B_WACKERMon Mar 13 1989 19:4040
>Aren't these programming questions supposed to go to
>SHPLOG::DECWINDOWS_PROGRAMMING?  Oh, well.

Sorry, future questions will go there.  It is coming a little hard and 
fast to get it all figured out ahead of time!

>then it should be QAR'ed.  Customers, of course, can submit SPR's
Will do if it proves out

>Second, he needs to define translations for the window widget.  Check the
>documentation for how to define and override the translations.

He did ADD CALLLBACK and sounded like he knew what he was doing well
enough to have done the supporting calls.  Could you tell me which
calls and in which order you can use to get input from a window
widget. 

>Third, a program only knows of its own widget structure.  Widgets "live" in the
>address space of an application.  Windows on the other hand "live" in the
>server and programs exist for examining the servers _window_ tree.  

Sorry, again, what I'd like is something that runs through the 
application widget tree and shows all the data structures.  The 
reason is that the documentation does not present available options,
where they are appropriate, how they interact, etc.  It is kind of 
like getting an unabridged dictionary indexed by the middle letter of 
the second word of the definition.  We don't have any dedicated time
to actually do programming in decwindows, much less follow the annals
of MIT or the plethora of notes files.  A one week overview and now 
you're and expert in UIL, DWT, and XLIB ain't a real attractive 
approach, but here we are and all suggestions are welcome!

>I wrote one which propagates font and color changes from the top level
>down to children and popup children.  That ELKTRA::DW_EXAMPLES. 

I think that means you walk the whole structure, but only for colors.  
Do you know of anything that dumps the whole shebang?

Bruce

393.3button press input and input focusSMAUG::FLOWERSIBM Interconnect Eng. 226-7716Wed Mar 15 1989 11:1215
>Second, he needs to get mouse position and clicks from a Window widget
>and has not been able to coax it out.  

We've had plenty of luck with:
	XtAddEventHandler( window_widget_id, ButtonPressMask, FALSE,
			   button_press_handler_rtn, 0 );


>so does anyone have any pointers on what's required to 
>change it to accept input?

In the button_press_handler_rtn you'll want to make a call to
XSetInputFocus...


393.4Use the Main Window's Focus CallbackTBD1::BURLEIGHDave, DECwindows TrainingWed Mar 15 1989 12:377
    If you're using a Window widget as the work area in a Main Window
    widget, you can set the Main Window widget's DwtNacceptFocus
    resource to True, and use its Focus callback to transfer the focus
    to its Window widget work area with XSetInputFocus().
    
    Dave

393.5Thank youNEXUS::B_WACKERWed Mar 15 1989 19:052
Thanks all!!  I'll pass it on.