>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. > > 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 title search fails. the idea is to force the user to check the Task Manager and terminate that process before relaunching the app. 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. The Windows Registry is a fascist plot. ;-) >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. 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.
