XP and string paths

[worf]

I am having "string path problems" when porting an add-in to different
xp machines (This works fine on my XP development machine). See a
reference to the problem here:

http://www.exceltip.com/book-1931841047.html

Is there a way around this problem using code so that my users don't
have to copy all of the sheets to a new workbook in Windows XP in
order to make the VBA string functions work properly?

[Peter T]

I don't see any ref to your problem in that link and not sure what you mean
by "string path problems", nor how copying sheets makes things work. Your
question is very vague.

If (guessing) you are saying your VBA string functions break, your problem
may be due to missing Reference(s). In user's vbe look at Tools/References.

As a temporary fix to get your string functions working, fully qualify back
to VBA, eg

s = VBA.Strings.Left$(sText)

DateTime functions can be similarly affected, possibly others too.

If above fixes best to get to the route of the problem.

Regards,
Peter T

"worf" <tom@****.harry> wrote in message
news:3ggap1p0j7o9efkfu5p89pmua0q2ufh976@4ax.com...
> I am having "string path problems" when porting an add-in to different
> xp machines (This works fine on my XP development machine). See a
> reference to the problem here:
>
> http://www.exceltip.com/book-1931841047.html
>
> Is there a way around this problem using code so that my users don't
> have to copy all of the sheets to a new workbook in Windows XP in
> order to make the VBA string functions work properly?
>

[PerlsB4Swine]

Let's take a look at what the link I posted says about string path
problems:

In the first comment it says, "...However it started falling apart in
Chapter 2 when the Excel VBA Projects included with the book would not
work. This appears to be due to missing VBA references such as "LCase"
and "Format". Where I can find these and how I can install them is not
mentioned anywhere."

The response to that is:

"The errors mentioned in the previous review are caused by changes in
the path to the VBA string functions when using Windows XP. You can
always just enter the code as is written in the book into a new VBA
project using Excel and it will run fine. But the simplest solution is
this:

1.) Open the project that is giving you trouble.
2.) Select 'Move or Copy Sheet...' from the Edit menu.
3.) Choose to Move the selected sheet to a new workbook to create a
copy.
4.) The new workbook should look just like the previous workbook. Only
now the library paths will be updated to what's on your computer and
the program will work. You will have to save the new workbook or the
program will be lost when you close it and you will have to repeat the
above steps."

Does that help you understand how the link I posted describes the
"string path" problem? In short, Excel VBA apparently has trouble
finding string functions when a previously-created workbook is placed
on another Windows XP machine.

If I distribute this app to hundreds of users, I can ask each one of
them to go to Tools/References and look for missing references, or I
can try to fix the problem in code so they don't have to do that. If
"fully qualifying" the string paths with "VBA.Strings" will accomplish
that, then it qualifies as more than a "temporary fix," eh?

I'll give it a try, thanks.


On Tue, 6 Dec 2005 10:27:29 -0000, "Peter T" <peter_t@discussions>
wrote:

>I don't see any ref to your problem in that link and not sure what you mean
>by "string path problems", nor how copying sheets makes things work. Your
>question is very vague.
>
>If (guessing) you are saying your VBA string functions break, your problem
>may be due to missing Reference(s). In user's vbe look at Tools/References.
>
>As a temporary fix to get your string functions working, fully qualify back
>to VBA, eg
>
>s = VBA.Strings.Left$(sText)
>
>DateTime functions can be similarly affected, possibly others too.
>
>If above fixes best to get to the route of the problem.
>
>Regards,
>Peter T
>
>"worf" <tom@****.harry> wrote in message
>news:3ggap1p0j7o9efkfu5p89pmua0q2ufh976@4ax.com...
>> I am having "string path problems" when porting an add-in to different
>> xp machines (This works fine on my XP development machine). See a
>> reference to the problem here:
>>
>> http://www.exceltip.com/book-1931841047.html
>>
>> Is there a way around this problem using code so that my users don't
>> have to copy all of the sheets to a new workbook in Windows XP in
>> order to make the VBA string functions work properly?
>>
>

[Peter T]

It was not at all obvious to me that the higher item in that link was a
response to an item below. Subject lines do not relate to each other. I've
no idea what's inside the file being discussed but I suspect the suggested
solution is specific to that file.

