ries@venice.SEDD.TRW.COM (Marc Ries) (12/22/89)
In article <216@venice.SEDD.TRW.COM> ries@venice.sedd.trw.com (Marc Ries) writes: [...] >The problem is, the code doesn't work, at least on our HP 360's >running HP MOTIF under HPUX 7.0. I ran the following code, and >on our system, I still got a pushbutton widget with a full set of >MWM decorations around it?!?!? > >Is it HP MOTIF or me or ???? It's me. But... The problem is you (I) have to RESTART THE WINDOW MANAGER for this program to work... There must be a way to do this WITHOUT restarting the window manager??? Something along the lines of how Young does it in his "monitordata" and "controldata" examples for the HP Widgets in his book _X Window Systems Programming..._ but for MOTIF. -- Marc Ries ries@venice.sedd.trw.com (ARPA) somewhere!trwind!venice!ries (UUCP) #include <std.disclaimer>
gabe@hpcvlx.cv.hp.com (Gabe Begeddov) (12/29/89)
/ hpcvlx:comp.windows.x / david@jpl-devvax.JPL.NASA.GOV (David E. Smyth) / 1:07 pm Dec 27, 1989 / ries@venice.sedd.trw.com (Marc Ries) writes: >[In response to my plea for help, the following code was emailed to >me. > >The problem is, the code doesn't work, at least on our HP 360's >running HP MOTIF under HPUX 7.0. I ran the following code, and >on our system, I still got a pushbutton widget with a full set of >MWM decorations around it?!?!? > >Is it HP MOTIF or me or ???? It works great for me! This is an interesting race condition. Mwm recieves the map request (as a result of the XtRealize). It checks for a decoration property whenever a client window goes from withdrawn to mapped. The client is meanwhile doing a change property for decorations. System dependant behavior follows. There are several things you can do. You can unmap and remap your window in order to guarantee that Mwm will see them, or you can use the XmNdecorations resource of any subclass of VendorShell (in Motif) using the same value that you were passing in to the decorations field of MWM_HINTS. Gabe Beged-Dov