Path: utzoo!attcan!uunet!lll-winken!ames!mailrus!tut.cis.ohio-state.edu!bloom-beacon!ESOSUN.CSS.GOV!pete From: pete@ESOSUN.CSS.GOV (Pete Ware) Newsgroups: comp.windows.x Subject: Translation management problems Message-ID: <8903282222.AA02129@munin.css.gov> Date: 28 Mar 89 22:22:23 GMT References: <8903282031.AA00400@DORA.MIT.EDU> Sender: daemon@bloom-beacon.MIT.EDU Organization: The Internet Lines: 56 >Date: Tue, 28 Mar 89 15:31:43 EST >From: Chris D. Peterson >> Unfortunately, when I do so some widgets loose (sic). For example: ^^^^^ Sorry for the typo, it does make it rather difficult to read. >>xman -xrm '*Translations:#overrideAlt_R: Help()' >I am surprised that this works at all, the specification states that >there must be a "\n" after the directive (#override in this case). >That might help things work better. In section 10.3 when talking about the string-to-translation resource converter, it says: As an option, you can specify a number sign (#) as the first character of the table followed by ``replace'' (default), ``augment'', or ``override'' to indicate whether to replace, augment, or override any existing table. So it looks like it does not need a '\n' for the directive (the source confirms this). Even with the '\n' it still didn't work. >Also, where is this action defined? The toolkit will look in each >widget's action list from subclass to superclass order, then look in >the application's action list. If it cannot then find the action it >will print a warning message. "Help()" is not defined. It's an action in a program I'm writing. I just used "xman" as an example so others could repeat the problem. Try it and see if you can develop a hypothesis as to what is going wrong. >One side effect that may cause you problems is that you have just told >all of your widgets to look for key press events, this means that it is >no longer possible for child windows to pass events up to their parents. >Some applications may depend upon this behavior. Just a word to the >wise. > > Chris D. Peterson Yes, this is a problem and one I knew of. I think the toolkit and the protocol are inconsistent in that translation management talks about individual events, like "Alt_R" but selecting for an event causes like event's (any other keypress) not to go to the parent widget. It would be better (or at least more intuitive) if events worked their way up the widget hierarchy until some widget had an action for that event or the top of the hierarchy is reached. Note I'm talking about widgets and not windows. --pete esosun!pete@seismo.CSS.GOV (Pete Ware) (619) 458-2520 {seismo,ucsd,uunet}!esosun!pete