But even having read all that it doesn't describe what occurs or does not
occur that causes your problem, in particular the phrase "string path
problems". I know now that term does not originate from you, but the way it
was used by the author in the response as "the" diagnosis is highly
misleading. As I suggested before, I suspect it's due to a missing
reference. Which may well involve paths, but not directly string paths.

Depending on the missing reference, if indeed that's the problem, you might
be able to fix it your end, eg by setting a ref to the earliest version.
However if it's a ref to some non system registered file that's path
dependent then it will need to be fixed on each machine (might be possible
to do that programmatically).

Until you know and understand the cause of the problems I would strongly
recommend you regard my suggested fix as temporary. It may or may not be OK
to leave that way.

A common cause of such problems is distributing a file built in a later xl
version to earlier versions (always build in the earliest). Though as it
sounds both you and your users all use XP that's unlikely to be the problem.
So I can only guess you have set a ref to something else in your system. But
the simple first thing is ask one of your uses to report any missing
references and go from there - is that not possible.

Regards,
Peter T

"PerlsB4Swine" <listmail@subdimension.com> wrote in message
news:brdbp1lmv0mfssnrfvkb43il3dno7ukg71@4ax.com...
> Let's take a look at what the link I posted says about string path
> problems:
>
> In the first comment it says, "...However it started falling apart in
> Chapter 2 when the Excel VBA Projects included with the book would not
> work. This appears to be due to missing VBA references such as "LCase"
> and "Format". Where I can find these and how I can install them is not
> mentioned anywhere."
>
> The response to that is:
>
> "The errors mentioned in the previous review are caused by changes in
> the path to the VBA string functions when using Windows XP. You can
> always just enter the code as is written in the book into a new VBA
> project using Excel and it will run fine. But the simplest solution is
> this:
>
> 1.) Open the project that is giving you trouble.
> 2.) Select 'Move or Copy Sheet...' from the Edit menu.
> 3.) Choose to Move the selected sheet to a new workbook to create a
> copy.
> 4.) The new workbook should look just like the previous workbook. Only
> now the library paths will be updated to what's on your computer and
> the program will work. You will have to save the new workbook or the
> program will be lost when you close it and you will have to repeat the
> above steps."
>
> Does that help you understand how the link I posted describes the
> "string path" problem? In short, Excel VBA apparently has trouble
> finding string functions when a previously-created workbook is placed
> on another Windows XP machine.
>
> If I distribute this app to hundreds of users, I can ask each one of
> them to go to Tools/References and look for missing references, or I
> can try to fix the problem in code so they don't have to do that. If
> "fully qualifying" the string paths with "VBA.Strings" will accomplish
> that, then it qualifies as more than a "temporary fix," eh?
>
> I'll give it a try, thanks.
>
>
> On Tue, 6 Dec 2005 10:27:29 -0000, "Peter T" <peter_t@discussions>
> wrote:
>
> >I don't see any ref to your problem in that link and not sure what you
mean
> >by "string path problems", nor how copying sheets makes things work. Your
> >question is very vague.
> >
> >If (guessing) you are saying your VBA string functions break, your
problem
> >may be due to missing Reference(s). In user's vbe look at
Tools/References.
> >
> >As a temporary fix to get your string functions working, fully qualify
back
> >to VBA, eg
> >
> >s = VBA.Strings.Left$(sText)
> >
> >DateTime functions can be similarly affected, possibly others too.
> >
> >If above fixes best to get to the route of the problem.
> >
> >Regards,
> >Peter T
> >
> >"worf" <tom@****.harry> wrote in message
> >news:3ggap1p0j7o9efkfu5p89pmua0q2ufh976@4ax.com...
> >> I am having "string path problems" when porting an add-in to different
> >> xp machines (This works fine on my XP development machine). See a
> >> reference to the problem here:
> >>
> >> http://www.exceltip.com/book-1931841047.html
> >>
> >> Is there a way around this problem using code so that my users don't
> >> have to copy all of the sheets to a new workbook in Windows XP in
> >> order to make the VBA string functions work properly?
> >>
> >
>

