Macro Will Not Run on Some PCs

[NoVAFolk]

I have a simple workbook that has a macro that parses the
ActiveWorkbook.FullName property to obtain the current path and filename
(".xls" removed). The filename is used later in a
"Workbooks(sParentWorkbook).Activate" statement where sParentWorkbook is
consistently demonstrated to contain the correct value.

The macros in the workbook work properly on my PC regardless of where I
place the spreadsheet to test the functionality.

On some PCs, however, the "Workbooks(sParentWorkbook).Activate" statement
fails with an invalid index diagnostic. In debug mode, the variable
sParentWorkbook has the correct value. The exactly identical spreadsheet, in
the same network location will open and execute without error on my PC.

>> All PCs are running MS Office 2000 9.0.6926 SP-3 <<

Please provide suggestions as to where to look to solve this problem.

[Dave Peterson]

Include the extension (.xls) in sParentWorkbook.

There's a windows setting that allows you to hide or show extensions. I'd bet
there's a difference between the settings on those pcs.

I've never seen it fail when the .xls is included.

But why not just use:

Dim myWkbk as workbook
set myWkbk = activeworkbook
'do a bunch of stuff
mywkbk.activate

'I wouldn't do this, but you could:

sParentWorkbook = activeworkbook.name
'lots of stuff
workbooks(sparentworkbook).activate

..Name won't include the path.



NoVAFolk wrote:
>
> I have a simple workbook that has a macro that parses the
> ActiveWorkbook.FullName property to obtain the current path and filename
> (".xls" removed). The filename is used later in a
> "Workbooks(sParentWorkbook).Activate" statement where sParentWorkbook is
> consistently demonstrated to contain the correct value.
>
> The macros in the workbook work properly on my PC regardless of where I
> place the spreadsheet to test the functionality.
>
> On some PCs, however, the "Workbooks(sParentWorkbook).Activate" statement
> fails with an invalid index diagnostic. In debug mode, the variable
> sParentWorkbook has the correct value. The exactly identical spreadsheet, in
> the same network location will open and execute without error on my PC.
>
> >> All PCs are running MS Office 2000 9.0.6926 SP-3 <<
>
> Please provide suggestions as to where to look to solve this problem.

--

Dave Peterson

[NoVAFolk]

Thank you Dave. Your reply, and Jim's, were right on target. Indeed the
Explorer settings were different on the "non-functioning" PCs. I guess it's
just one of those thnings that one has to take into account from time to time
and I've learned my lesson.

Again, thank you.

"Dave Peterson" wrote:

> Include the extension (.xls) in sParentWorkbook.
>
> There's a windows setting that allows you to hide or show extensions. I'd bet
> there's a difference between the settings on those pcs.
>
> I've never seen it fail when the .xls is included.
>
> But why not just use:
>
> Dim myWkbk as workbook
> set myWkbk = activeworkbook
> 'do a bunch of stuff
> mywkbk.activate
>
> 'I wouldn't do this, but you could:
>
> sParentWorkbook = activeworkbook.name
> 'lots of stuff
> workbooks(sparentworkbook).activate
>
> ..Name won't include the path.
>
>
>
> NoVAFolk wrote:
> >
> > I have a simple workbook that has a macro that parses the
> > ActiveWorkbook.FullName property to obtain the current path and filename
> > (".xls" removed). The filename is used later in a
> > "Workbooks(sParentWorkbook).Activate" statement where sParentWorkbook is
> > consistently demonstrated to contain the correct value.
> >
> > The macros in the workbook work properly on my PC regardless of where I
> > place the spreadsheet to test the functionality.
> >
> > On some PCs, however, the "Workbooks(sParentWorkbook).Activate" statement
> > fails with an invalid index diagnostic. In debug mode, the variable
> > sParentWorkbook has the correct value. The exactly identical spreadsheet, in
> > the same network location will open and execute without error on my PC.
> >
> > >> All PCs are running MS Office 2000 9.0.6926 SP-3 <<
> >
> > Please provide suggestions as to where to look to solve this problem.
>
> --
>
> Dave Peterson
>