File checking

I have written an application that runs as a service in a windows environment. This application works with an XML file that is generated from an ERP system.
I’m checking for IsReadable, IsWriteable and locking, but without success. My application is stopping every time it cannot open the xml file. Is there a better way to check whether its save to open the file? by using standard xojo solution or using windows libraries.

Thanks for your help.

It all depends why the file isn’t openable.

If it’s because the XML file isn’t yet fully written - i.e. is being used by something else - then you probably want to wait and try again.
If it’s not openable for some other reason, then you probably want to stop.

What I’d do here is use a textInputStream to read the file, wrapped in a Try block, to catch e.g. NilObjectException etc., and then in the Catch event have a dialog which asked if you want to try again or cancel, something like this (in pseudocode)

dim keeptrying as boolean = true

while keeptrying
read in xml file to string variable
catch err as nilobjectexception
Put up a message dialog ("Couldn’t open the file. Try again? ") with buttons “Try again”, “Give up”
if button pressed = “Give up” then
keeptrying = false
end if
end try

you should look at the WFS, startwatchingchanges, stopwatchingchanges are probably what you seek

My first question… “What is the exception message when it fails to open the file?”

As I said before, I need a proper solution to check whether the file that is been build by our ERP system is still open, and is not able to be processed by my service program.


You’ve been given 2 solutions. Choose one. The one by Hamish is easier. Ie., try to open it and catch the exception. That tells you unequivocally whether it is safe to open the file.


True. For some reason when the service program runs, the output from our ERP system takes much longer.

I sounds to me like your ERP system is continually writing to this file, while at the same time you are attempting to have another (xojo) process read from this file. This would account for your ERP seeming to take longer, as it is “smart” enough to wait during the attempts to read the file. If that is the case perhaps a program that does not read the WHOLE file… but only the tail end and attempts to (offline) reconcile with a previous read (ie. incremental transactions)

Hi Dave,

Your assumption is correct, I can see the file being build very slowly when this happens. Can you please clarify your suggested solution?