[PerlsB4Swine]

Thanks, Peter.

I have asked my users about the missing references, and no one has
reported seeing that error listed in Tools/References.

But, if you think about it, what reference would be missing such that
the "Lcase" function is suddenly no longer available to Excel?

I think I see why you and I are not seeing this the same way. I am
using nothing above Excel 9 (Office 2000) constructs. So I have, in
essence, developed in Excel 9 for everything 9 and above. I do not
believe this is necessarily a problem with Excel - it is a problem
that occurs because of Windows XP (not Excel XP). The path to the
string functions (the "string path") that Excel uses has become
incorrect in going from one Windows XP machine to another Windows XP
machine. It's not an Excel problem, it's a Windows problem, but I'm
seeing the end result of it in Excel because that's where I'm using
string functions. If I'd used Word, I'd have had the same problem.

Just thought of a better way to express this:

Imagine a workbook with one module. In that module is one routine, and
here it is:

Public Sub Test()
Dim A as String
Dim b as String

A = "ABC"
b = LCase(A)

msgbox b

End Sub

I compile and run this on my Windows XP machine using Excel 9 and then
I send it to you who's running Excel 10 (let us say) also on Windows
XP. Now this is a pretty simple routine, right? It will *fail* on your
machine because your machine will not be able to find the "LCase"
function.

Now, per the link, one "solution" to this problem is to copy the
sheets, modules, userforms, class modules, etc to a new workbook and
re-save on the new XP machine. Then ***Windows XP*** can find the
string functions again (it rediscovers the correct "string path.")
But, I can't have each one of my Windows XP users doing that - I want
to let Windows XP know, via Excel VBA, how to find the string
functions (e.g., "Lcase") that are used in my Excel add-in.

I hope I've done a better job of explaining the problem (as I see it)
this time. I'm not ignoring your suggestions; I just don't think this
is the usual "missing reference" problem. Somehow it is related to how
Windows XP stores (and recognizes) paths to its own internal string
functions.

Thanks again for taking the time to respond.

On Tue, 6 Dec 2005 17:58:15 -0000, "Peter T" <peter_t@discussions>
wrote:

