HDTenEightyP/NetNews huggingface dataset:
From: hellmann@cs.scarolina.edu (Douglas R Hellmann)
Subject: Re: Implementing a Modal dialog that returns a value.
Organization: USC  Department of Computer Science
Date:  8 Sep 92 12:20:53 GMT

jck@kimba.catt.citri.edu.au (Justin Kibell) writes:

>If anyone could help me with this problem. Modal dialogues are fine. I want the
>dialogue to be used like a function returning a value - therefore it must wait
>for the answer as a result of pressing a done or cancel button on the dialog.
>ie: if (AskUser == True) do da do da

The project I am working on uses modal error dialogs, we don't return a value 
or anything, but that should be doable with your callback data.

>code fragments ..
>    create dialog and set it to FULL_APPLICATION_MODAL ....
>    set up a callback on buttons ..
>    app <- application context of main shell
>    while (fr_answer == (int) 99)
>        XtAppProcessEvent (app, XtIMAll);    <- sometimes sticks here ??? :-<
>    return(fr_answer);
>callback ..
>    this changes the value passed via client data to either 1 or 0
>    depending on which button was pressed on the dialog.

>jck@jaguar.catt.citri.edu.au	XMelba - SDL GR 88 - Case tool project.

Here is what we do:

/* Global pointer to the error dialog */
static Widget G_error;

/* Global flag telling error() if the user has pressed the OK button */
static Boolean G_keep_grab;

/* Callbacks */
static void init_error();        /* initializes the global pointer and flag */
static void behave_modally();    /* callback that unmanages the dialog */

void error(str)
char *str;
{
   XEvent         event;
   Arg            args[1];

   G_keep_grab = True;
   XtSetArg(args[0], XmNmessageString,
                     XmStringCreateLtoR(str, XmSTRING_DEFAULT_CHARSET));
   XtSetValues(G_error, args, 1);

   XtManageChild(G_error);
   XtAddGrab(XtParent(G_error), True, False);

   while ( G_keep_grab || XtPending() )
   {
      XtNextEvent(&event);
      XtDispatchEvent(&event);
   }
}

Hope this helps.

Doug Hellmann
hellmann@cs.scarolina.edu
Newsgroups: comp.windows.x.motif
From: drand@spinner.osf.org (Douglas Rand)
Subject: Re: Q: How Do I Reparent A Widget?
Organization: Open Software Foundation
	<BRENNAN.92Sep9010412@yosemite.hal.com>
Date: 9 Sep 92 10:53:26

In article <BRENNAN.92Sep9010412@yosemite.hal.com> brennan@hal.com (Dave Brennan) writes:

   The short answer is that you don't.  Under Xt widgets really aren't meant
   to be reparented once they are created.  Have you considered creating two
   forms and managing only the one you need to see?

   The long answer is that if you're really determined and have a lot of time
   to track down and work out strange problems it can be done.  This is a
   terrible hack anyhow, typically reserved for implementing Motif tear-off
   menus.  You really don't want to bother.

Let me add why.  When the widget is created,  the parent is examined
to see if it is a constraint widget.  Constraint widgets add resources
to the widget instance,  and thus the Intrinsics (unfortunately) 
allocates a larger block of memory.

To reparent,  it would be necessary to realloc the memory to get a larger
block, sometimes, depending on the new manager parent.  It would have
been better if the Intrinsics had allocated the constraint record
separately and destroyed it separately.

As far as I know,  this is the major reason that reparenting cannot
be currently implemented in the Intrinsics.

--
Douglas S. Rand <drand@osf.org>		OSF/Motif Dev.
Snail:         11 Cambridge Center,  Cambridge,  MA  02142
Disclaimer:    I don't know if OSF agrees with me... let's vote on it.
Amateur Radio: KC1KJ
From: rph@fox.frame.com (Ron Hughes)
Newsgroups: comp.windows.x.motif
Subject: Re: Q: Help with XtAppAddInput
Date: 11 Sep 92 17:34:16 GMT
Distribution: inet
Organization: The Internet

