I'm using VB6 to create an output file.
Is there a way to simply output a line to the file with just a form feed
character(CHR(10) in it? No carriage return/line feed. Just a formfeed
character.
Here is how i open the file and write data to it.
Open OutputFile For Output As #OutNum
Print #OutNum, Space(7) + LineString + Space(6)
Any help would be gratefully appreciated.
Thanks,
Tony
LineString = "One" & Chr$(10) & "Two"
--
Rick (MVP - Excel)
"Tony Girgenti" <tony(nospam)@lakesideos.com> wrote in message
news:4E675173-889F-4FDB...@microsoft.com...
Use ";" at the end to prevent VB from appending Chr(13)+Chr(10). Examples:
Print #OutNum, Chr(10);
Print #OutNum, Space(7) + LineString + Space(6) + Chr(10);
Also try:
Debug.Print "ABC";
Debug.Print "DEF"
Output:
ABCDEF
Use Write #
Print # is for line based/formatted data.
--
Dee Earley (dee.e...@icode.co.uk)
i-Catcher Development Team
iCode Systems
> Is there a way to simply output a line to the file with just a form feed
> character(CHR(10) in it? No carriage return/line feed. Just a formfeed
> character.
10 is not a form feed character; it is a line feed character. 12 is a form
feed character.
Wrong.
--
.NET: It's About Trust!
http://vfred.mvps.org
>>> I'm using VB6 to create an output file.
>>>
>>> Is there a way to simply output a line to the file with just a form feed
>>> character(CHR(10) in it? No carriage return/line feed. Just a formfeed
>>> character.
>>
>> Use Write #
>>
>> Print # is for line based/formatted data.
>
> Wrong.
Holy crap, I just skimmed the replies and didn't notice how wrong!
Write # = Same as Print # except with the addition of a bunch of stupid
quotation marks.
Print # = What you should always use even if someone tells you to use Write
#.
Not necessarily--Write # works just fine when used as intended. What is
intended is what is written w/ Write # will be read w/ Input #. If so,
the input is guaranteed to be consistent w/ the previous output
including handling such things as strings w/ embedded blanks, etc.,
correctly w/o the need for adding quotes on output manually or parsing
fields on input.
Not for everything or every purpose but useful for what it provides.
--
Another lame construct. <g>
I dunno, if you just get used to using either Print# and Get/Put, all's well with
the world. Tossing Write# and Input# into the mix just isn't necessary.
> Not for everything or every purpose but useful for what it provides.
I suppose it's possible it's just "not for me", yeah.
"Necessary?" No; never said it was... :)
But, nothing particularly wrong/bad/lame/etc. afaics for what it is
defined to do. (Like blank-embedded strings automagically parsed).
>> Not for everything or every purpose but useful for what it provides.
>
> I suppose it's possible it's just "not for me", yeah.
I consider it somewhat like "GOTO" -- not for mass consumption, perhaps,
but sometimes quite useful.
--
I'm trying really hard to recall my distaste. It was developed in the GW-BASIC
years, early-80s maybe. Maybe even earlier. I guess I never saw the utility of it,
or just knew how to do whatever I needed with Print, so it wasn't something I ever
grew to find a use for either. Ah well, yeah, nothing particularly
wrong/bad/lame/etc other than the confusion it seems to cause in threads like this.
<g>
Probably related to the fact that it would delimit all strings, etc.,
which can make text files somewhat "messy" if don't need them and
similar rules that one could see as "obsessively compulsive".
The thing is, of course, that by utilizing those rules one handles the
not-so-easy cases of the embedded blanks and similar w/o parsing as a
payback.
I suppose I never developed an aversion because most of what I did w/
any dialect of BASIC (which also goes wayback on a multitude of systems)
used machine-only files and the rules were such that it was simple
enough to move from HP85 or similar to ROM dialects on standalone Z80
boards as well as CP/M and/or MSDOS that way.
--
I'm sure that's it, yeah. If I wanna delimit, *I* delimit! :-)
Just in case someone relatively new might be following this thread, it
should be mentioned that just because Print may be considered more useful
and thus more recommended, going into an existing application and
willy-nilly replacing Writes with Prints is not a good idea - as some newbie
I'm close to quickly found out. I, huh ... rather he, wasted quite a few
days answering the phone and putting everything back.
-ralph
My apologies, it shows how long ago I last used them...
And I misread MSDN:
Write # Statement: Writes data to a sequential file.
Print # Statement: Writes display-formatted data to a sequential file.
Next time Karl, you may want to try elaborating slightly :)
Your suggestion worked exactly the way i wanted it to. Thanks for your reply.
Jeff Johnson was right. It's a 12 not a 10.
Thanks for all of the other replies.
Tony
"Nobody" wrote:
> .
>
Hey, consider it a sign of respect, in that I knew you knew how to
remember yourself. ;-)
--
[.NET: It's About Trust!]