PIPEVIEW leaves TMP files

[vefatica]

Every time I use PIPEVIEW I get another vieXXXX.tmp file in %temp.

 

[rconn]

WAD - TCC creates the temp file for V.EXE to display. TCC doesn't know when V is done with it.

 

[vefatica]

Hmmm! I can think of not-too-costly ways to get around that. When V is started, start a clean-up thread, passing it a pointer to a struct containing V's PID and the file name. The thread would wait for the V process, delete the file, and terminate.

 

[AnrDaemon]

Or delete the file after V starts.
The file will be removed once program exits.

 

[rconn]

You're assuming that TCC is the parent pipe process. That is not necessarily the case.

 

[vefatica]

You're assuming that TCC is the parent pipe process. That is not necessarily the case.

I may not fully understand, but some instance of TCC executes PIPEVIEW. Doesn't that instance of TCC know the filename and V's PID?

 

[Charles Dye]

It seems to me that deleting a temp file on exit should be V's responsibility, not TCC's. V.EXE ought to have an option meaning "this is a temp file; delete it when you exit." Idea for the next version?

 

[Charles Dye]

And on the subject of TCC/V integration: It would be nice if TCC had a way to pass a "cosmetic" filename to V, to be displayed in the V title bar instead of the actual filename. That way, given a command like view clip: or view http://www.jpsoft.com/, V would show the original source of the text -- not the filename of a temp file, which the user probably doesn't care about.

 

[vefatica]

It seems to me that deleting a temp file on exit should be V's responsibility, not TCC's. V.EXE ought to have an option meaning "this is a temp file; delete it when you exit." Idea for the next version?

How would V know it's a temp file?

 

[Charles Dye]

How would V know it's a temp file?

A new option, which TCC could pass to indicate this situation.

 

[vefatica]

A new option, which TCC could pass to indicate this situation.

I don't think Rex has anything to say about how V works. Does V already have such an option?

 

[Charles Dye]

I don't think Rex has anything to say about how V works.

No, he'd have to cooperate with Mr. Prineas. I assume that the two are already communicating. In fact, I seem to remember Mr. Prineas being on this forum for a while, though that was some years back.

 

[vefatica]

No, he'd have to cooperate with Mr. Prineas. I assume that the two are already communicating. In fact, I seem to remember Mr. Prineas being on this forum for a while, though that was some years back.

I get it now.

 

[Joe Caverly]

In the registered version of V, there is this dialog box under Tools -> Delete Temporary Files;

Joe

 

[JohnQSmith]

deleting a temp file on exit should be V's responsibility, not TCC's

It should be the responsibility of the program creating the temp file to delete it.

That'd be like the city coming out to fix the water meter at your house, digging a huge hole so they can get at the surrounding pipe and then leaving saying... "It was just a temp hole, you fill it."

 

[rconn]

Hmmm! I can think of not-too-costly ways to get around that. When V is started, start a clean-up thread, passing it a pointer to a struct containing V's PID and the file name. The thread would wait for the V process, delete the file, and terminate.

That would work in a few cases. But not when you've got multiple pipes on the command line, or if TCC terminated before V.

 

[Charles Dye]

It should be the responsibility of the program creating the temp file to delete it.

That'd be like the city coming out to fix the water meter at your house, digging a huge hole so they can get at the surrounding pipe and then leaving saying... "It was just a temp hole, you fill it."

I disagree. V isn't a passive bystander here; it's an active participant in using the file. (And deleting a file once you're through with it is not a particularly onerous chore.)

If there is some way to know when V has opened a handle to the file, then AnrDaemon's approach would work too.

 

[vefatica]

If there is some way to know when V has opened a handle to the file, then AnrDaemon's approach would work too.

I think that depends on whether the file may be opened again. The docs say that further attempts to open it will fail if DeleteFile has marked it for deletion.

 

[AnrDaemon]

The docs say that further attempts to open it will fail if DeleteFile has marked it for deletion.

That's exactly the intent.