> I have a X/Motif program which needs to monitor and read from a file which
> is open for writing by another application.
> 
> What I think I'm supposed to do is use XtAppAddInput() to monitor the file
> and then do a callback when the file has been written to.  
> 
> But what I've gotten to "work" is terribly hacked up.  And it  increases
> the load on my machine by what seems to be too much.

You should not be using XtAppAddInput() for this job.

A lot of people think that XtAppAddInput() is a way of causing a
routine to be called when there is more data available.  That's the
wrong way to think about it.

vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
Try this:  XtAppAddInput() will cause a routine to be called
if your file descriptor is in such a state that a read system
call on that file descriptor would not block.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

So if your file descriptor is associated with a pipe or socket
and the other end has closed or gone away, a read would not
block (it would immediately return zero, indicating end-of-file),
so your routine will be called.  If you don't recognize and deal
with the EOF situation, then after you return, the other end is
still closed, a read would still immediately return zero, your
routine will get called again, etc.

Similarly for normal files.  If you've read the whole file and you've
reached the end of the file, then if you were to issue a read system
call it would immediately return zero (EOF), so since a read would
not block your routine will be called.  If you then discover there's
actually no data but just return without dealing with the fact that
you've reached the end of the file you'll do it all again and again
and again.  Note that XtAppAddInput() never ever makes sense for a
file descriptor associated with a normal file, because a read system
call would never block on a normal file (it doesn't even matter
whether or not you've reached the end of the file).  (The only
reasonable exception I can think of is if file or record locking
is taking place, which could indeed cause a read to block).

Another fun way to hose yourself is if you decide to close YOUR end of
a pipe or socket connection you've previously called XtAppAddInput()
on.  What do you think would happen if you were issue a read system
call on a file descriptor you've just closed?  (HINT: it wouldn't
block!)

The right tool for your job is XtAppAddTimeOut().

- --Ron	(rph@frame.com)
From: otsatya@uts.amdahl.com (O. T. Satyanarayanan)
Newsgroups: comp.windows.x.motif
Subject: UIM/X vs TeleUse
Summary: request for comments
Date: 10 Sep 92 18:55:28 GMT
Organization: Amdahl Corporation, Sunnyvale CA

I am posting this for a friend. Please send all replies to the address given
at the end of the article. 

Thank You.
-Satya

-----------------------------

Greetings,

I'd like to know people's opinions on UIM/X vs TeleUse, hopefully
from those who have used both.  Which is better, and why?

Thanks in advance...


Please send replies to:  bijan@mickey.disney.com

------------------
Newsgroups: comp.windows.x.motif
From: rh1@base.bellcore.com (Richard Yu)
Subject: Help on size of dialog shells
Organization: Bellcore, Livingston, NJ
Date: Tue, 15 Sep 92 11:57:23 GMT

How can I control the size and position of a dialog shell, created as a child of
an ApplicationShell.  The x, y , height and width resources do not seem
to work.

Thanks.
Newsgroups: comp.windows.x.motif
From: generous@sti.nasa.gov (Curtis Generous)
Subject: use of hints with mwm
Keywords: hints, mwm, resize
Organization: Goddard Space Flight Center
Date: Thu, 10 Sep 1992 12:14:08 GMT


I am trying to prevent the main window of an application from being
resized while running under mwm.  The code I'm using looks like:

    MwmHints        hints;

    hints.flags     = MWM_HINTS_FUNCTIONS;
    hints.functions = MWM_FUNC_RESIZE;
    XtVaSetValues(toplevel, XmNmwmFunctions, hints, NULL);

