One way to avoid problems like this (and they are difficult to find!) is to add
"option explicit" at the top of each module.

This tells excel that you want to be forced to declare your variables. Then
when excel tries to compile your code and it sees something that it doesn't own
and is not one of your variables, you'll get an error. That line will be
highlighted. Two seconds later, you see the problem, fix it and go on your
happy way.

It's a pain to go back to each module that you've written and add declarations
(and "option explicit"), but it might be worth it when you get some free time
(hehehe).

But it is worth starting all new modules (and even the ones in work) this way.
(In fact, there's an option in the VBE that helps you.

Tools|Options|Editor Tab
Check "Require Variable Declaration"

Now each new module will start with "Option Explicit" already there. (You'll
have to add it to existing modules, though.)

And some hints. Use upper and lower case in your variable declarations. If you
later type your variable in all lower (or all upper case), then when you're done
with that line of code, you're variable will change to the case shown in your
Dim statement. (A quick way to see if you typed correctly.)

And one that I've come to like:
When you declare your variables nicely:

Dim wks as worksheet (not just Dim wks), as soon as you hit the dot (wks.),
you'll see a list of properties and methods that are available for that type of
object. It makes it easier to just arrow down and pick off the one you want.

A similar thing can happen if you declare your variables. Say you have a
variable named: ThisIsOneLongVariableNameForAWorksheet.

if you type
thisis
and hit ctrl-spacebar, the vbe will help you by showing you all the available
options that start with those characters. (If you stop at This and hit
ctrl-spacebar, you'll see too many. So try to stop as soon as possible, but
enough to limit the options.)

That makes typos less likely, too.





bw wrote:

Thanks Dave,

It is a type in the message, AND the code.

When I was trying to find the problem on the XP machine, I recorded a macro to find out
what the recorder did, and then copied the value for origin from the recorded macro.

Then when I changed the code on the W2000 machine, I ASSUMED the code was x1
(one), I have now changed it to xl(L) as you have suggested, and surprise, surprise...it
works on both machines.

Pretty sharp of you to catch that error on my part!

Thanks again everyone...
Bernie

On Fri, 25 Jul 2003 23:03:10 -0500, Dave Peterson wrote:
is x1windows (ex-one-windows) a typo in the message or a typo in the code?

Should be XLWindows (ex-ell-windows).




bw wrote:

Well, after all the help, and getting this to work on the XP machine, I now discover
that
the XP code doesn't work on the W2000 machine.

To review, this code works on Windows 2000 (Excel 2002), but not the other
machine:
Workbooks.OpenText Filename:=my2ndFileName, Origin:=437, _
StartRow:=1, DataType:=xlFixedWidth, FieldInfo:=myArray

This code works on Windows XP (Excel 2000), but not the other machine:
Workbooks.OpenText Filename:=my2ndFileName, Origin:=x1Windows, _
StartRow:=1, DataType:=xlFixedWidth, FieldInfo:=myArray

So the problem code is the argument "Origin" value.

So how do I make it compatible for both versions of Excel?

Thanks,
Bernie

On Fri, 25 Jul 2003 23:13:30 GMT, bw wrote:
The following code works with Windows 2000, but not with Windows XP. Can
someone
explain why, and provide a workaround?

Also, what does "TrailingMinusNumbers" do?

Workbooks.OpenText Filename:=my2ndFileName, Origin:=437, _
StartRow:=1, DataType:=xlFixedWidth, FieldInfo:=myArray, _
TrailingMinusNumbers:=True

Thanks,
Bernie



--

Dave Peterson


--

Dave Peterson