openttextfile ForAppend ignores EOF (Ctrl-Z) ?

[R.Wieser]

Hello all,

Just now I opened a textfile for append and add some content. To my
surprise the EOF (0x1A, Ctrl-Z) char that was terminating the origional file
was still there, with the appended content after it.

I've taken another look at how I should be using the 'opentextfile' method,
but cannot find anything in regard to how to handle an (terminating) EOF
char.

Currently I've changed the script to a read all -> strip EOF -> append
content -> write all sequence, but would like to know if I can just, you
know, /append/ to the file.

Regards,
Rudy Wieser

[Mayayana]

"R.Wieser" <***@not.available> wrote

| Currently I've changed the script to a read all -> strip EOF -> append
| content -> write all sequence, but would like to know if I can just, you
| know, /append/ to the file.
|
I had never heard of that and had to look it up:

https://en.wikipedia.org/wiki/Substitute_character

It seems that tradition was ended many years ago and
that using Chr(26) to mark the end of a file is not likely
to be recognized but most software or by Windows. Since
the WSH was written late 20th century, I guess it uses
the "modern" standard. :) Which makes me wonder how you
got a Chr(26) into the file in the first place. You've been
ending files with Ctl+Z all these years and didn't notice
that it didn't do what you expected?

According to wikipedia, Chr(26) is now used as a substitute
character, for characters that can't be rendered. When I
wrote a file ending with Chr(26) it showed up with a square
at the end. If I use Ctl + Z in Notepad it only selects text.
And that's 18 year old, XP Notepad. How did you not notice
all of that? (You might also be interested to know that you
can no longer buy hay for your horse on the town common.
Why? Beats me. The world's gone crazy. :)

[R.Wieser]

Mayayana,

Since the WSH was written late 20th century, I guess
it uses the "modern" standard. :)

Grumble, grumble. All that newfangled stuff ... grumble. :-)

Which makes me wonder how you got a Chr(26) into
the file in the first place.

Easy. I've got a DOS era text-editor here (Norton Editor, 1986) which does
that when I close the file.

And yes, that still is my to-go editor. It still works well and I do not
seem to require more that what its made for, ASCII text editing. Heck, it
even got a "reformat paragraph" feature !

You've been ending files with Ctl+Z all these years and
didn't notice that it didn't do what you expected?

:-) It only became a probblem when using WSH and trying to append to that
file. In other cases (opening the file with Notepad or Write) I simply
delete the last, displayed as a rectangle, char and append to the bottom.
The editor has no problem reading files without an EOF.

You might also be interested to know that you can no longer
buy hay for your horse on the town common. Why? Beats me.
The world's gone crazy. :)

First the the horse whips, and now the hay too ? Whats next, my T65
rotatry dial landline phone (still got a one laying about here - not
attached though) ? :-)

Yeah, yeah, I know I'm a "bit" conservative. I simply seldom replace whats
still working well. This (the pasting from Windows) is the second
"problem" I had with it (the first one was not having LFN support, but that
was rather easily fixed - and I did that only about two years ago).

Hmmm... I might try to find where it writes that EOF, and NOP it out ...
Ofcourse, that would only solve it for that one program.

Regards,
Rudy Wieser

[Mayayana]

"R.Wieser" <***@not.available> wrote

| First the the horse whips, and now the hay too ? Whats next, my T65
| rotatry dial landline phone (still got a one laying about here - not
| attached though) ? :-)
|
| Yeah, yeah, I know I'm a "bit" conservative.

I'm not so far off. I don't use a cellphone or texting.
(Why volunteer to be tracked and interrupted everywhere I go?)

I also have two phones hardwired into my landline.
Not rotary, but not portable. Reason? If there's a
blackout, none of my portable phones work! They
need power to the base. Crazy design. The handset
charges, but the base and answering machine go
dead without power.

I'm not embarassed. I just
think of all those rich yuppies in NYC during the big
hurricane 3-4 years back, who had to hike up to the
other end of Manhattan so they could plug in their
cellphones, connect to the outside world, and find
out there was a hurricane. :)

But they don't learn.
Today those same people probably have empty
refrigerators and depend on "DoorDash" to deliver food
to them. Next blackout they'll be eating cockroaches
and trying to start campfires with their iPhone
flashlights.

[R.Wieser]

Mayayana,

Post by Mayayana
I'm not so far off. I don't use a cellphone or texting.
(Why volunteer to be tracked and interrupted everywhere I go?)

:-) Neither am I . First because I didn't want to get interrupted, but
nowerdays because of the phone not being under my control - with tracking
definitily as one of the "do not want!" pain points.

Post by Mayayana
I also have two phones hardwired into my landline.

Just one here. Pushbutton (DTMF). And although I could throw away my
landline and let my ISP handle it (/much/ cheaper) I still hesitate. Power
outages are not the a common occurance where I live, but if (when) the modem
dies I've got nothing to contact them with to fix it. You might say that
is the downside of /not/ owning a smartphone ...

