VB writing to files

king_of_inismac

Hey guys!

I open two files within one subroutine:

commandFilePath = CurDir & "\input.txt"
commandOutFilePath = CurDir & "\output.txt"

' Open the file for reading
Open commandFilePath For Input As #1

' Open the file for writing the results
Open commandOutFilePath For Output As #2

'I also read data from the input file within this subroutine, this works fine
Line Input #1, FileCommand

However, in another subroutine I try to write to the ouput file, but it gives me a bad filename/number error.

Print #2, "hello, this function is working!"

I think its something to do with the fact that I'm referencing the file from another subroutine. anyone got any ideas?

Cheers,
Martin

is_that_so

commandFilePath = CurDir & "\input.txt"
commandOutFilePath = CurDir & "\output.txt"
If the variable name is local it can only be seen within that subroutine, if you make it global all subroutines can see it or you can pass the filename to the new subroutine.

king_of_inismac

Thats not really the problem. I want the file to be visible to all subroutines, not the path.

T'would be very messy for all subroutines to have to open the file themselves in order to add data to the file.

Is there any way they call all directly use the print function, like
Print #2,"hello"

without having to open the file individually?

Cheers for the help so far!

is_that_so

File and path in this case are pretty much synonymous. It is down to the scope of a variable. If you open a file say #1 in one subroutine, no other subroutine knows about it. If you do need all subroutines to see it then make it global. But to be honest there is no real need for a subroutine that has a specific task to write to a file as well. Call another subroutine anywhere you need to do that

eg

Sub 1

'Do one thing
Call Print Routine
end sub

sub2

'Do another thing
Call Print Routine

end sub

Sub Print Routine
Open "File" for Output as #1
print #1 ,String
Close #1

end sub

RicardoSmith

I know its saying exactly the same thing a different way, but...

The path to the file is all each subroutine needs to know where the file is. So to
make the path, which is a string variable, ummm lets call it sFilePath readable by all sub routines you have to make the scope of the variable (sFilePath) global. Otherwise is only accessible in the sub routine that declared it.

However you should have one routine that writes to the file, not multiple routines. You should make a function that writes to the file and call it within your other routines. Or have the main routine that calls all the subroutines and the file writing routine. Thats would be better IMO. Though since I haven't a clue of what your trying to achieve who knows.

king_of_inismac

Thanks a million man, Couldn't see the wood for the trees there!

Gonna do a good deed tomorrow to spread the good karma

Talliesin

I'd prefer to wrap the file access in a class (presuming that just using FileSystemObject instead isn't reasonable, which alas it often isn't due to some limitations).

This can simplify the calls made in the various routines, and also the class can be built along RAII principles and hence the destructor can ensure it is closed even in the case of an error being raised.

RicardoSmith

Talliesin wrote:

I'd prefer to wrap the file access in a class (presuming that just using FileSystemObject instead isn't reasonable, which alas it often isn't due to some limitations).

This can simplify the calls made in the various routines, and also the class can be built along RAII principles and hence the destructor can ensure it is closed even in the case of an error being raised.

I've not much experience of using classes, myself. What are RAII principles? Why advantages does a class give you over a function in terms of simplifying calls and in error handling?

Talliesin

RicardoSmith wrote:

I've not much experience of using classes

Get practicing! IMO classes should be the second thing you learn about after you've learnt enough syntax and basics of using the IDE to build tutorial applications to learn about them

RicardoSmith wrote:

What are RAII principles?

http://www.hackcraft.net/raii/ is an article I wrote on this. Basicly the lifetime of the object of a class controls the obtaining and releasing of resources like file handles, memory (not much of a concern in VB), window handles etc.
This centralises the burden of handling them in one piece of code, and also means that they are handled correctly even in the case of normal program flow being interupted (such as when an error is raised) without fiddly code to account for each place this could possibly happen.

RicardoSmith

Talliesin wrote:

Get practicing! IMO classes should be the second thing you learn about after you've learnt enough syntax and basics of using the IDE to build tutorial applications to learn about them....

Never had time, too busy on live projects. But thanks for the link.

Talliesin

RicardoSmith wrote:

Never had time, too busy on live projects. But thanks for the link.

Well the reduction in complexity class-based design brings to projects above a certain size should be welcom ethen

RicardoSmith

Talliesin wrote:

Well the reduction in complexity class-based design brings to projects above a certain size should be welcom ethen

I've started working with VB.NET at work and Java at college at night. So I'll let you know!