This has the effect that I want, the top/side bars no longer allow the window to
be enlarged/reduced.  However, the application now no longer will iconify (the minimize
and maximize buttons no longer are showing, and the bitmapped icon no longer 
shows up in mwm's iconbox.  Is this a normal side effect?

--curtis
p.s. this is on a sun 4/470, sunos 4.1.1, motif 1.1, X11R4.


--
Curtis C. Generous
NASA STI
generous@nova.sti.nasa.gov
From: gdmr@dcs.ed.ac.uk (George Ross)
Newsgroups: comp.windows.x.motif
Subject: Re: Help on size of dialog shells
Date: 15 Sep 92 14:28:01 GMT
Organization: Department of Computer Science, Edinburgh University

In article <1992Sep15.115723.19180@porthos.cc.bellcore.com>, rh1@base.bellcore.com (Richard Yu) writes:
> How can I control the size and position of a dialog shell, created as a child of
> an ApplicationShell.  The x, y , height and width resources do not seem
> to work.

Perhaps your window manager is configured to ignore program-supplied size and
position hints.
-- 
George D M Ross, Department of Computer Science, University of Edinburgh
     Kings Buildings, Mayfield Road, Edinburgh, Scotland, EH9 3JZ
Tel: 031-650 5147   Internet: gdmr@dcs.ed.ac.uk   JANET: gdmr@uk.ac.ed.dcs
From: meeks@osf.org (W. Scott Meeks)
Newsgroups: comp.windows.x.motif
Subject: Re: How to make buttons look pressed in ??
Date: 11 Sep 92 18:18:09 GMT
Distribution: inet
Organization: The Internet


I believe that you can do what you want with the existing XmToggleButton
resources.  Try setting XmNindicatorOn to FALSE and XmNvisibleWhenOff to
TRUE.

W. Scott Meeks           
Open Software Foundation 
meeks@osf.org            
(617) 621-7229           
Practice random kindness and senseless acts of beauty.
From: dbrooks@osf.org
Newsgroups: comp.windows.x.motif
Subject: Re: Is there something analogous to XtIsMapped() ?
Date: 10 Sep 92 19:43:06 GMT
Distribution: inet
Organization: The Internet

Ron Cecchini writes:

     There is XtIsManaged() and XtIsRealized().  I need XtIsMapped() and
   there is none.  What is the easiest way to detect this (I'm not
   having any luck trying to use the widget's resources).

Get the window with XtWindow(widget) [or XtWindow(XtParent(gadget))].  Now,
using XGetWindowAttributes, you can find out some exciting things about the
window, including its map_state (IsUnmapped, IsUnviewaboe, IsViewable).

You might also want to take note of the WM_HINTS.initial_state; see the ICCCM.

David Brooks
Systems Engineering
OSF
From: dao+@rchland.ibm.com (Dan Dao)
Newsgroups: comp.windows.x.motif
Subject: Filtered list
Date: 10 Sep 92 15:28:15 GMT
Reply-To: "Dan Dao" <dao@rchland.VNET.IBM.COM>
Distribution: inet
Organization: The Internet

I would like to implement 'filtered list' and looking for the algorithm that
'file selection box' uses DirMask to filter the files in a directory.
Does anyone have any experience on this subject?
Thanks
---
Dan Dao dao@rchland.vnet.ibm.com (507)253-8023
From: amoss@huji.ac.il (Amos Shapira)
Newsgroups: comp.windows.x.motif
Subject: Re: Q: Help with XtAppAddInput
Date: 15 Sep 92 12:07:04 GMT
Organization: Mail to News Gateway at Wang Labs

avinash@felix.contex.com (Avinash Chopde) writes:

>In article <920911103416.11049@fox.frame.com>, rph@fox.frame.com (Ron Hughes) writes:

>Well, I presume it will send a Broken Pipe signal (at least a write
>on a closed connection does.)

Not usually, broken pipe is issued only for the writing side, the reading side
will recieve EOF indication (0 bytes read, for instance).

>I have to use XtAppAddInput on a socket, and have run into a problem
>with the process that does the writing --- if the socket connection
>has been broken, the writing process exits with the Broken Pipe signal.
>I do not want to trap the signal, but want to prevent it---is there
>any way to check the status of a file descriptor (sort of like feof,
>ferror) before "write()"ing to it ?

Couldn't find anything to do this on SunOS (the answer could easely be OS-
specific anyway).  One hack I can think of is to try to read 0 bytes or some
other operation without serious side-effects and see if you get a EBADF (bad
file descriptor) errno.

Follow ups to comp.unix.programmer.

Cheers,
--
--Amos Shapira (Jumper Extraordinaire)
C.S. System Group, Hebrew University, Jerusalem, Israel
amoss@cs.huji.ac.il
From: felix@laas.fr (Francois Felix INGRAND)
Newsgroups: comp.windows.x.motif
Subject: How do you set an option menu value by program?
Date: 4 Sep 92 20:43:21 GMT
Distribution: comp
Organization: LAAS-CNRS France


I have an option menu set with:

     opt_label = XmStringCreateSimple("Time :");
     val0 = XmStringCreateSimple("1");
     val1 = XmStringCreateSimple("3");
     val2 = XmStringCreateSimple("5");
     val3 = XmStringCreateSimple("10");
     val4 = XmStringCreateSimple("15");
     val5 = XmStringCreateSimple("20");

     delay_option_Menu = XmVaCreateSimpleOptionMenu
	  (filling_option_form, "delay_option_Menu",
	   opt_label, NULL, 3, delay_option_cb,
	   XmNbackground, wwg_pix,
	   XmNforeground, gbb_pix,
	   XmVaPUSHBUTTON, val0, NULL, NULL, NULL,
	   XmVaPUSHBUTTON, val1, NULL, NULL, NULL,
	   XmVaPUSHBUTTON, val2, NULL, NULL, NULL,
	   XmVaPUSHBUTTON, val3, NULL, NULL, NULL,
	   XmVaPUSHBUTTON, val4, NULL, NULL, NULL,
	   XmVaPUSHBUTTON, val5, NULL, NULL, NULL,
	   NULL);
     XmStringFree(opt_label);
     XmStringFree(val0);
     XmStringFree(val1);
     XmStringFree(val2);
     XmStringFree(val3);
     XmStringFree(val4);
     XmStringFree(val5);

     XtManageChild(delay_option_Menu);

and it works fine when the user select various values... But how do you change
the value by program? (we want to reset the menu to a default value when we
reset the application).

I have not been able to find the solution in all the book I checked... 
There must be a way...

Thanks in advance,
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Francois Felix INGRAND                   "Read my Lisp... No new syntax" (nil)
LAAS/CNRS: felix@laas.fr      "La guerre, qu'on voit danser le long des golfes
ACS Technologies                     clairs, a des reflets d'argent" (Anonyme)
From: dyoung@media.mit.edu (David Young)
Newsgroups: comp.windows.x.motif
Subject: Q: How Do I Reparent A Widget?
Date: 8 Sep 92 23:03:41 GMT
Organization: MIT Media Laboratory


The short version of my question is: How can I change the parent of a
widget - thereby removing it from its current parent's list of children,
and adding it to the new parent's list of children?

The long version - well, there isn't much more to say.  I basically have
several row-column widgets and I'd like to move widgets (form widgets with
row-column widgets as children) from row-column to another row-column.