>It was not at all obvious to me that the higher item in that link was a
>response to an item below. Subject lines do not relate to each other. I've
>no idea what's inside the file being discussed but I suspect the suggested
>solution is specific to that file.
>
>But even having read all that it doesn't describe what occurs or does not
>occur that causes your problem, in particular the phrase "string path
>problems". I know now that term does not originate from you, but the way it
>was used by the author in the response as "the" diagnosis is highly
>misleading. As I suggested before, I suspect it's due to a missing
>reference. Which may well involve paths, but not directly string paths.
>
>Depending on the missing reference, if indeed that's the problem, you might
>be able to fix it your end, eg by setting a ref to the earliest version.
>However if it's a ref to some non system registered file that's path
>dependent then it will need to be fixed on each machine (might be possible
>to do that programmatically).
>
>Until you know and understand the cause of the problems I would strongly
>recommend you regard my suggested fix as temporary. It may or may not be OK
>to leave that way.
>
>A common cause of such problems is distributing a file built in a later xl
>version to earlier versions (always build in the earliest). Though as it
>sounds both you and your users all use XP that's unlikely to be the problem.
>So I can only guess you have set a ref to something else in your system. But
>the simple first thing is ask one of your uses to report any missing
>references and go from there - is that not possible.
>
>Regards,
>Peter T
>
>"PerlsB4Swine" <listmail@subdimension.com> wrote in message
>news:brdbp1lmv0mfssnrfvkb43il3dno7ukg71@4ax.com...
>> Let's take a look at what the link I posted says about string path
>> problems:
>>
>> In the first comment it says, "...However it started falling apart in
>> Chapter 2 when the Excel VBA Projects included with the book would not
>> work. This appears to be due to missing VBA references such as "LCase"
>> and "Format". Where I can find these and how I can install them is not
>> mentioned anywhere."
>>
>> The response to that is:
>>
>> "The errors mentioned in the previous review are caused by changes in
>> the path to the VBA string functions when using Windows XP. You can
>> always just enter the code as is written in the book into a new VBA
>> project using Excel and it will run fine. But the simplest solution is
>> this:
>>
>> 1.) Open the project that is giving you trouble.
>> 2.) Select 'Move or Copy Sheet...' from the Edit menu.
>> 3.) Choose to Move the selected sheet to a new workbook to create a
>> copy.
>> 4.) The new workbook should look just like the previous workbook. Only
>> now the library paths will be updated to what's on your computer and
>> the program will work. You will have to save the new workbook or the
>> program will be lost when you close it and you will have to repeat the
>> above steps."
>>
>> Does that help you understand how the link I posted describes the
>> "string path" problem? In short, Excel VBA apparently has trouble
>> finding string functions when a previously-created workbook is placed
>> on another Windows XP machine.
>>
>> If I distribute this app to hundreds of users, I can ask each one of
>> them to go to Tools/References and look for missing references, or I
>> can try to fix the problem in code so they don't have to do that. If
>> "fully qualifying" the string paths with "VBA.Strings" will accomplish
>> that, then it qualifies as more than a "temporary fix," eh?
>>
>> I'll give it a try, thanks.
>>
>>
>> On Tue, 6 Dec 2005 10:27:29 -0000, "Peter T" <peter_t@discussions>
>> wrote:
>>
>> >I don't see any ref to your problem in that link and not sure what you
>mean
>> >by "string path problems", nor how copying sheets makes things work. Your
>> >question is very vague.
>> >
>> >If (guessing) you are saying your VBA string functions break, your
>problem
>> >may be due to missing Reference(s). In user's vbe look at
>Tools/References.
>> >
>> >As a temporary fix to get your string functions working, fully qualify
>back
>> >to VBA, eg
>> >
>> >s = VBA.Strings.Left$(sText)
>> >
>> >DateTime functions can be similarly affected, possibly others too.
>> >
>> >If above fixes best to get to the route of the problem.
>> >
>> >Regards,
>> >Peter T
>> >
>> >"worf" <tom@****.harry> wrote in message
>> >news:3ggap1p0j7o9efkfu5p89pmua0q2ufh976@4ax.com...
>> >> I am having "string path problems" when porting an add-in to different
>> >> xp machines (This works fine on my XP development machine). See a
>> >> reference to the problem here:
>> >>
>> >> http://www.exceltip.com/book-1931841047.html
>> >>
>> >> Is there a way around this problem using code so that my users don't
>> >> have to copy all of the sheets to a new workbook in Windows XP in
>> >> order to make the VBA string functions work properly?
>> >>
>> >
>>
>

[Peter T]

From everything you've described I'm surprised the problem is not due to a
missing reference. The Lcase error, fixable with VBA.Strings. is indicative.
But to clarify one thing - even if code uses only xl9 constructs if you
build in XP it will can still fail in earlier versions.

It's not directly a path error to the vba's strings library, this is set
with registration in the windows system, but due different versions of the
excel/vba libraries. Ref's to older versions are forwards compatible (except
for a few small things), but newer versions are not backwards compatible.

Just to discount a possibility - make a note of all the ref's in your
original version. Start a brand new project and look at these ref's. Are
both sets identical (if you use userforms add one form to the new project).
If all same means no other ref's to be concerned with.

Can you get to a xl9/2000 machine - rebuild your file from scratch by
copying code. I wouldn't copy sheets from the tab menu, but select the
relevant cells in each sheet and copy paste. It's OK to export your original
modules & import not forgetting any ThisWorkbook or worksheet module code.

Add "Option Explicit" to the top of all modules, debug & compile. It will
break on un- declared variables or mis-matches, but more importantly throw
any code that's non-compatible with xl9. Distribute this xl9 made file and
fingers crossed.

Regards,
Peter T


