Trying to detect when a process has finished with a txt file, I thought Status() might work, but upon closer inspection I think its returning the runtime/rtl file handling status and not the file status when non Clarion apps also have the file open and working on it.
Havent disabled disk caching and enabled oplocks yet, but am aware of it.
tldr am I going to have to monitor the file handles using win32 apis to detect when the file is closed before my clarion app can use it?
TIA
That would seem to be overly complicated.
Why can’t you just open the file with whatever permissions you need, it’ll either work or it won’t. And if it doesn’t you can try again later.
I found the problem, it doesnt exist. The background process (powershell) I shellexecuteex start and have output sent to txt file but powershell hasnt created the file by the time my code starts to work on it.
Ive got an open(mytxtfile,readwrite+denyall) set up later on with errorcode checking, but I wasnt getting that far.
Cpu time slicing in favour of desktop app against background processes, exacerbated the problem, but I’ll use open in a loop testing for more conditions with Yield to wait for the background process to finish.
Edit.
I can see why servers have their cpu timeslicing set to favour background processing, it helps the badly written services not fall over, in much the same way as when single core cpus existed, everything ran like clockwork then.
Set a server cpu quantum to favour the foreground app, like a desktop, loggoff and wait for the badly written apps/services to fall over over the course of a day or week because they havent been programmed properly.
I put the open(file,readwrite+denyall) inside a loop case of’ing errors. If clock() exceeds timeouttime, set just before loop, it breaks out of the loop and aborts the rest of the job, so it doesnt hang waiting for the asynchronous background app/process to complete.
Loop timeout time increases with cpuload to compensate for old and/or busy machines, so its not a fixed timeout that could fail just because workload happens to be too great.
Works quite nicely now.
STATUS(File) is the Open Status for the running Clarion EXE … actually it can be Thread status specific as noted by the help.
If the file is threaded, STATUS is for the current thread only.
Why ask the question and trust the answers, or even trust the help, when you can write one line of code and test it on a file for yourself. E.g. your EXE must be open by the OS so a simple test maybe Message('EXE Status()='& STATUS(Command('0') ) . You should also test it on a file your program opened.
I made the below utility on GitHub to Open a File in any mode and leave it open. That way I could verify my code handled the Access Denied error gracefully after Create, Open, Share, Remove, etc.
There is also a “File Lock Check” in that Repo that simply uses OPEN().
Its a windows process (powershell) creating the file, not a clarion process template, and Im using powershell because I can gain access to parts of the OS I cant with Win32 api’s like the Bios of a machine.
What do you need in the BIOS that you think you can’t get to with a Windows API call?
Everything. 
Bios versions and bios settings.
Ive got some powershell scripts which get some of the info for me, but its manufacturer/bios specific.
Do you know something I dont? If so pray tell. 
Yeah I have noticed the registry is the root source.
I’ll check out GetSystemFirmwareTable, I forgot about the SMBios, in device manager but will check out the api. Google and Bing can be so limiting sometimes..
Thanks!