Any suggestions or helps would be appreciated.

david young
dyoung@media-lab.media.mit.edu


Note: while I am still using my media lab account, I am no longer a student
there.  I am now employed by: USAnimation, 818 N. La Brea Ave, Hollywood,
CA 90038  
Newsgroups: comp.windows.x.motif
From: armin.kuepfer@alcatel.ch (Armin Kuepfer)
Subject: Re: Redirecting Standard Output to a Widget?
Organization: chx400.switch.ch
Date: Wed, 9 Sep 1992 08:19:09 GMT

> Is it possible to redirect standard output to a widget?

You might look at xdbx, which is a X frontend for dbx, you could
check W. Richard Stevens new excellent book 
  "Advanced Programming in the UNIX Environment", 
  Addison Wesley ISBN 0-201-56317-7, 
for input/output handling in parent and child processes and you yse 
XtAppAddInput() to read the childs data.
Newsgroups: comp.windows.x.motif
From: kaleb@thyme.jpl.nasa.gov (Kaleb Keithley)
Subject: Re: Q: How Do I Reparent A Widget?
Organization: Jet Propulsion Laboratory, Pasadena, CA
Date: Wed, 9 Sep 92 15:33:14 GMT

In article <DRAND.92Sep9105326@spinner.osf.org> drand@spinner.osf.org (Douglas Rand) writes:
>In article <BRENNAN.92Sep9010412@yosemite.hal.com> brennan@hal.com (Dave Brennan) writes:
>
>   The short answer is that you don't.  Under Xt widgets really aren't meant
>   to be reparented once they are created.  Have you considered creating two
>   forms and managing only the one you need to see?
>
>Let me add why.  When the widget is created,  the parent is examined
>to see if it is a constraint widget.  Constraint widgets add resources
>to the widget instance,  and thus the Intrinsics (unfortunately) 
>allocates a larger block of memory.
>
>To reparent,  it would be necessary to realloc the memory to get a larger
>block, sometimes, depending on the new manager parent.  It would have
>been better if the Intrinsics had allocated the constraint record
>separately and destroyed it separately.
>
>As far as I know,  this is the major reason that reparenting cannot
>be currently implemented in the Intrinsics.

