Force Windows to execute file actions

[ISITEC_RIEPER]

Hello,

i'm using a third partie tool that i start with LaunchExecutableEx("cmd /c
tool.exe >result.txt"). The result of the tool.exe is written to result
..txt.

My next steps:
ProcessSystemEvents();
SyncWait(Timer(), 2.0);
fileHandle = OpenFile ("result.txt", VAL_READ_ONLY,VAL_OPEN_AS_IS,
VAL_ASCII);
ReadLine(fileHandle,result_str,255);
CloseFile(fileHandle);

I try to read the contens of the result.txt. But most of the time there
seemes nothing to be written into the file. When i debug my project and do
the lines step by step everything works fine and i can readout the result
from the file. Is a possible caus that Windows doesn't write the file
immediatly ? Can i force Windows to write the file right away ?
Another starnge behavior i found by the use of
OpenDocumentInDefaultViewer(). I try to open a directory (explorer). Mostly
everything works fine, but sometimes i can see while i'm debugging that the
function is called but nothing happens. Than it takes a long time before the
Explorer suddenly opens. I also guess that i have to force Windows to
execute the command..... but how?

Te sleep policy is set to sleep some, my cvi version is 8.1.0


Thanks

Norbert Rieper
Bremerhaven
Germany

[ISITEC_RIEPER]

I also get an error when i close a file and then in the next step try to
delete the file:

error = CloseFile(fileHandle);
error = DeleteFile("silex_vl.txt");

CloseFile returns without any error, DeleteFile returns -6 (access denied).
When i run in debug mode and stop execution before DeleteFile and then
continue, i get no error!

Any ideas?

Norbert



"Norbert Rieper" <nrieper@isitec.de> schrieb im Newsbeitrag
news:4668fd61$1@PYROS.natinst.com...
> Hello,
>
> i'm using a third partie tool that i start with LaunchExecutableEx("cmd /c
> tool.exe >result.txt"). The result of the tool.exe is written to result
> .txt.
>
> My next steps:
> ProcessSystemEvents();
> SyncWait(Timer(), 2.0);
> fileHandle = OpenFile ("result.txt", VAL_READ_ONLY,VAL_OPEN_AS_IS,
> VAL_ASCII);
> ReadLine(fileHandle,result_str,255);
> CloseFile(fileHandle);
>
> I try to read the contens of the result.txt. But most of the time there
> seemes nothing to be written into the file. When i debug my project and do
> the lines step by step everything works fine and i can readout the result
> from the file. Is a possible caus that Windows doesn't write the file
> immediatly ? Can i force Windows to write the file right away ?
> Another starnge behavior i found by the use of
> OpenDocumentInDefaultViewer(). I try to open a directory (explorer).
> Mostly everything works fine, but sometimes i can see while i'm debugging
> that the function is called but nothing happens. Than it takes a long time
> before the Explorer suddenly opens. I also guess that i have to force
> Windows to execute the command..... but how?
>
> Te sleep policy is set to sleep some, my cvi version is 8.1.0
>
>
> Thanks
>
> Norbert Rieper
> Bremerhaven
> Germany
>
>
>
>

[Guillaume Dargaud]

> CloseFile returns without any error, DeleteFile returns -6 (access
> denied). When i run in debug mode and stop execution before DeleteFile and
> then continue, i get no error!

Add a while loop as long as you get access denied, with a short delay
inside. Give explorer the time to update the filesystem...
--
Guillaume Dargaud
http://www.gdargaud.net/

[menchar]

Are you trying to read the file while the tool has it open for writing?

Unless you specify sharing semantics when opening the file, you're going to get exclusive access by default.  So if the tool opens the text file without specifying sharing, you're not going to be able to read it from your application while the tool has it open.

You should be using CreateFile(), not OpenFile(), which is for compatability with 16 bit Windows apps, and specify sharing semantics in the call.

Could it be that when you're in debug mode, it takes long enough that the tool manages to complete and terminates, so that you're then able to open it with exclusive access?  Or, you're delaying enough that file buffers in the tool are eventually flushed out to disk.  Disk i/o likes to work in chunks of data related to the sector size on the disk (cluster size in Windows) so if the tool does lots of small writes to the file, this could be getting postponed, as it's not efficient to go to the disk each time.  It's called lazy flushing, and Windows OS's do this.

The tool could use FlushFileBuffers() function to force the data to be written out to disk - maybe it does or maybe it doesn't - do you have the source code for the tool?  If the standard C library is being used for file i/o in the tool, there's a way to flush buffers there too.  But whoever authored the tool may not have provided for the way you're trying to use the file.  If that's the case, there's not much you can do about it I think other than wait for the tool to eventually write out to disk.

Do you have some other common resource in use by both your code and the tool?    Maybe they're contending over something other than the file, and the tool is getting suspended and not writing to disk.  In debug mode, I imagine your application thread gets suspended when you're single stepping or at a breakpoint - this would allow the tool to run freely if there's resource contention of some kind.


Menchar

[ISITEC_RIEPER]

Thanks for your answers - i had in mind that the difference between
LaunchExecutableEx an LaunchExecutable is that LaunchExecutableEx waits for
the startet application to exit - but if found out that i was wrong. I have
to use system() to wait for the application to exit or use
LaunchExecutableEx and than use the handle with ExecutableHasTerminated() to
wait for the application to exit.
Thats because i had the errors i described...... shame on me :o(

But the problem about OpenDocumentInDefaultViewer() still exists:
I try to open a directory (explorer). Mostly everything works fine, but
sometimes i can see while i'm debugging that the function is called but
nothing happens. Than it takes a long time before the Explorer suddenly
opens. I guess that i have to force Windows to execute the command..... but
how?

Norbert




"menchar" <x@no.email> schrieb im Newsbeitrag
news:1181502680310-533748@exchange.ni.com...
> Are you trying to read the file while the tool has it open for
> writing?Unless you specify sharing semantics when opening the file, you're
> going to get exclusive access by default.&nbsp; So if the tool opens the
> text file without specifying sharing, you're not going to be able to read
> it from your application while the tool has it open.You should be using
> CreateFile(), not OpenFile(), which is for compatability with 16 bit
> Windows apps, and specify sharing semantics in the call.Could it be that
> when you're in debug mode, it takes long enough that the tool manages to
> complete and terminates, so that you're then able to open it with
> exclusive access?&nbsp; Or, you're delaying enough that file buffers in
> the tool are eventually flushed out to disk.&nbsp; Disk i/o likes to work
> in chunks of data related to the sector size on the disk (cluster size in
> Windows) so if the tool does lots of small writes to the file, this could
> be getting postponed, as it's not efficient to go to the disk each
> time.&nbsp; It's called lazy flushing, and Windows OS's do this.The tool
> could use FlushFileBuffers() function to force the data to be written out
> to disk - maybe it does or maybe it doesn't - do you have the source code
> for the tool?&nbsp; If the standard C library is being used for file i/o
> in the tool, there's a way to flush buffers there too.&nbsp; But whoever
> authored the tool may not have provided for the way you're trying to use
> the file.&nbsp; If that's the case, there's not much you can do about it I
> think other than wait for the tool to eventually write out to disk.Do you
> have some other common resource in use by both your code and the
> tool?&nbsp;&nbsp;&nbsp; Maybe they're contending over something other than
> the file, and the tool is getting suspended and not writing to disk.&nbsp;
> In debug mode, I imagine your application thread gets suspended when
> you're single stepping or at a breakpoint - this would allow the tool to
> run freely if there's resource contention of some kind.Menchar