Blank line at top of txt file

  • Thread starter Thread starter slickdock
  • Start date Start date
S

slickdock

When I export my report as a txt file, there is a blank line at the top of
the txt file. There is no reason for the blank line--If I export it as an
rtf, there is no blank line. It's a very basic simple report, one field only,
creating a list.

I did a google search and found others with the same complaint, but found no
solution. There was one suggestion that it was the fault of the printer
driver, and to change to a generic driver, but that didn't work.
 
slickdock said:
When I export my report as a txt file, there is a blank line at the top of
the txt file. There is no reason for the blank line--If I export it as an
rtf, there is no blank line. It's a very basic simple report, one field
only,
creating a list.

I did a google search and found others with the same complaint, but found
no
solution. There was one suggestion that it was the fault of the printer
driver, and to change to a generic driver, but that didn't work.
Click to expand...

This is a 'kludge' solution which you can resort to if you don't find
anything better.

You can post-process the file to remove the leading carriage return, like
this:

Dim f As Integer, b As String

f = Freefile
Open "C:\Temp\MyTxtFile.txt" For Binary Access Read As f
b = Space$(LOF(f))
'Read the file from the third byte, bypassing the CrLf
Get #f, 3, b
Close f

'Delete the original file
Kill "C:\Temp\MyTxtFile.txt"

Open "C:\Temp\MyTxtFile.txt" For Binary Access Write As f
'Write out the whole string as a new file
Put #f, , b
Close f

(Use your own path to the file, of course)

HTH
 
Oops. Slight correction:

b = Space$(LOF(f))

should read:

b = Space$(LOF(f) - 3)
 
Just shows that working late is a false economy.

A correction to my correction:

It should read: b = Space$(LOF(f) - 2)

Duh! <yawn> It's late here. I'm off to bed. Nighty night.
 
Beautiful. Thank you so much. What course could I enroll in to learn stuff
like that?
 
Also, since I'm a vb beginner, if I include this in my Access 2002 mde file
for distribution, is there anything in it that may prevent it from working on
many different machines, with different Windows operating systems and various
levels of how up to date they maintain their windows updates?
 
Stuart's solution was just straight VBA. It should work on any
configuration. The only issue would be if you've included references to
other libraries that get broken: the VBA library is the last one checked, so
if some other library is broken, it can (and will) affect VBA code.
 
..... or if you happen to not have write permissions to the folder you're
saving the file to... you'll want to verify that as well.


--
Jack Leach
www.tristatemachine.com

"I haven't failed, I've found ten thousand ways that don't work."
-Thomas Edison (1847-1931)
 
slickdock said:
Beautiful. Thank you so much. What course could I enroll in to learn stuff
like that?
Click to expand...

You're welcome.

No idea about courses. I've never been on one, apart from the golf course,
of course. (sorry) :-)

Personally, I'd like to know why you're getting a leading CrLf, because I
just tested a txt export and didn't get the same result. On the other hand,
if the code works, why bother? We can try and get to the bottom of it or you
can just run with the pos-process. The choice is yours (gasp).
 
Jack Leach said:
.... or if you happen to not have write permissions to the folder you're
saving the file to... you'll want to verify that as well.
Click to expand...

Now come on Jack. Is it late where you are too? <g> If that were the case,
the export would've failed also (the code replaces the file in situ).
 
One more thing. Jack's comment reminded me that it would be as well to
ensure the export worked before running the post-process code. The easy way
to do that is to Kill the file before the export, then check to see if it
exists afterwards. If so then the export worked ok.

So a revised, safer solution would be:

Dim f As Integer, b As String
Dim FileName As String

FileName = "C:\Temp\MyTxtFile.txt"

Kill FileName

'Do the export

'Test to see if file exists
If Dir$(FileName) <> "" Then
f = Freefile
Open FileName For Binary Access Read As f
b = Space$(LOF(f) - 2)
'Read the file from the third byte, bypassing the CrLf
Get #f, 3, b
Close f

'Delete the original file
Kill FileName

Open FileName For Binary Access Write As f
'Write out the whole string as a new file
Put #f, , b
Close f
End If

(this is the way of it with kludges. There's always something else turns up
that needs to be covered)

Notice I put the file path into a variable. That's because it's being used
too much now to leave it as a literal string (a classic one-to-many
situation).
 
Now come on Jack. Is it late where you are too?

Not late... but that's what happens when you have twenty things going on and
still try to be helpful :|

But... wait... what's this???

<quote>
....Jack's comment reminded me that it would be as well to ensure the export
worked before running the post-process code....
</quote>

Maybe it was something to think about after all!

Safety First! :-)

--
Jack Leach
www.tristatemachine.com

"I haven't failed, I've found ten thousand ways that don't work."
-Thomas Edison (1847-1931)
 
Jack Leach said:
Not late... but that's what happens when you have twenty things going on
and
still try to be helpful :|

But... wait... what's this???

<quote>
...Jack's comment reminded me that it would be as well to ensure the
export
worked before running the post-process code....
</quote>

Maybe it was something to think about after all!

Safety First! :-)
Click to expand...

Ok ya got me! <hangs head in shame>
 
Back
Top