if you called it cause it is current how come ya dont know?

Post #27,499 by boxley 2/6/02 10:38:27 AM Reply	if you called it cause it is current how come ya dont know? need a better idea of what yer trying to do. thanx, bill "If you're half-evil, nothing soothes you more than to think the person you are opposed to is totally evil." Norman Mailer
Post #27,509 by jb4 2/6/02 12:12:16 PM Reply	I'm an error library, and I don't know which proc called me I can be called from any number of processes, and I generally do the same thing everywhere, except when I'm called from our GUI manager. I need to know that I'm in the GUI manager proc, so that I don't do anything...er, stupid... I do NOT have access to the command line, so argv[0] is out. Any ideas? jb4 (Resistance is not futile...)
Post #27,528 by kmself 2/6/02 2:14:04 PM Reply	GUI detection Check the value of $DISPLAY. If it's not set, you're safe to assume a non-GUI environment, though you might want to check to see if you're attached to a terminal or not. If $DISPLAY is set, you'd then do an appropriate GUIfied response. If that fails, say because $LUSER is an idiot and isn't running an actual X11 session, then you would abort miserably, complaining loudly to stdout with a nonzero exit status. Of several programs I've looked at lately, testing $DISPLAY to see that there is/isn't a GUI session attached is occasionally omitted. It's a seriously brain-dead mistake. SAS does it in its v8/v9 incarnations. The user has to provide an extra flag to the program to tell it it's not in an X11 session. This is Bad Code™ `-- Karsten M. Self [link\|mailto:kmself@ix.netcom.com\|kmself@ix.netcom.com] [link\|http://kmself.ix.netcom.com/\|[link\|http://kmself.ix.netcom.com/\|http://kmself.ix.netcom.com/]] What part of "gestalt" don't you understand?`
Post #27,888 by ben_tilly 2/9/02 12:47:27 AM Reply	Stupid but reliable solution Have the error library have an internal flag for this, which defaults false, but which can be reset. When the GUI application starts, have it set the flag. Yeah, yeah, it is a global. So are environment variables. And some day you may have your application called from a process that inherited an environment from an unrelated GUI. (But you are backgrounded.) Globals which are shared across processes are worse than globals inside of processes... Cheers, Ben
Post #28,009 by jb4 2/11/02 9:24:39 AM Reply	I'm not that doctrinare... ...but I would try to keep globals to a minimum. There is precedent for such a solution in this system, however, so it wouldn't be hard getting it past a code inspection. Thanks for the input, Ben. jb4 (Resistance is not futile...)

Welcome to IWETHEY!