File Closed - but Windows doesn't agree

[CoastalMaineBird]

how do you get a refnum of the file, in order to use the Close function, without using the Open function?

You had it when you NEWed the file. You converted it to a path (I don't know why - you already had a path), and then threw it away.

It's your responsibility to hold on to the refnum and use it when you WRITE (or READ) the file, and also CLOSE it.

[CoastalMaineBird]

Value Changed makes more sense.

Indeed. Consider the case where you attach an F1 keycode to your switch. Hitting F1 would then toggle your switch, but NOT trigger your event, if it's based on MOUSE UP.

[Broken_Arrow]

I'm starting to see the light. I've lost control of the file over the course of adding to the program.

[altenbach]

A few more notes:

• You don't need a wait statement, the timeout determines the loop rate.
• You don't need any of the inner FOR loops, they serve no purpose. The code cannot continue until the file dialog (and the immediately following code) completes. Think dataflow!
• Both file dialogs need to handle a cancel.
• You only need one case structure in the Load/NEW event case. The two buttons are mutually exclusive and one is always true, else the event would not have occurred. 😉

Attached is a quick draft how you would carry the file name and refnum in shift registers to give you some ideas. It stlll needs work, e.g. wiring of the errors, and general code cleanup. I did not test if it even works, because I don't have your subVI.

[Broken_Arrow]

COOL
I learned two things from your vi. I should have used a shift register, and --- Clear Errors.vi rocks!

I knew about the redundancy of the two buttons in one case. That was written like that so I could see both functions at the same time inside one case structure. Doesn't make it right, though.

[Dynamik]

Hi Christian,

      I came across Richard's ("Broken Arrow's") accolades re: Clear Error.vi, and confess that I totally miss the point of how it functions when called as it is here - not in a chain.

Not to poke fun, but, what am I missing here?

[altenbach]

Here it is just a bandaid solution. 😉

By default, automatic error handling is enabled and you'll get an error dialog whenever the error output is not wired and an error occurs. Here, an error occurs in the cases where (1) the refnum is not yet set AND a (2) close node is encountered, e.g. at the start of the program. Wiring the error output ensures that nothing pops up. 🙂

Error handling should definitely be improved in the example!

[Dynamik]

Ahhh, oK - I must have "show errors" off - but it could be useful...

Thank you! 

[Broken_Arrow]

That Clear Errors vi addressed a situation I was having: if someone pushed a button twice (to close the file) the second time would generate an error. I was using a local read to see if the path = empty = don't try to close a file (which isn't there). The Clear Errors just works easier. This is an example, IMO, where the error is just a nuisance.

[CoastalMaineBird]

if someone pushed a button twice (to close the file) the second time would generate an error. I was using a local read to see if the path = empty = don't try to close a file (which isn't there).

I think good interface rules dictate that you disable and gray the button if it can't be used at the moment. This does several things:
1... Let the user know that they can't close the file (it's already closed).
2... Makes your code easier - you don't have to handle the special cases - if the button was clicked, respond to it, since you know that it can't be clicked if it shouldn't be.