Chr(9)

[Sash]

Is there a way to indicated a certain number of tabs? I have a program that
reformats data into a tab delimited file to be imported into another program.
It's really grown and I'm trying to consolidate code. I thought that if I
could eliminate a bunch of Chr(9) & Chr(9) & Chr(9) & Chr(9) that would help.

 

[Stuart McCall]

Is there a way to indicated a certain number of tabs? I have a program
that
reformats data into a tab delimited file to be imported into another
program.
It's really grown and I'm trying to consolidate code. I thought that if I
could eliminate a bunch of Chr(9) & Chr(9) & Chr(9) & Chr(9) that would
help.

In addition to Dirk's suggestion, it would be better if you used a variable:

Dim strTab As String * 1

strTab = Chr$(9)

Then you could use it like this:

String(5, strTab)

That way the code doesn't have to call the Chr$ function all the time.

 

[Dirk Goldgar]

In addition to Dirk's suggestion, it would be better if you used a
variable:

Dim strTab As String * 1

strTab = Chr$(9)

Then you could use it like this:

String(5, strTab)

That way the code doesn't have to call the Chr$ function all the time.

In fact, there is already a VBA defined constant for this, vbTab. I just
didn't want to introduce extra complexity in the answer. But there is not a
whole lot of difference between using Chr$(9) and using vbTab. While
referring to vbTab is slightly faster, the difference is small enough to
make me wonder if Chr$(<constant>) is resolved inline at compile time.

 

[Stuart McCall]

In fact, there is already a VBA defined constant for this, vbTab. I just
didn't want to introduce extra complexity in the answer. But there is not
a whole lot of difference between using Chr$(9) and using vbTab. While
referring to vbTab is slightly faster, the difference is small enough to
make me wonder if Chr$(<constant>) is resolved inline at compile time.

--
Dirk Goldgar, MS Access MVP
www.datagnostics.com

(please reply to the newsgroup)

You may well be right about the inline resolution <shrug>, however, Chr$(9)
isn't Chr$(<constant>) but rather Chr$(<literal>), so I'm not sure the
compiler could optimize this. If it did it would need to take two passes to
do it...

And I totally forgot about the intrinsic vbTab. Duh. Must be getting rusty
(I retired in '06)

 

[Dirk Goldgar]

You may well be right about the inline resolution <shrug>, however,
Chr$(9) isn't Chr$(<constant>) but rather Chr$(<literal>), so I'm not sure
the compiler could optimize this. If it did it would need to take two
passes to do it...

I don't follow you there. I agree that 9 is a literal, not just a constant,
but that should be even easier to optimize.

And I totally forgot about the intrinsic vbTab. Duh. Must be getting rusty
(I retired in '06)

I'm getting pretty rusty myself, it seems these days, even though I'm a good
many years (I hope) from retirement.

 

[Stuart McCall]

inline:

I don't follow you there. I agree that 9 is a literal, not just a
constant, but that should be even easier to optimize.

Well my thinking is that because the compiler has encountered a literal, how
does it know to optimize without scanning for more instances? After all, any
Chr$ call with a literal argument could be literally (sorry) anything. And
it wouldn't be worth optimizing if there was only 1 call.

I've never written a full blown, optimizing compiler so I may well be
blowing smoke. It just goes against the grain to make unnecessary multiple
function calls.

I'm getting pretty rusty myself, it seems these days, even though I'm a
good many years (I hope) from retirement.

Well I must say you hide it well...

 

[Dirk Goldgar]

Well my thinking is that because the compiler has encountered a literal,
how does it know to optimize without scanning for more instances? After
all, any Chr$ call with a literal argument could be literally (sorry)
anything. And it wouldn't be worth optimizing if there was only 1 call.

I see what you're saying, but I was thinking that the compiler could easily
recognize Chr$(<literal>) and just replace it with the character itself.
There's no need for any function call in such a case. Now admittedly, the
overhead of having the compiler include logic to recognize such things might
outweigh the value of the substitution, but I have no idea how the folks who
wrote VBA thought about that issue.

I've never written a full blown, optimizing compiler so I may well be
blowing smoke.

Me, neither. I wrote an assembler once, for one of my college courses.
That was fun.

It just goes against the grain to make unnecessary multiple function
calls.

I'm with you there.

Well I must say you hide it well...

You're too kind.