On Monday 14 May 2007 04:58, Kay Ramme - Sun Germany - Hamburg wrote:
...
> > I've wondered if it might be a multiple clients issue (and here it
> > makes it hard to keep track, since we're talking about
> > server/clients and my business clients, so I'll use "client apps"
> > to refer to the non-human one).  Basically this is not a program
> > people will keep on in the background.  It runs, does it's thing,
> > then exits.  When it's done, as I said, it checks a flag to see if
> > OOo was running when it started.  If not, it kills OOo through the
> > API.  If OOo was running, it cleans up and exits properly.  Most of
> > the time there's never been a problem, but it started showing up
> > with one user after a while.
>
> You may want to use multiple instances of OOo running, one for every
> client (you need to provide directories for the user data for every
> instance, e.g. "-env:UserInstallation=<path>"). So, obviously this is
> not optimal memory wise ;-)

In my case, there is only one customer using what should only be one 
instance of my software on one computer, so multiple instances are not 
needed.  Each client is in their own office, on separate computers.

> > I've wondered if, for some reason, the old instance of the client
> > app was not releasing, but the log files show it was.
>
> You mean, it terminated ?!

No, I mean my log files, from my Java app will show that the connection 
with OOo was successfully released and my program kept running after 
terminating the connection (or destroying the object, or whatever step 
is needed -- haven't used that code in a while, so I've forgotten 
exactly what it does).

> > I think I'm going to handle this by writing a routine that will
> > kill OOo.  When my app first starts, it'll try an immediate
> > connection with OOo.  If it doesn't get it, it'll run OOo and wait.
> >  If, after a certain length of time, it doesn't get a connection,
> > then it'll kill any instance of OOo and try again.  At the end,
> > it'll release it and if it was supposed to end OOo, it'll also
> > terminate it with Taskkill.
>
> SAL implements a little executable called "kill.exe", which is
> somewhat similar to the Unix kill command, but is usable on Windows
> (http://porting.openoffice.org/source/browse/porting/sal/systools/win
>32/kill/).
>
>
> Call "kill -null <pid>" to terminate the hanging process, while
> ensuring that the crash reporter jumps up.

Actually, I'd rather the reporter not show up.  This is on my clients' 
computers and most are quite intelligent business people, but they're 
not computer people and I need a professional presentation, so opening 
a crash reporter frequently when they run my software would be an 
issue.

...
> > Yes, I agree.  That's why I was working with people on macros and
> > issues around that.  Some of my questions even ended up in Andrew's
> > book on macros in OOo.  The people there were quite helpful and it
> > was a good community, so I was glad to work with them and wanted to
> > help.  On the other hand, when a programmer got snotty with me, it
> > was years before I even considered filing any kind of issue again. 
> > I've dealt with that attitude before and, as a former special ed
> > teacher, I found it quite disgusting.  My job was to work with
> > people that didn't understand in the same way as others and I had
> > to show much more tolerance than most people ever do.  I've dealt
> > with a few other situations where developers were almost hostile
> > toward those they considered "end users" because the users did not
> > have the same technical skills the programmers did.  It's totally
> > inappropriate and it had happened with me in a few other FOSS
> > projects, so I just gave up on filing bug reports.  If developers
> > want help but aren't willing to treat those who try to help like
> > humans, then I'm just not going to take the risk.
>
> Understood. My believe is, that there are no end users respectively
> developers, everybody has always more than one role, e.g. being a
> user of a browser while developing a word processor or some web stuff
> (this obviously does not need to be computer related only :-). So I
> think, that everybody should be able to understand the position of
> others relative to ones own. Moving along from being a novice e.g. to
> becoming a wizard is matter of many small steps in learning etc. Any
> (artificial) barrier between any pair of those steps hinder people to
> learn and to improve their abilities. This is also one of the reasons
> I am completely against something as "developer" documentation vs.
> "end user" documentation.

I understand what you are saying.  I'm self taught and I find it quite 
common that I'll ask for help on forums and the answer is quite 
condescending, with an "I know more than you and that makes you an 
idiot" attitude.  People have a wide range of experience and all of 
them can provide input to a project.  As you point out, many times 
someone starts as an end user and gets more involved and provides a lot 
of input along the way.

> >>> As I said, I've helped in other areas and when I get back to the
> >>> point where I'm writing again, instead of programming, I'm sure
> >>> I'll have a lot to contribute to in OOo.  It's been a big help to
> >>> me and I want to give back more than what I have, but I've just
> >>> found reporting issues to be a negative experience.  I don't know
> >>> if the intent of some of those programmers was to squelch me so
> >>> they could close the bugs, but the effect is that I've learned
> >>> it's not worth the hassle to report issues.
> >>
> >> There sure are cases, where opinions very, mostly I would trust
> >> the aspect matter expert, so certainly she or he may fail.
> >
> > My sense was that in at least one case, the intent was to just get
> > me to shut up so the issue could be closed and forgotten.
>
> This is certainly not acceptable. Please put me on CC: if you ever
> stumble over this again.

I certainly will.  I think people who handle issues in that way hurt the 
entire project and that is not the point.

Hal

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to