"PerlsB4Swine" <listmail@subdimension.com> wrote in message
news:bc7cp1p23lo05shvg22gg2hcv9suqgsn1t@4ax.com...
> Thanks, Peter.
>
> I have asked my users about the missing references, and no one has
> reported seeing that error listed in Tools/References.
>
> But, if you think about it, what reference would be missing such that
> the "Lcase" function is suddenly no longer available to Excel?
>
> I think I see why you and I are not seeing this the same way. I am
> using nothing above Excel 9 (Office 2000) constructs. So I have, in
> essence, developed in Excel 9 for everything 9 and above. I do not
> believe this is necessarily a problem with Excel - it is a problem
> that occurs because of Windows XP (not Excel XP). The path to the
> string functions (the "string path") that Excel uses has become
> incorrect in going from one Windows XP machine to another Windows XP
> machine. It's not an Excel problem, it's a Windows problem, but I'm
> seeing the end result of it in Excel because that's where I'm using
> string functions. If I'd used Word, I'd have had the same problem.
>
> Just thought of a better way to express this:
>
> Imagine a workbook with one module. In that module is one routine, and
> here it is:
>
> Public Sub Test()
> Dim A as String
> Dim b as String
>
> A = "ABC"
> b = LCase(A)
>
> msgbox b
>
> End Sub
>
> I compile and run this on my Windows XP machine using Excel 9 and then
> I send it to you who's running Excel 10 (let us say) also on Windows
> XP. Now this is a pretty simple routine, right? It will *fail* on your
> machine because your machine will not be able to find the "LCase"
> function.
>
> Now, per the link, one "solution" to this problem is to copy the
> sheets, modules, userforms, class modules, etc to a new workbook and
> re-save on the new XP machine. Then ***Windows XP*** can find the
> string functions again (it rediscovers the correct "string path.")
> But, I can't have each one of my Windows XP users doing that - I want
> to let Windows XP know, via Excel VBA, how to find the string
> functions (e.g., "Lcase") that are used in my Excel add-in.
>
> I hope I've done a better job of explaining the problem (as I see it)
> this time. I'm not ignoring your suggestions; I just don't think this
> is the usual "missing reference" problem. Somehow it is related to how
> Windows XP stores (and recognizes) paths to its own internal string
> functions.
>
> Thanks again for taking the time to respond.
>
> On Tue, 6 Dec 2005 17:58:15 -0000, "Peter T" <peter_t@discussions>
> wrote:
>
> >It was not at all obvious to me that the higher item in that link was a
> >response to an item below. Subject lines do not relate to each other.
I've
> >no idea what's inside the file being discussed but I suspect the
suggested
> >solution is specific to that file.
> >
> >But even having read all that it doesn't describe what occurs or does not
> >occur that causes your problem, in particular the phrase "string path
> >problems". I know now that term does not originate from you, but the way
it
> >was used by the author in the response as "the" diagnosis is highly
> >misleading. As I suggested before, I suspect it's due to a missing
> >reference. Which may well involve paths, but not directly string paths.
> >
> >Depending on the missing reference, if indeed that's the problem, you
might
> >be able to fix it your end, eg by setting a ref to the earliest version.
> >However if it's a ref to some non system registered file that's path
> >dependent then it will need to be fixed on each machine (might be
possible
> >to do that programmatically).
> >
> >Until you know and understand the cause of the problems I would strongly
> >recommend you regard my suggested fix as temporary. It may or may not be
OK
> >to leave that way.
> >
> >A common cause of such problems is distributing a file built in a later
xl
> >version to earlier versions (always build in the earliest). Though as it
> >sounds both you and your users all use XP that's unlikely to be the
problem.
> >So I can only guess you have set a ref to something else in your system.
But
> >the simple first thing is ask one of your uses to report any missing
> >references and go from there - is that not possible.
> >
> >Regards,
> >Peter T
> >
> >"PerlsB4Swine" <listmail@subdimension.com> wrote in message
> >news:brdbp1lmv0mfssnrfvkb43il3dno7ukg71@4ax.com...
> >> Let's take a look at what the link I posted says about string path
> >> problems:
> >>
> >> In the first comment it says, "...However it started falling apart in
> >> Chapter 2 when the Excel VBA Projects included with the book would not
> >> work. This appears to be due to missing VBA references such as "LCase"
> >> and "Format". Where I can find these and how I can install them is not
> >> mentioned anywhere."
> >>
> >> The response to that is:
> >>
> >> "The errors mentioned in the previous review are caused by changes in
> >> the path to the VBA string functions when using Windows XP. You can
> >> always just enter the code as is written in the book into a new VBA
> >> project using Excel and it will run fine. But the simplest solution is
> >> this:
> >>
> >> 1.) Open the project that is giving you trouble.
> >> 2.) Select 'Move or Copy Sheet...' from the Edit menu.
> >> 3.) Choose to Move the selected sheet to a new workbook to create a
> >> copy.
> >> 4.) The new workbook should look just like the previous workbook. Only
> >> now the library paths will be updated to what's on your computer and
> >> the program will work. You will have to save the new workbook or the
> >> program will be lost when you close it and you will have to repeat the
> >> above steps."
> >>
> >> Does that help you understand how the link I posted describes the
> >> "string path" problem? In short, Excel VBA apparently has trouble
> >> finding string functions when a previously-created workbook is placed
> >> on another Windows XP machine.
> >>
> >> If I distribute this app to hundreds of users, I can ask each one of
> >> them to go to Tools/References and look for missing references, or I
> >> can try to fix the problem in code so they don't have to do that. If
> >> "fully qualifying" the string paths with "VBA.Strings" will accomplish
> >> that, then it qualifies as more than a "temporary fix," eh?
> >>
> >> I'll give it a try, thanks.
> >>
> >>
> >> On Tue, 6 Dec 2005 10:27:29 -0000, "Peter T" <peter_t@discussions>
> >> wrote:
> >>
> >> >I don't see any ref to your problem in that link and not sure what you
> >mean
> >> >by "string path problems", nor how copying sheets makes things work.
Your
> >> >question is very vague.
> >> >
> >> >If (guessing) you are saying your VBA string functions break, your
> >problem
> >> >may be due to missing Reference(s). In user's vbe look at
> >Tools/References.
> >> >
> >> >As a temporary fix to get your string functions working, fully qualify
> >back
> >> >to VBA, eg
> >> >
> >> >s = VBA.Strings.Left$(sText)
> >> >
> >> >DateTime functions can be similarly affected, possibly others too.
> >> >
> >> >If above fixes best to get to the route of the problem.
> >> >
> >> >Regards,
> >> >Peter T
> >> >
> >> >"worf" <tom@****.harry> wrote in message
> >> >news:3ggap1p0j7o9efkfu5p89pmua0q2ufh976@4ax.com...
> >> >> I am having "string path problems" when porting an add-in to
different
> >> >> xp machines (This works fine on my XP development machine). See a
> >> >> reference to the problem here:
> >> >>
> >> >> http://www.exceltip.com/book-1931841047.html
> >> >>
> >> >> Is there a way around this problem using code so that my users don't
> >> >> have to copy all of the sheets to a new workbook in Windows XP in
> >> >> order to make the VBA string functions work properly?
> >> >>
> >> >
> >>
> >
>

