Ken Dibble wrote: >>Seriously, writing anything to the root of c: is wrong, very wrong. You >>don't want their other computer guys saying things like "what kind of >>moron..." >> >>What happens when they lock down write access to c:, or when they want >>to do it but can't because of your app getting in the way of that. > > The only objection that I've ever seen to writing things to the root of c: > that has ever made sense to me is that there's a finite limit on how many > files can be there. That's at least a real limitation, not just a > theoretical one. However, it's not very likely to be a problem in the real > world since that limit is not very likely to be approached in the normal > course of use, let alone reached. Nor do I see how a dozen-byte-or-so .txt > file can possibly cause problems in that location on its own. > > Sure, I've heard that it's "wrong", but beyond the above, I've never heard > anybody ever advance a solid reason why it's wrong--though I've heard > plenty of stuff along the lines of "what a moron.."--again, without anybody > ever giving a reason. > > Sure, they can lock down c:\. They can lock down anything. They've already > locked down \Program Files and %OS%. C:\ may be next. Then what? They'll > lock down everything and tell us we have to do everything through the > browser, I suppose. "They" can go .... do something.... to themselves.
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. >> > 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... > 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. > 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. >>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? -- pkm ~ http://paulmcnett.com _______________________________________________ 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.