And, there's a resource inheritance issue.  In a nutshell, there's no way 
to get an accurate list of resources (above and beyond the constraint
resources) that would apply to a widget after reparenting it.

-- 

Kaleb Keithley                          kaleb@thyme.jpl.nasa.gov

Not authorized, in any way, shape, or form, to speak for anyone.
From: xia@molbio.ethz.ch (Xia Tai-he)
Newsgroups: comp.windows.x.motif
Subject: unsubscribe
Date: 7 Sep 92 15:37:17 GMT
Distribution: inet
Organization: The Internet


unsubscribe me
From: mxa11@po.CWRU.Edu (Madhavi Ahuja)
Newsgroups: comp.windows.x.motif
Subject: FAQ and examples
Date: 15 Sep 92 14:38:02 GMT
Distribution: inet
Organization: Case Western Reserve University, Cleveland, Ohio (USA)
NNTP-Posting-Host: thor.ins.cwru.edu


Hi
Where can I find motif FAQ and motif examples ?????
Thanks
Madhavi
ma@acqdev.eeg.ccf.org
Newsgroups: comp.windows.x.motif
From: leiman@armos.engr.washington.edu ()
Subject: Re: Redirecting Standard Output to a Widget?
Organization: University of Washington
Date: Thu, 10 Sep 1992 00:17:56 GMT

In article <1992Sep8.235519.8543@ncsu.edu>, you write:
|> Is it possible to redirect standard output to a widget?
|> I'm currently converting an existing Unix application to
|> Motif, and am using a form manager.  It would be ideal if
|> one of the widgets were able to print the messages from
|> standard output, but I've yet to figure out a simple way
|> to do this.  For example:

