SourceFullName error PowerPoint Office 2007 sp 1

  • Thread starter Thread starter tiamat
  • Start date Start date
T

tiamat

Hi,

We are trying to update the value of SourceFullName for a PowerPoint 2007
presentation link to an OLE, paste special, Excel chart.

The problem we have is on some machines we get the error below when the
value given to 'SourceFullName' does not point to a valid file but on other
machines it accepts the value.

Method 'SourceFullName' of object 'LinkFormat' failed.

With error number -214467259


My question hence, is there a way where we can turn off the check when
setting 'SourceFullName'? Or is there a windows update or known setting that
modifies the behaviour.


At the moment we know on some machines this check is happening but on others
it is not. We have tested under XP sp 3 and Vista sp 1 and we are running
Office 2007 sp 1. We have both XP and Vista machines showing the duality, it
would be nice to find out what is setting this behaviour, what we do observe
is that appears to be at a machine level.
 
Don't be annoyed at the probably obvious question, but I want to ask it so
we
can dismiss it. This problem occurs on different computers but with the same
PPT file? Or if different files, you're certain the Excel content is linked
but not embedded in all cases?

Do the links point to files on a network drive? There are some real problems
in that area in 2007.

-----------------------------------------
Steve Rindsberg, PPT MVP
PPT FAQ: www.pptfaq.com
PPTools: www.pptools.com
================================================
Click to expand...

Hi Steve,

No problem on the question. Yes, this occurs with the same test pptx and
xlsx file. Secondly, multiple file locations are part of our test plan, i.e.
where presentation and xlsx files reside locally, on a network and in the
same directory.

I think we have now answered our problem though - we have now noticed that
the version build number is different.

I.e. Those machines that do not perform the check show in the About box:
Microsoft Office PowerPoint 2007 (12.0.6211.1000) SP1 MSO (12.0.6213.1000)

The machines that are performing the check :
Microsoft Office PowerPoint 2007 (12.0.6303.5000) SP1 MSO (12.0.6213.1000)

So for now this resolves my issue. For those that are interested what we are
doing is to deliberately create an incorrect link.

This is so we can provide a workaround for the current outstanding issue
detailed here.

http://www.microsoft.com/office/com...e-powerpoint&lang=en&cr=US&sloc=en-us&m=1&p=1

By writing an incorrect link and providing a mechanism to retrieve the
original format - AddIn buttons to vba code, we are effectively able to stop
the lengthy operation of updating links that is being done.

Initially we were just writing a marker at the start of the link. However,
the forementioned in processing links meant this was not reliable. Our
workaround which appears to work so far for both build versions is to add an
extra fake folder into the link path, please see below.

C:\Files\Excel.xlsx

becomes

C:\DISABLE\Files\Excel.xlsx

An interesting observation, is that the checking mechanism for
(12.0.6303.5000) is still happening but has a different level of parsing than
the earlier version. Which is why the earlier attempt of :

DISABLE C:\Files\Excel.xlsx

worked for one version and not the other.

I include this information as it maybe useful for others. At the moment we
have files that are taking 20minutes on some peoples machines just to load
and admittedly our approach is a bit of a hack, but until the MS issue is
resolved it is very effective for the users.
 
Well, I thought I would follow up with our final conclusions, mainly, because
this was so painful I wouldnt want anyone else to waste their time.

Basically, in a nutshell the way to 'reliably' modify a link and
reconstitute at a later stage is to parse the link text and alter the
FILENAME. We did this by inserting a fixed marker string 'disabled' into the
link before the file extension. This marker was then used when reconstituting.

The only thing of note was that links which had relative paths required an
extra degree of manipulation upon reconstitution. To reliably recreate the
link we retrieved the location of the current powerpoint presentation using
FullName parsed this and appended the path information to the relative link
path. This then upon reconstitution worked fine upon saving and then
reopening the powerpoint presentation.

Do not attempt to modify the path. We observed very erroneous behaviour with
some machines behaving and others failing (Office had the same version
number). We tested under XP, Vista with English, German and French.

So ends thankfully this saga...
 
Back
Top