Re: XP and string paths

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

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 *** and copy paste. It's OK to export your original
>modules & import not forgetting any ThisWorkbook or work*** 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@xxxxxxxxxxxxxxxx> wrote in message
>news:bc7cp1p23lo05shvg22gg2hcv9suqgsn1t@xxxxxxxxxx
>> 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@xxxxxxxxxxxxxxxx> wrote in message
>> >news:brdbp1lmv0mfssnrfvkb43il3dno7ukg71@xxxxxxxxxx
>> >> 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 ***...' from the Edit menu.
>> >> 3.) Choose to Move the selected *** 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@xxxxxxxxxx> wrote in message
>> >> >news:3ggap1p0j7o9efkfu5p89pmua0q2ufh976@xxxxxxxxxx
>> >> >> 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?
>> >> >>
>> >> >
>> >>
>> >
>>
>


.

Quantcast