It just happens that I'm working on a same kind of problem myself.
A good example how to do this can be found in Doug Young's book 
pg 161 in xbc.c example program. Also the same stuff is mentioned in
Motif Programming Manual (O'Reilly VOL 6) page 689.

Basically this is what you need to do:
1. Your parent process calls pipe() to set up a channel (you do this
   twice if you need to redirect stdin as well)
2. call fork() to spawn a child 
   note that your program now splits into two processes, the parent which
   gets a process-id >0 returned, and the child which gets 0.
3. the child has now inherited the open files (like stdin & stdout)
   do redirection by using dup(), close() pairs or use dup2(). 
   Then close the pipes.
   In the parent do the same thing.
4. use execlp() in child to overlay forked process with your Unix cmd.
5. with XtAddInput() make stdin to cause callbacks in your parent, the 
   callback function should now be able to read output from the spawned cmd.
6. use fprintf(stdout, ...) to send stuff for the spawned cmd

For steps 1-4 you can simply use the xs_talkto() in directory /lib of the
Young examples sources (young.motif.tar.Z in export.lcs.mit.edu ).
You need to add some amount of checking though, and handling of signals
and error conditions etc.
It's also a good idea to modify the original unix application just a little
(if only possible), to get rid of buffering and maybe handle errors better.

-- 
Ian Leiman, M.Sc.(EE)            leiman@armos.engr.washington.edu
4106 Dayton Ave. North           home:   +1 206 545-4967
Seattle, WA 98103                office: +1 206 685-2872 (UW/CISO)
Newsgroups: comp.windows.x.motif
From: drand@spinner.osf.org (Douglas Rand)
Newsgroups: comp.windows.x.motif
Subject: Re: Is there something analogous to XtIsMapped() ?
Date: 9 Sep 92 23:17:26 GMT
Organization: Open Software Foundation

In article <7a5yxra@rpi.edu> cecchinr@hornsby.cs.rpi.edu (Ron Cecchini) writes:

     There is XtIsManaged() and XtIsRealized().  I need XtIsMapped() and
   there is none.  What is the easiest way to detect this (I'm not
   having any luck trying to use the widget's resources).

Why do you care?  You need to know XtIsRealized so you don't draw
to a NULL window,  but why do you need the mapping state?  You 
normally draw to a Widget's window in response to an Exposure.
The server won't generate these events until the window is mapped.



--
Douglas S. Rand <drand@osf.org>		OSF/Motif Dev.
Snail:         11 Cambridge Center,  Cambridge,  MA  02142
Disclaimer:    I don't know if OSF agrees with me... let's vote on it.
Amateur Radio: KC1KJ
From: fun@axis.fr (Francois Thienot)
Newsgroups: comp.windows.x.motif
Subject: Please again TeleUSE users's list
Date: 7 Sep 92 11:58:42 GMT
Organization: Axis Digital - France

Last time Gary MORRIS send an article "Mailing list for TeleUSE
users established". I lost all my news, please send me this list at
fun@axis.fr and other information on TeleUSE.

Thanx . 

FUN (Fun Unix & Nanas)
uniX! uniX! uniX!
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
*    /\__/\    *  FUN (Fun Unix&Nanas)	* e_mail: fun@axis.fr	    *
*   //\  /\\   *  AXIS DIGITAL		* 			    *
*  <  @\/@  >  *  11 rue L. HOCHE   	* Voix:   (33) 46 03 37 75  *
*    \ || /    *  92100 Boulogne    	* DeFaxo: (33) 46 04 60 18  *
*    ~^vv^~    *  FRANCE		*			    *
-=-=-=-\/=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-- 
-----------------------------------------------------------------------
FUNEWS-FUNEWS-FUNEWS-FUNEWS-FUNEWS-FUNEWS-FUNEWS-FUNEWS-FUNEWS-FUNEWS-F
-----------------------------------------------------------------------
From: littlec1@jaguar.uofs.edu (Chris Little)
Newsgroups: comp.windows.x.motif
Subject: Motif Programmer's Reference Manual
Date: 5 Sep 92 02:47:47 GMT
Organization: University of Scranton


Marshall Brain makes reference to the "Motif Programmer's Reference Manual".
Is this available via ftp?  Would it be found at a typical bookstore?

Thank you.

--
Chris Little, Programmer/DBA                    University Computing Systems
                                                University of Scranton
  LITTLEC1@JAGUAR.UOFS.EDU                      Scranton, PA 18510
Newsgroups: comp.windows.x.motif
From: marbru@auto-trol.com (Martin Brunecky)
Subject: Re: Q: How Do I Reparent A Widget?
Organization: Auto-trol Technology Corporation
Date: Thu, 10 Sep 1992 18:16:55 GMT

In article <DRAND.92Sep9105326@spinner.osf.org> drand@spinner.osf.org (Douglas Rand) writes:
>...
>   terrible hack anyhow, typically reserved for implementing Motif tear-off
>   menus.  You really don't want to bother.
    Oh boy. Is this the way you guys did that ? 
>
>....
>To reparent,  it would be necessary to realloc the memory to get a larger
>block, sometimes, depending on the new manager parent.  It would have
>been better if the Intrinsics had allocated the constraint record
>separately and destroyed it separately.
     R5 feature/optimization ... but that's not the problem.
>
>As far as I know,  this is the major reason that reparenting cannot
>be currently implemented in the Intrinsics.
>
   I'd consider this a technicality. Once you get that deep into Xt
   internals, it can be done - as a deeply Xt implementation specific
   code.

   But the main reason are resources. Xt emphasizes resources, and
   (though some resources are inherited from the parent), most resources
   are fetched based on the widget location in the tree hierarchy.

   If you reparent a widget, you'v changed it's location in the tree.
   Should you refetch all resources ? (note that is an equivalent of
   recreating a widget). If the parent is a constraint widget, should
   the constraint reflect the ones specified for the intial location
   in the tree, or ones specified for the target one (note you*must*
   redo the constraints during reparent) ?


-- 
=*= Opinions presented here are solely of my own, not those of my employer =*=
Martin Brunecky           marbru@auto-trol.com                  (303) 252-2499