Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!elroy.jpl.nasa.gov!ncar!ico!attc!marbru From: marbru@attc.UUCP (Martin Brunecky) Newsgroups: comp.windows.x Subject: Re: Was None now XtSetValues Message-ID: <947@attc.UUCP> Date: 2 Jan 91 18:39:14 GMT References: <9338@adobe.UUCP> <9012271954.AA07350@iris49.biosym.com> Reply-To: marbru@auto-trol.UUCP (Martin Brunecky) Organization: Auto-trol Technology, Denver Lines: 47 In article <9012271954.AA07350@iris49.biosym.com> pete@iris49.UUCP (Pete Ware) writes: >Also, the widget writer is the one that determines if XClearArea() is >called. If the update is critical and happens frequently (a digital >readout in a complex display that the application controls, for example) the >SetValues() function can update that one portion of the display: > > if (oldWidget->timeBar.start_time != current->timeBar.start_time) > { > if (XtIsRealized (current)) > { > NewTime (current, oldWidget); > redisplay = FALSE; > } > else > { > redisplay = TRUE; > } > } > return redisplay; But the solution above does not help if you are subclassing off of something you can't change (Motif widget, for exmaple) and it's SetValues already says redisplay = TRUE. Unfortunatelly, XtSetValues only ORes results of calls to set_values method traversing down the class hierarchy. May be some "special value" of the set_values return (XtSetValues "NEVER") could do the trick in this case .... Note, it sounds like a hack. It is a hack. But the more people start subclassing off of (other people's) widgets WITHOUT modifying those, the more often they will find they have to UNDO (some) results of the superclasses operation (initialize, set_values). And this is just such an "undo". -- =*= 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