[PerlsB4Swine]

Yes, I can test with Excel9/Office2000/WindowsXP, as you described,
and am eager to do so. I originally developed in xl9 on Win XP, but
then rebuilt in xl11 on Win XP because my newer machine happened to
have that. I finally understand what you have been saying.

Will post here with results. Thanks again, Peter, for taking the time
to explain this so thoroughly.

On Wed, 7 Dec 2005 00:44:05 -0000, "Peter T" <peter_t@discussions>
wrote:

>From everything you've described I'm surprised the problem is not due to a
>missing reference. The Lcase error, fixable with VBA.Strings. is indicative.
>But to clarify one thing - even if code uses only xl9 constructs if you
>build in XP it will can still fail in earlier versions.
>
>It's not directly a path error to the vba's strings library, this is set
>with registration in the windows system, but due different versions of the
>excel/vba libraries. Ref's to older versions are forwards compatible (except
>for a few small things), but newer versions are not backwards compatible.
>
>Just to discount a possibility - make a note of all the ref's in your
>original version. Start a brand new project and look at these ref's. Are
>both sets identical (if you use userforms add one form to the new project).
>If all same means no other ref's to be concerned with.
>
>Can you get to a xl9/2000 machine - rebuild your file from scratch by
>copying code. I wouldn't copy sheets from the tab menu, but select the
>relevant cells in each sheet and copy paste. It's OK to export your original
>modules & import not forgetting any ThisWorkbook or worksheet module code.
>
>Add "Option Explicit" to the top of all modules, debug & compile. It will
>break on un- declared variables or mis-matches, but more importantly throw
>any code that's non-compatible with xl9. Distribute this xl9 made file and
>fingers crossed.
>
>Regards,
>Peter T
>
>
>"PerlsB4Swine" <listmail@subdimension.com> wrote in message
>news:bc7cp1p23lo05shvg22gg2hcv9suqgsn1t@4ax.com...
>> Thanks, Peter.
>>
>> I have asked my users about the missing references, and no one has
>> reported seeing that error listed in Tools/References.
>>
>> But, if you think about it, what reference would be missing such that
>> the "Lcase" function is suddenly no longer available to Excel?
>>
>> I think I see why you and I are not seeing this the same way. I am
>> using nothing above Excel 9 (Office 2000) constructs. So I have, in
>> essence, developed in Excel 9 for everything 9 and above. I do not
>> believe this is necessarily a problem with Excel - it is a problem
>> that occurs because of Windows XP (not Excel XP). The path to the
>> string functions (the "string path") that Excel uses has become
>> incorrect in going from one Windows XP machine to another Windows XP
>> machine. It's not an Excel problem, it's a Windows problem, but I'm
>> seeing the end result of it in Excel because that's where I'm using
>> string functions. If I'd used Word, I'd have had the same problem.
>>
>> Just thought of a better way to express this:
>>
>> Imagine a workbook with one module. In that module is one routine, and
>> here it is:
>>
>> Public Sub Test()
>> Dim A as String
>> Dim b as String
>>
>> A = "ABC"
>> b = LCase(A)
>>
>> msgbox b
>>
>> End Sub
>>
>> I compile and run this on my Windows XP machine using Excel 9 and then
>> I send it to you who's running Excel 10 (let us say) also on Windows
>> XP. Now this is a pretty simple routine, right? It will *fail* on your
>> machine because your machine will not be able to find the "LCase"
>> function.
>>
>> Now, per the link, one "solution" to this problem is to copy the
>> sheets, modules, userforms, class modules, etc to a new workbook and
>> re-save on the new XP machine. Then ***Windows XP*** can find the
>> string functions again (it rediscovers the correct "string path.")
>> But, I can't have each one of my Windows XP users doing that - I want
>> to let Windows XP know, via Excel VBA, how to find the string
>> functions (e.g., "Lcase") that are used in my Excel add-in.
>>
>> I hope I've done a better job of explaining the problem (as I see it)
>> this time. I'm not ignoring your suggestions; I just don't think this
>> is the usual "missing reference" problem. Somehow it is related to how
>> Windows XP stores (and recognizes) paths to its own internal string
>> functions.
>>
>> Thanks again for taking the time to respond.
>>
>> On Tue, 6 Dec 2005 17:58:15 -0000, "Peter T" <peter_t@discussions>
>> wrote:
>>
>> >It was not at all obvious to me that the higher item in that link was a
>> >response to an item below. Subject lines do not relate to each other.
>I've
>> >no idea what's inside the file being discussed but I suspect the
>suggested
>> >solution is specific to that file.
>> >
>> >But even having read all that it doesn't describe what occurs or does not
>> >occur that causes your problem, in particular the phrase "string path
>> >problems". I know now that term does not originate from you, but the way
>it
>> >was used by the author in the response as "the" diagnosis is highly
>> >misleading. As I suggested before, I suspect it's due to a missing
>> >reference. Which may well involve paths, but not directly string paths.
>> >
>> >Depending on the missing reference, if indeed that's the problem, you
>might
>> >be able to fix it your end, eg by setting a ref to the earliest version.
>> >However if it's a ref to some non system registered file that's path
>> >dependent then it will need to be fixed on each machine (might be
>possible
>> >to do that programmatically).
>> >
>> >Until you know and understand the cause of the problems I would strongly
>> >recommend you regard my suggested fix as temporary. It may or may not be
>OK
>> >to leave that way.
>> >
>> >A common cause of such problems is distributing a file built in a later
>xl
>> >version to earlier versions (always build in the earliest). Though as it
>> >sounds both you and your users all use XP that's unlikely to be the
>problem.
>> >So I can only guess you have set a ref to something else in your system.
>But
>> >the simple first thing is ask one of your uses to report any missing
>> >references and go from there - is that not possible.
>> >
>> >Regards,
>> >Peter T
>> >
>> >"PerlsB4Swine" <listmail@subdimension.com> wrote in message
>> >news:brdbp1lmv0mfssnrfvkb43il3dno7ukg71@4ax.com...
>> >> Let's take a look at what the link I posted says about string path
>> >> problems:
>> >>
>> >> In the first comment it says, "...However it started falling apart in
>> >> Chapter 2 when the Excel VBA Projects included with the book would not
>> >> work. This appears to be due to missing VBA references such as "LCase"
>> >> and "Format". Where I can find these and how I can install them is not
>> >> mentioned anywhere."
>> >>
>> >> The response to that is:
>> >>
>> >> "The errors mentioned in the previous review are caused by changes in
>> >> the path to the VBA string functions when using Windows XP. You can
>> >> always just enter the code as is written in the book into a new VBA
>> >> project using Excel and it will run fine. But the simplest solution is
>> >> this:
>> >>
>> >> 1.) Open the project that is giving you trouble.
>> >> 2.) Select 'Move or Copy Sheet...' from the Edit menu.
>> >> 3.) Choose to Move the selected sheet to a new workbook to create a
>> >> copy.
>> >> 4.) The new workbook should look just like the previous workbook. Only
>> >> now the library paths will be updated to what's on your computer and
>> >> the program will work. You will have to save the new workbook or the
>> >> program will be lost when you close it and you will have to repeat the
>> >> above steps."
>> >>
>> >> Does that help you understand how the link I posted describes the
>> >> "string path" problem? In short, Excel VBA apparently has trouble
>> >> finding string functions when a previously-created workbook is placed
>> >> on another Windows XP machine.
>> >>
>> >> If I distribute this app to hundreds of users, I can ask each one of
>> >> them to go to Tools/References and look for missing references, or I
>> >> can try to fix the problem in code so they don't have to do that. If
>> >> "fully qualifying" the string paths with "VBA.Strings" will accomplish
>> >> that, then it qualifies as more than a "temporary fix," eh?
>> >>
>> >> I'll give it a try, thanks.
>> >>
>> >>
>> >> On Tue, 6 Dec 2005 10:27:29 -0000, "Peter T" <peter_t@discussions>
>> >> wrote:
>> >>
>> >> >I don't see any ref to your problem in that link and not sure what you
>> >mean
>> >> >by "string path problems", nor how copying sheets makes things work.
>Your
>> >> >question is very vague.
>> >> >
>> >> >If (guessing) you are saying your VBA string functions break, your
>> >problem
>> >> >may be due to missing Reference(s). In user's vbe look at
>> >Tools/References.
>> >> >
>> >> >As a temporary fix to get your string functions working, fully qualify
>> >back
>> >> >to VBA, eg
>> >> >
>> >> >s = VBA.Strings.Left$(sText)
>> >> >
>> >> >DateTime functions can be similarly affected, possibly others too.
>> >> >
>> >> >If above fixes best to get to the route of the problem.
>> >> >
>> >> >Regards,
>> >> >Peter T
>> >> >
>> >> >"worf" <tom@****.harry> wrote in message
>> >> >news:3ggap1p0j7o9efkfu5p89pmua0q2ufh976@4ax.com...
>> >> >> I am having "string path problems" when porting an add-in to
>different
>> >> >> xp machines (This works fine on my XP development machine). See a
>> >> >> reference to the problem here:
>> >> >>
>> >> >> http://www.exceltip.com/book-1931841047.html
>> >> >>
>> >> >> Is there a way around this problem using code so that my users don't
>> >> >> have to copy all of the sheets to a new workbook in Windows XP in
>> >> >> order to make the VBA string functions work properly?
>> >> >>
>> >> >
>> >>
>> >
>>
>