>>>>>>Hi,
>>>>>>
>>>>>>Is it possible to add/include a file to an EXE file? As if the file was included at design/compile time?
>>>>>>
>>>>>>TIA
>>>>>
>>>>>I have to ask, why? There could be other way to accomplish what you need.
>>>>
>>>>One of the files used by SDT is SDTMeta.dbf. Sometimes I get an error from the customer that this file cannot be read by the application. To prevent these errors, ideally, I would include this file into the application (into the .EXE).
>>>>But, for some customers, this file has to be updated/changed, when the application is being updated. Reason is that these customers have custom fields or some other custom settings that require this file to be different from other customers.
>>>>Therefore, I would like to include this file, SDTMeta.dbf into the EXE; but for those that need to have a custom version, modify it - during the update - and then store it into the .EXE
>>>
>>>Just keep the usual file into EXE (with different name) and if you have problems reading the file that is outside the EXE,
>>>extract it, update it and then use it :-)
>>>Something like:
>>>

>>>TRY
>>>    USE SDTMeta IN 0 SHARED
>>>CATCH
>>>       STRTOFILE(FILETOSTR("YourStroredFile.DDD"), Full_path_for_SDTMeta.DBF, 0)
>>>       UPDATE Full_path_for_SDTMeta.DBF to have all records
>>>       USE SDTMeta IN 0 SHARED
>>>ENDTRY
>>>

>>>Of course this is very simplified :-)
>>
>>This is a good approach. But I am thinking that the error message the customer gets is not because the file is "bad" but because the OS has a glitch. So, I am thinking of enclosing the USE SDTMeta (just like you have) in TRY CATCH and do it 3 times, with a delay of about a second. Then, if it fails, even on the 3rd try, suppress the error (in Catch) and go on. Currently the application completely fails on Read error. If I suppress the error, I tested, the application still works. Just some SDT Filters may not be working 100%. But this is minor compared to the application crashing.
>>Thank you.
>
>Make sure that for the delay you're performing a sleep operation (i.e. system call to release the timeslice) rather than a simple busy-wait loop. If you do use a busy-wait loop, you may want to consider adding DOEVENTS in the loop.

I was thinking of inkey(1). Would this require a DOEVENTS?