costello%nnfvax.DECnet@CHEME.TN.CORNELL.EDU ("NNFVAX::COSTELLO") (06/17/90)
The following certainly falls into the category of naive questions, to which one would hope to find an answer in BIG TYPE in the FMs, but I haven't, nor is it discussed in the Frequently Asked Questions posting, so I will appreciate all responses, including flames, that contain a hint to get me past this block. I've started writing an application using VMS 5.3, DECwindows 2.0, the DECwindows toolkit and the VAX Binding. The various widgets are described with UIL and DRM, and I'm using callbacks from the widgets so defined to accomplish as many things as I can. So far, I've used XT$Main_Loop once things are setup through the Resource Manager, and it all works fine. Here's the rub. I need to respond to events like Motion_Notify, Configure, Button_Press, Button_Release, and the like. I can find plenty of examples of a replacement for Xt$Main_Loop that allows such event processing, but none for applications that make use of UIL/DRM. I've mercilessly edited my Pascal (yes, Pascal) code to show in the following what I believe to be the relevant calls in the order in which they happen: (* Get a handle to the display so we have something to use in the NextEvent call *) display := x$open_display; ... DRM code, including appropriate calls to Dwt$Initialize_DRM, Xt$Initialize, Dwt$Open_Hierarchy, Dwt$Fetch_Widget, Xt$Manage_Child, and Xt$Realize_Widget, all of which works just fine when followed by Xt$Main_Loop. ... (* Code to replace Xt$Main_Loop *) repeat X$Next_Event (display, x_event); Xt$Dispatch_Event (x_event); until (FALSE); As you can see, all I'm trying to do is replace the function that Xt$Main_Loop does so I have a working base on which to add my own event processing. What happens is that the application hangs in the first X$Next_Event call, and none of the widgets ever gets created. It's no big surprise, therefore, that "x_event" never gets filled in - the event type is still 0. I've tried various reasonable parameters in the OpenDisplay call, like "DECW$DISPLAY" and "0::0.0" (remember, in DECnet land, node 0 is always home). I tried "FOO::0.0" to see if OpenDisplay was actually doing anything at all (FOO is >not< a known node, btw), and the program got an access violation on the NextEvent call, which I think meant "display" never got set by OpenDisplay. This different failure mode is the only reason I have for believing that OpenDisplay worked. I will gladly send more details to anyone kind enough to offer advice. Thanks in advance Dennis Costello costello@cheme.tn.cornell.edu costello%nnfvax.dnet@ionvax2.tn.cornell.edu costello%nnfvax.dnet@vax5.cit.cornell.edu (607) 255-2329 days (607) 273-7565 nights