Is this safe

Midhat Ademovic

I need to communicate with fiscal printer via third party software (Don't ask me way).
I'm sending command file in one folder and receive answer file in another folder.

My print method need to return number of fiscal invoice which is generated by printer and can be found in answer file.

So my method look like this

public int PrintInvoice()
{

//Do some code of sending command file

//Wait until answer file received

while(!_answerFileReceived){}

//Process answer file and return Invoice number

}

Also I have FileSystemWatcher which monitor answer directory (file creation) with code

fswWatcher_FileCreated(object sender, FileSystemEventArgs e)
{

_answerFileReceived = true;

}

My question is "Is this safe" and can I have exceptions, or do you have any suggestion of another approach to above problem.

Thank you.

6 Replies

Know the answer? Post it — somebody with the same question will find it here.

Vulpes15y ago
Accepted answer
Well, one concern is that an answer will never be received because the printer has broken down or some other problem has occurred. You won't get an exception but the code will stay in the while loop and your application's UI will be frozen in the meantime.

If you know how long it should take for an answer to be received, then you could set a timer interval for a little longer than that and then, in its Tick event handler cancel the command and perhaps, when you get the error code, send it again:

private bool _timedOut;

public int PrintInvoice()
{
//Do some code of sending command file
_timedOut = false;
timer1.Start(); // start timer

//Wait until answer file received
while(!_answerFileReceived && !_timedOut)
{
System.Threading.Thread.Sleep(100);
Application.DoEvents(); // allow UI events to be processed
}

if(_timedOut) return -1; // error code

//Process answer file and return Invoice number
}

private void timer1_Tick(object sender, EventArgs e)
{
timer1.Stop();
_timedOut = true;
}

As an alternative to using the UI thread (if that's what you're doing), you could use a BackgroundWorker to do the operation which would keep the UI responsive. However, you'd still have the 'time out' problem even then.
Sam Hobbs15y ago
Note that the best solution nearly certainly involves using the third party software in the manner it was designed to be used, and we don't know what that is.
Midhat Ademovic15y ago
Thanks for your answers.

I changed my approach based on your suggestions. I totaly loose FileSystemWatcher and put the monitor logic inside PrintMethod like

bool fileArived = false;

//Code for monitor answer file
for(int i = 1; i < 250; i++)
{
//Wait 20 ms for answer (max 5 sec)
Thread.Sleep(20);

//Is answer file received
if(File.Exists("AnsferFile.txt"))
{
fileArevied = true;
break;
}
}

if(fileArevied)
{
//process file and get Invoice number
}
else
{
//Error handling
}

This way there is not infinite loops and everything is in one place.
Sam Hobbs15y ago
Yes, of course Sleep is needed when Application.DoEvents is used and Application.DoEvents is needed when Sleep is used but neither is needed if processing is done asynchronously.
Vulpes15y ago
The purpose of Application.DoEvents is to enable any pending UI events to be processed including the timer.Tick event. Otherwise the while loop would hog all the processor time.

Thread.Sleep(100) is to prevent Application.DoEvents being called again too quickly.
Sam Hobbs15y ago
Are you not able to use the managed classes that Microsoft provides?

If not, then I would look for samples using the third party software that you are using. Are there no samples?

I don't know how those printers work so I don't understand about answer files so since you already have an answer, I probably cannot help. I however don't understand why you miust do both; wait for an answer file and monitor the directory.

I would expect the third party software to have an asynchronous way to send data that would include a timeout, and then most of what you are doing here would be unnecessary. I sure don't understand the need to use Sleep and DoEvents. It seems to me that the combination of FileSystemWatcher (for success) and the timer (for failure) would be sufficient. But if it works, then that is good.