Importing numbers to notepad (.txt files)

Hey,
First off all, i'm new here so hello everyone.
I've been doing 'Visual Basic' for over a year now, i'm not a guru but I know the basics.
That's why I came to this forum, to get some help.

Anyway, I have this program the calculate numbers and I want the output of those numbers will be in notepad.
What I need to know is how to create a txt file using visual basic (deciding the name of the file), how to add new content to the txt file.

If someone could help me with this it'll be great.
I need to finish this as soon as possible.

Thanks,
Kedmyster

Like your self am new here and vb is basic for me but i have picked up bits .

This bit of code sends the input of the txtbox to a log file,dont know if thats what your after .apparently the log.txt has to be were you save the project but i think this makes a log for you, not sure anyways good luck.

Open App.Path & "\log.txt" For Append As #1
Print #1, Text1.Text
Close #1

For Output will create a new file everytime.

For Append is for adding to the end of an existing file.

The name of the file is not relevant. The file extension is all that really matters. If you use .LOG or .TXT you create a file that most likely is associated with NOTEPAD on a user machine.

What WINDOWS APPLICATION is associated with what file extensions can be changed from any FOLDER window, under TOOLS menu, FOLDER options menu, FILE TYPES tab.

Although we also use OPEN here - and I'm not suggesting you should not, we mostly use FSO - FILE SYSTEM OBJECT - to open/read/write to files now. Once you bang into some of the limitations of OPEN (file width - leading spaces on rows) - you find that FSO gets around all these.

HTH

Heh, thanks for the help though I found it by myself already :P
Program works preety good now.

Thanks again!

Any chance of a example code there Szlamany..Please

I did a quick cut/paste - not at the office right now, so it was kind of hard to put this together.

This loops through all the files in a folder - when a matching name is found - it opens it with FSO and reads the data in...

VB Code:

Dim fso As New FileSystemObject, tso As TextStream, fdr As Folder, fil As File
 
    ' gstrInput contains the path and filename of the text file to read
    ' optionally it can contain a wildcard * in the filename portion
 
    i = InStr(gstrInput, "*")           ' Is there a wildcard 
    If i <> 0 Then                          ' yes there is
        j = InStrRev(gstrInput, "\", i)     ' Search from the end of the string for the "folder" character
        gstrfolder = Left(gstrInput, j)         ' Cut off the folder
        gstrInput = Mid(gstrInput, j + 1)   ' Cut off the filename
        j = InStr(gstrInput, "*")               ' Find the wildcard position
        gstrLeft = Left(gstrInput, j - 1)       ' Now we know the left part
        gstrRight = Mid(gstrInput, j + 1)   ' and the right-part
        gstrInput = ""                      ' Clear this vbl for later
 
        ' Now we loop throuhg the folder/filenames
        Set fdr = fso.GetFolder(gstrfolder)
        For Each fil In fdr.Files
            Debug.Print fil.Name
            If Left(fil.Name, Len(gstrLeft)) = gstrLeft And Right(fil.Name, Len(gstrRight)) = gstrRight Then  ' Does the left part match and the right part match
                gstrInput = gstrfolder & fil.Name  ' Then we have a file to process
                Exit For
            End If
        Next
    End If
    
    If gstrInput = "" Then GoTo All_Done  '  No more files to process
    
    Set tso = fso.OpenTextFile(gstrInput)  ' Lets open that file
      
    'Open gstrInput For Input As #1
    
    Do While Not tso.AtEndOfStream    ' These are "self-commenting" keywords in my opinion - I think I will stop here...
        s1 = tso.ReadLine
'        Line Input #1, s1
        lngReadCnt = lngReadCnt + 1
 
   ... 
 
   Loop
    
    tso.Close

Thanks:thumb:

Just saying my opinion: you need to add an extra reference to your program to get FSO, which I don't like. I find it much easier to just open a file in Binary, read the whole file and then if required, convert it to a string. Binary opening and converting is two times faster than the regular way to open a file, while FSO is very slow even when compared to the regular way!

If you need a proof about this, I have attached a code and a compiled program so you can see the differences with your own eyes (and if you don't trust the precompiled EXE, you can just check the code and compile a version of your own). The code by default opens c:\autoexec.bat 10000 times with the selected opening method and then shows the time that went to do this. All three functions return a string you can immediately display in a textbox (this gives a major slowdown to the Binary way, because the function needs to convert the read data to a string - just imagine how fast it would be without the slow string conversion! :))

Also, szlamany: I'd like to see a problematic file, dealing with the file length and leading rowspaces problem. I have high believes the problems might be because of bad coding instead of a limitation with Open.


Oh yes, the results on my machine:
- Binary: 450 - 500 ms
- Input: 950 - 1050 ms
- FSO: 4175 ms was the fastest result I got


What do I say? Use Binary, always! :D

Merri - I can understand your issue with the reference - that's why we shunned FSO for our first two years at this.

We process many import and export files for the health industry (love this HIPAA EDI - been doing lots of billable hours on this).

When a client gives us a 1000 byte CR/LF delimited file from some IBM mainframe - with 2000 claim rows in it, we prefer to go line by line in the TEXTIMPORT program we have. It loads the data directly into SQL - so it's a one/stop process anyway.

When we tested our TEXTOUTPUT process with this same 1000 byte record, we could not get the other side to be able to read the file until we started using FSO.

We are firm believers in ripping existing code for new applications - so once FSO proved to work in places that OPEN did not, we baled on OPEN and choose FSO.

That is not to say that if we were going to read a .INI file when an app first started that we would not use OPEN - that's a perfect place for it.

As for reading the file in BINARY - probably would not want the "extra development/maintenance" overhead associated with that. Granted speed is great - but some junior programmer re-visiting that code 3 years later would most like break it :D

I started to think FSO can't be that slow and did some optimization to each of the functions. Thus now the results are much more equal:

- Binary: 410 ms avarage
- FSO: 415 ms avarage
- Input: 450 ms avarage

Even though now FSO is about just as fast as Binary, it doesn't change the fact FSO has a large overhead and bigger memory usage compared to Binary.

What I optimized?
- Binary read buffer is redimmed only once
- FSO is now initialized and freed from the memory only once
- FileLen is called only once (appears to be a very slow function to call)


As for using binary instead of FSO, I think binary code might be even more clear than FSO, depending of the situatation. Atleast the code you posted above is hard to read, but mostly because it is uncommented. Commented code is always much easier than code you need to figure out yourself - thus I think there shouldn't be too big problems using Binary, even when there is a novice having a visit :)

Anyways, for small files I see no big point using FSO: it is pretty much a waste of memory - and I still haven't got a case when Open doesn't work properly. For bigger files (which you also need to process), binary is much better because of the speed.

So, personally I keep not using FSO as I see the ways VB provides natively are superior to it.

Merri - I've commented the code - hope you like it now :D