Regards,
Rudy Wieser

[R.Wieser]

Post by Mayayana
It seems that tradition was ended many years ago
and that using Chr(26) to mark the end of a file is
not likely to be recognized but most software or by
Windows.

I just remembered that that EOF was sometimes used at the end of a
text-header of a further binary file, so you could 'TYPE' the file and get
info - but not the on-screen garbage of the binary part.

I just tried it, and indeed 'TYPE' still seems to stop at that EOF
character. :-)

Regards,
Rudy Wieser

[JJ]

Post by R.Wieser
Hello all,
Just now I opened a textfile for append and add some content. To my
surprise the EOF (0x1A, Ctrl-Z) char that was terminating the origional file
was still there, with the appended content after it.
I've taken another look at how I should be using the 'opentextfile' method,
but cannot find anything in regard to how to handle an (terminating) EOF
char.
Currently I've changed the script to a read all -> strip EOF -> append
content -> write all sequence, but would like to know if I can just, you
know, /append/ to the file.
Regards,
Rudy Wieser

I also starting to get fed up with TextStream limitations. In your case,
it's the inability to file-seek backward, or do a file-seek with write-file
mode, using the Skip() method.

I haven't checked thoroughly, but ADO's Stream may be a better file stream
object.

[Mayayana]

"JJ" <***@vfemail.net> wrote

| I also starting to get fed up with TextStream limitations. In your case,
| it's the inability to file-seek backward, or do a file-seek with
write-file
| mode, using the Skip() method.
|

I don't think I've ever even tried Skip or SkipLine.
It seems so much more efficient to just read the whole
thing in and then deal with it as a string. If I need to
separate lines I just do a Split.
The only time I don't use ReadAll is when I'm treating
it as a binary file. Then I use Read(file length).

With VB it's similar. Reading or writing a file to disk
is incredibly fast. Working with strings is incredibly
fast. The only thing that's slow is concatenation. For
that I use arrays and Join.

[JJ]

Post by Mayayana
I don't think I've ever even tried Skip or SkipLine.
It seems so much more efficient to just read the whole
thing in and then deal with it as a string. If I need to
separate lines I just do a Split.
The only time I don't use ReadAll is when I'm treating
it as a binary file. Then I use Read(file length).
With VB it's similar. Reading or writing a file to disk
is incredibly fast. Working with strings is incredibly
fast. The only thing that's slow is concatenation. For
that I use arrays and Join.

It's slow for accessing partial data of big files where the needed data is
at offset 100MB+. Also, the Skip() method works more like Read() rather than
simply changing the file pointer, because it took more than a second to
Skip() 100MB+ characters.

[Mayayana]

"JJ" <***@vfemail.net> wrote

| > With VB it's similar. Reading or writing a file to disk
| > is incredibly fast. Working with strings is incredibly
| > fast. The only thing that's slow is concatenation. For
| > that I use arrays and Join.
|
| It's slow for accessing partial data of big files where the needed data is
| at offset 100MB+. Also, the Skip() method works more like Read() rather
than
| simply changing the file pointer, because it took more than a second to
| Skip() 100MB+ characters.

I see you're right. Personally I think there's a problem
with design and planning if anyone's making files that big,
but I got curious, anyway. I have a text version of the Bible.
I put together 40 copies, for a total of about 170 MB. I
then read 40 bytes at offset 120,000,000. It took 8 seconds
in VBS and 5.5 seconds in VB. But the looking closer it turned
out that nearly all of that time must be used to allocate
memory to read in the file. The time required to do
s = Mid(s170K, 120000000, 40) didn't even register. It showed
as 0. Likewise, doing Instr(120000000, s170K, "Jesus") took
less than 1 ms.

So I guess what that means is that if you need to read one
section of text from 100 giant files, it will be slow. But if you
need to read 200 sections of text from one giant file, it won't
take much longer than it takes to load the file.

I didn't realize the load would take so long. I typically deal
with files under 5 MB and read/write time is negligible. In fact,
with my script/HTML editor I now load the file and then run
it through a tokenizer, checking every byte/sequence, to see
whether it's valid UTF-8. All of that still only takes a few ms.

[Wendelin Uez]

Post by Mayayana
But if you
need to read 200 sections of text from one giant file, it won't
take much longer than it takes to load the file.

I'm not sure, but perhaps loading the huge disk file as memory mapped file
might be faster because it is mainly a copy action rather than a line-byline
reading and the allocation size is not dynamic but static (because must be
predefined)?

wuez

btw: is there an english speaking VB6 user group out there, I only know a
german speaking one.

[Mayayana]

"Wendelin Uez" <***@online.de> wrote

| btw: is there an english speaking VB6 user group out there, I only know a
| german speaking one.
|
microsoft.public.vb.general.discussion

There was a bit of a civil war some years ago, as some
of the MVPs tried to make us switch to VB.Net, but it
was eventually resolved. The group above is pretty much
the last active VB6 group. The VB.Net groups generally
have "dotnet" in their name.