I agree with you on that point.
I just remembered i got stuck a few days ago while burning something, and couldn't open the CD, and believe me i tried everything, so i had to turn off the computer...Thought maybe you'd like this idea :-)


>Hi Jaime,
>
>It may be possible, but my point was that those 'wise' guys simply are not smart enough to understand that there really are situations when there is absolutely NOTHING the programmers can do to avoid the open file dialog. These situations are rare, but they fall under the category errors, and they should be handled accordingly.
>
>>Tore
>>Just an idea that might help you. I noticed some programs that lock the CD and prevent it from being opened during operation. My guess is there is some API function that does that, so maybe you could lock the CD while doing your operation, then unlock when finished. Check www.news2news.com/vfp , there might be something useful there.
>>
>>Cheers,
>>Jaime
>>
>>>Hi again Christof,
>>>
>>>I am very happy for your comments about this. As you may have noticed from my other messages, I see the missing error from VFP as a PITA, and have suggested a SET command to enable VFP to raise an error. But some people obviously have perfect customers where network connections never break, or where their customer never remove a CD while their are in the middle of an update procedure or similar situations.
>>>
>>>Myself I have about 4000 customers using an 'electronic catalogue' made in VFP8. Twice a year I send out new CDs with new data, which are compared to the data on their computer, and new or changed information is added and changed on their computer. The update process takes about 5 minutes, and there is absolutely no way I can program to avoid the open file dialog if one of my customers remove the CD before the update process is finished. All the 'wise' guys can say that I can check for the existence of the files before I open them, but I can not check all the time, I must also use the damned files....! And yes, I can copy the CD to the HD and do the update from the HD, but many of my customers simply don't have enough empty space on their HD.
>>>
>>>I have given up writing to convince those 'wise' stubborn guys that this actually is a very real problem, which should be handled differntly by VFP. I know that you are wise enough to understand how serious this matter is, and I hope that you have enough respect to be taken more seriously than me and some other people in this thread.
>>>
>>>>Hi George,
>>>>
>>>>>It seems to me that we have enough "hammers" to drive this "nail". Between creating our own routine to open the table, to private datasessions, to subclassable dataenvironments, what more do we need here?
>>>>
>>>>
>>>>Stability. There are many cases where its difficult to validate that a table is open, for instance, when you allow users to create a SELECT statement, when files are damaged, or when a table usually is open, but some rarely executed method closes it under some specifc circumstances. It shouldn't happen, but it does happen.
>>>>
>>>>In a desktop application this causes a dialog to appear. While it's annyoing to the user and certainly causes support calls, it's not really a big deal. However, when there's no desktop available, the application hangs. For me there's not much of a difference if VFP crashed or hangs, the result is the same: I've to kill the task. In VFP, as a high level language, I don't think that any VFP command should crash or hang VFP. Neither calling API function that cause exceptions, nor passing an invalid pointer to SYS(2600) crashes VFP. A SELECT statement shouldn't, neither.
>>>>
>>>>This is even more an issue, if you only provide the infrastructure, but the actual code is written by someone out of your control. Think of a web product like AFP that runs as a service and executes VFP code written by our customers. It's their code that is wrong, but our product that hangs.
>>>>
>>>>
>>>>--
>>>>Christof