>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 _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/[EMAIL PROTECTED] ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
