>What if "they" is your corporate, bill-paying client? Who has a policy
>that says that nothing gets written to c:? Such policies seem fairly common.
I don't work in the corporate world. I work in-house in a not-for-profit
agency, and when I sell an app it's to other agencies of the same type.
It's a very specialized setting. I'm lucky to be here, and the situation is
such that I can retire here. I don't have to do things the way everybody
else does, and that suits me fine.
> >> > actually. I just wanted to be able to write it to some standard location
> >> > that would be known to exist and which a second attempted instance could
> >> > check without knowing anything about the first instance.
> >>
> >>
> >>I know this isn't what you are asking for, but I'll just say it. I used
> >>to limit my apps to single instance, too. I don't remember what method I
> >>used, but I don't think it was a file-based semaphore. IIRC I would use
> >>the win api to search for a window that had a title matching my app's
> >>title. If found, I'd activate it and exit; else continue loading like
> >>normal.
> >
> > The actual reason for this is that VFP can crash in such a way that it
> > leaves nothing visible on the desktop or in the taskbar, but the vfp
> > runtime is still running in the Task Manager. In those cases, the window
>
>
>That's indeed strange. I've never seen that, which seems to indicate
>that VFP doesn't need to crash in such a fashion...
Possibly you haven't written applications this complex? Or perhaps you
haven't had to develop apps for slow-running machines with older OSes?
Lots of things happen in VFP that some people never see. The VFP 7
intellisense bug that caused C5 crashes when the developer typed the left
paren on the name of a custom method in the Form or Class designer was
"never seen" by several well-known VFP experts, probably because they were
all running Win 2000 or XP on super-hot machines. The rest of us, not
accustomed to such luxury, saw it plenty. There are people who frequently
have .scx or .vcx files get corrupted while having three or more forms or
classes open at the same time and cutting/pasting code between them. Other
people say they've never seen it even once. In VFP 6 on this Win 98 machine
I can reliably cause the form designer to hard-freeze or throw an illegal
operation by clicking the edge of the mouse pointer on the edge of that
window's "X" close button.
The fact that some people never see something does not prove that the
people who do see it are doing something wrong.
Of course it doesn't need to crash in such a fashion. (In fact I would say
that VFP never needs to C5, that in fact an application that C5s is an
application that does not have proper control of its memory. But I have
heard several MS apologists claim that C5s are unavoidable.) In any case I
have yet to find anybody, anywhere, who could reliably explain why this
happens. Until I know that, I can't fix it, no? Nor can I even reliably
reproduce it in order to test strategies to prevent it.
Probably it happens in several different scenarios. I used to put some of
the standard VFP Windows menu pad functions in my apps--until I discovered
that one of those functions--"Hide"--can be used to make the entire
application disappear--and the typical user didn't even realize they had
done it. They think the application has been magically shut down. So they
try to start it again. Just the other day I had a user delete a record and
claim that it "just disappeared" without her doing anything--even though
she must have seen an "Are you sure?" dialog and chosen "Yes" to make it
"disappear", and I could look up the last-modified user id on the deleted
record and verify that it was her who deleted it. With users like this, any
number of strange scenarios can happen out of my sight.
>
> > title search fails. the idea is to force the user to check the Task
> Manager
> > and terminate that process before relaunching the app.
>
>
>You could write code to terminate the process for them, instead of
>making them do it.
> > A mutex might work--but as I understand it, I still need to know the path
> > where the mutex resides, correct? If so, it's not any better than a
> > semaphore file.
>
>
>Why not check the running processes for your executable, combined with
>the window title search? Your program would have all the info it needs
>to make a "smart" decision, keeping the user from losing hair.
I've never seen an example of code that could find a running process and
terminate it without relying on the window title search. I have tried very
hard to find one. Is there such a beast? Can you point me to a URL or
something? I'd be much obliged.
> > The Windows Registry is a fascist plot. ;-)
>
>
>You should try to go with the flow on the given OS. While I dislike the
>registry, it isn't hard to use and it has proven to be quite reliable
>over the long term, at least on the NT-based OS's.
Ah--but text-based .ini files and the like are so much simpler and robust,
I heard someone say. <g> Anyway, I think that a process that fails before
it can do a simple ERASE MyFile.txt is likely also to fail before it can do
a much more complex registry edit.
> >>But, I digress. What I really wanted to point out is that I stopped
> >>limiting my apps to single-instance, and *the users loved it*.
> >
> > I don't have any technical objection to that. But my framework does not go
> > the apparently usual route of ignoring update conflicts. We're not doing
> > point-of-sale invoices here where the likelihood of two users working on
> > the same record is virtually zero. We've got several staff members in a
> > position to enter some portion of data about the same client, and we have
> > to do our best to make sure that data is accurate. So when user A enters
> > something different than user B in the same field for the same client, we
> > have to have somebody investigate and decide who is right.
> >
> > Running two or more instances of this application on the same desktop
> > would, in my framework, create a likelihood of spurious update conflicts
> > that would only confuse the users.
>
>
>Running two instances of the app on one computer is logically identical
>to running an instance on computer A and another on computer B, no?
But the users running those instances on separate boxes are not identical
in any sense. It makes sense to Joe Smith and Mary Jones, who are running
the app on separate computers, when they experience an update conflict
while editing the same record. It does not make sense to Joe Smith when he
edits the same record twice on the same machine and is told "the other
user" changed something and asks him what he wants to do about it.
In my experience with the users I deal with, a window unseen is a window
whose very existence is forgotten. I tell you, most of these people do not
understand how to re-display a window that is minimized to the Task Bar,
and no matter how many times I show it to them, they think it's some kind
of magic and I must be really, really smart.
A classic example is Eudora email, in which users can open hundreds of
separate overlapping windows for email messages and read them--and then
leave them open (even though Eudora has an internal "Task Bar" with a
button for each window), which causes Eudora to take 2 minutes to load when
they restart it, and causes them to complain that their computers are "too
slow". (Or they resort the message list inadvertently on something other
than date and then tell me they haven't received any new emails in 3 days.)
At least in my field, which is mostly about providing social services, and
only marginally about computer operation, and where it is impossible to
enforce any minimum computer literacy requirements in job descriptions even
if we put them in there, it's better not to give users opportunities to
confuse themselves.
Ken Dibble
www.stic-cil.org
©2007 Ken Dibble |
|
