I have implemented a code to monitor orders in Orders.xml and TradeHistory.xml in order to detect the long standing "Stuck Submitted" problem.

The code works fine under the paper account and the orders are reflected to those xml files in the matter of seconds.

However, the orders with Fidelity account seem taking more than 30 seconds occasionally.
Any idea how orders are reflected to those xml files?
What would trigger the orders to reflect to the xml files?
If it is matter of file handle to be closed and flushed, is there anyway to force flushing the data to the xml files?

While I can't answer any of your questions which require a knowledge of the source code too deep, a rule of thumb is that one shouldn't rely too much on application's XML and TXT files while it runs. Changes to some of them aren't flushed to the disk until the program is restarted.

QUOTE:
a rule of thumb is that one shouldn't rely too much on application's XML and TXT files while it runs

Yes, I perfectly understand that. The deferred object cleanup (garbage collection) nowadays makes thing even difficult to predict the life cycle of the objects. But I'm hoping here is if there is anyway to make it more predictive. For example, closing Orders window, internal method to release object, timeout at the end of bar (e.g. Strategy Monitor does timeout updating the 1-min bar data 10 seconds before the next bar, etc...).

Turns out that a thread runs every 5 seconds to save new orders and order history.

QUOTE:
Turns out that a thread runs every 5 seconds to save new orders and order history.

Thanks! That is good to know about the thread saving the orders to the files. I started collecting some numbers and my preliminary testing indicates positive results.