MSWord9.OLB comaptibility with MS Word 2003

[mef526]

I have an application that creates a report using a Word template by
scanning the template's bookmarks and placing data at their location using
a DLL written with MFC . Some of the data is text, some graphics. For
graphics, I scale the PNG files to fit inside of a table cell. The program
works well on Word 2000.

I installed the program on a PC with Word 2003 and the reports look
terrible- the graphics don't go into the cells properly. Doesn't the
MSWORD9.OLB library work on Word 2003 machines the same way as on Word 2000
machines? (Obviously not!)

How much work will it be to fix this? Is there a KB bug on MSWORD9
compatibility with Word 2003? (there should be!)

I expect that compatibility means that the code I wrote will not break when
newer version of MS Word are released.

 

[Cindy M -WordMVP-]

Hi =?Utf-8?B?bWVmNTI2?=,

Without knowing how your code works with the graphics (are you using Shapes or
InlineShapes, for example), and more details about how it's not working in
Word 2003, it's difficult to say exactly what the problem might be. Certainly,
how TABLES behave has changed somewhat in each version, going from 97 through
2003. My best guess is that it's related to that, but without more
information...

I have an application that creates a report using a Word template by
scanning the template's bookmarks and placing data at their location using
a DLL written with MFC . Some of the data is text, some graphics. For
graphics, I scale the PNG files to fit inside of a table cell. The program
works well on Word 2000.

I installed the program on a PC with Word 2003 and the reports look
terrible- the graphics don't go into the cells properly. Doesn't the
MSWORD9.OLB library work on Word 2003 machines the same way as on Word 2000
machines? (Obviously not!)

How much work will it be to fix this? Is there a KB bug on MSWORD9
compatibility with Word 2003? (there should be!)

I expect that compatibility means that the code I wrote will not break when
newer version of MS Word are released.

Cindy Meister
INTER-Solutions, Switzerland
http://homepage.swissonline.ch/cindymeister (last update Jun 8 2004)
http://www.word.mvps.org

This reply is posted in the Newsgroup; please post any follow question or
reply in the newsgroup and not by e-mail

 

[mef526]

Thank you for your reply.
Well, the issue is more that there is a bug in MS Word, since the
compatibility is broken. Makes me want to abandon using MS Word if every new
release is going to require me to "Fix" my code. I think that it is really an
issue for MS to fix the compatibility issues.

That being said, what is the procedure to have a MS bug reported and a fix
in the KB created?

 

[Cindy M -WordMVP-]

Hi =?Utf-8?B?bWVmNTI2?=,

That being said, what is the procedure to have a MS bug reported and a fix
in the KB created?

You have to telephone support and open an issue. That will cost you, and you'd
only get the money back if MS decides it's a valid bug. And it's not certain
you'd get a fix.

If your company has a license that includes support, be sure to go through that.
The more costly license deals do include creating hot-fixes.

Well, the issue is more that there is a bug in MS Word, since the
compatibility is broken. Makes me want to abandon using MS Word if every new
release is going to require me to "Fix" my code. I think that it is really an
issue for MS to fix the compatibility issues.

FWIW, I've had discussions with MS about backwards/forwards compatibility.
Sometimes, it comes down to a question of introducing new functionality, that
will be useful to users but could break VBA code across versions. Or not
introducing the new functionality. For example: earlier versions of Word don't
support text wrap around "floating" graphical objects (shapes). More recent
versions do. This could, possibly, queer VBA code. But if they figure they're
going to sell more software with increased functionality, they'll go ahead and
do it. New functionality is more compelling in the marketplace than making sure
existing VBA code will continue to work in newer versions. Sure, it's
frustrating to developers (and companies who've invested in automated
solutions). But there's (almost) always a reason for the change.

Cindy Meister
INTER-Solutions, Switzerland
http://homepage.swissonline.ch/cindymeister (last update Jun 8 2004)
http://www.word.mvps.org

This reply is posted in the Newsgroup; please post any follow question or reply
in the newsgroup and not by e-mail

 

[mef526]

Being a developer myself, and seeing how MS has exteneded the windows API
using such gems as Sleep() and SleepEx(), I can't see how they need to break
code to add functionality. In all the COM books I read MS clearly states
that in COM the interface is a contract. They are so cavalier about breaking
that contract I think that Steve Balmer was tripping :
http://www.ntk.net/media/developers.mpg

This is the kind of thing that makes me suggest to clients that they should
NEVER pay for MS Office development.

 

[Cindy M -WordMVP-]

Hi Mef526,

can't see how they need to break
code to add functionality. In all the COM books I read MS clearly states
that in COM the interface is a contract.

This is somewhat different. We're not talking about breaking COM, here
(although there are very crass instances where that has happened), I don't
think. (Can't be sure of course, since you haven't shared any details with
us.) We're talking about changing how the UI works, in that things are
added to the application. There is no "contract" about changing how the UI
works from version to version. If the UI changes, the object model changes.
If you don't want it to change, then MS can give up on improving the
applications for the end-user. In end effect, this would mean discontinuing
the current application and introducting a new one in its place. Then you
(and the dev team) could start from scratch, all over again.

This is basically what's happened with OneNote and InfoPath. New
applications with none of the old baggage there would have been if one had
tried to integrate them into an existing Office app. Total paradigm shift,
as far as what's going on at the programming level. You have to know Java,
.NET and XML to even get started.

Cindy Meister
INTER-Solutions, Switzerland
http://homepage.swissonline.ch/cindymeister (last update Jun 8 2004)
http://www.word.mvps.org

This reply is posted in the Newsgroup; please post any follow question or
reply in the newsgroup and not by e-mail

 

[mef526]

Well COM did break because my code doesn't work. The COM interface didn't
change, but they re-defined what the interface DOES. In any case it caused
the code I wrote to no longer work, and after all, isn't that the point of
stabilizing the interface.

Look at it this way- I'll sell you a library with a function: F(int n) that
returns the nth Fibonacci number. Now my new version (with improved UI and
added features) now has F(int n) returning the factorial of n. Why didn't I
just create F1(int n)? Well, it must have been a bug.

I guess that I am beating this thread to death. I guess that what I want is
to have MS fix my code by issuing a patch for MS Word. Or even just a KB
article that admits the mistake and provides a work around. Short of that I
can't see how I can ever recommend MS products ever again. The good thing
about writing in C/C++ is that I am not at the mercy of MS whims. I can
always port my code to another development system. Think of all the people
who are struggling with Visual Fred (also called Visual Basic.NET). Just to
find "improvements" between .Net 1.037 and 1.1, albeit minimal, that break
their code.

 

[Cindy M -WordMVP-]

Hi Mef526,

I guess that what I want is
to have MS fix my code by issuing a patch for MS Word. Or even just a KB
article that admits the mistake and provides a work around.

If you don't figure out WHY (what was changed), no one can make a patch or
post a KB article. Be happy to help you track it down...

But if all you can say is "Make it work like Word 2000", then the answer
will be: "install Word 2000".

Cindy Meister
INTER-Solutions, Switzerland
http://homepage.swissonline.ch/cindymeister (last update Jun 8 2004)
http://www.word.mvps.org

This reply is posted in the Newsgroup; please post any follow question or
reply in the newsgroup and not by e-mail

 

[mef526]

Thanks for perservering on this issue.
Here is an actual code snippet. The automation is in C++ and uses a concept
that I developed called "data tags", that is, every data element in the
analysis has a name, a "data tag". In the MS Word code I search the
bookmarks and when I find a data tag I place the data associated with it.
Data tags are variants and have a type assigned to each one. This variant is
my own design (named MM_eVppType_t) and is an enum. The datatag's name is a
field in a struct like this:

typedef struct MM_zMapPtr_z {
ViAddr pAddr; ///< The variable used (a void pointer)
ViPChar pcName; ///< The name given (data tag)
MM_eVppType_t eVppType; ///< The type of variable
int nArySize; ///< Number of array elements in pAddr (if
array)
} MM_zMapPtr_t;


When I find a bookmark in the template that is a data tag it is placed based
on the type. The type eVppType_FileGraphic is a path to a PNG file. If the
data tag is a "eVppType_FileGraphic" and is in a cell (typical), I place the
bitmap in the cell and scale it (using fBitMapScale) so that it fully fits
into the cell.

In Word 2000 this works fine, in Word 2003 the graphics are all at the top
and not in cells at all.

Here is the relevant code:

if (eVppType & eVppType_FLAG_GRAPHICFILE) {
// The bookmark is a graphic
pcMyVal = (char*)pzMap->pAddr;
if ((NULL == pcMyVal) || (0 == *pcMyVal)) {
continue; // No File spec'd
} else if (_access(pcMyVal, 0) != 0) {
cstrMsgGraphic = cstrMsgGraphic + " \"" + pcMyVal + "\"";
nErrGraphic++;
continue; // File not found
}
CWordRange oRange = oBkmrk.get_Range();
// expression.AddPicture(FileName, LinkToFile, SaveWithDocument, Range)
oInlineShape = oInlineShapeColl.AddPicture(pcMyVal, vFalse, vTrue,
vOpt);
MM_DOEVENTS;

/// Send image to back in case we need to put text on top of it
CWordShape oShape = oInlineShape.ConvertToShape();
oShape.ZOrder(1); // Send to back

if (fBitMapScale != 0.0) {
// Scale the image to fit in the Cell and center it
CWordWrapFormat oWrapFormat = oShape.get_WrapFormat();
CWordCellsColl oCellsColl = oRange.get_Cells();
int nCellCnt = oCellsColl.get_Count();
if (nCellCnt == 1) {
oShape.put_LockAspectRatio(0);
CWordCell oCell = oCellsColl.Item(1);
float fCellWidth = oCell.get_Width();
oShape.put_Width(fCellWidth * min(1.0F, fBitMapScale));
float fShapeWidth = oShape.get_Width();
oShape.put_Left((fCellWidth - fShapeWidth) / 2.0F);
float fShapeHeight = oShape.get_Height();
if (oCell.get_HeightRule() == wdRowHeightAuto) {
fBitMapScale = min(fBitMapScale, 1.0F);
oShape.put_Height(fShapeHeight * fBitMapScale);
oShape.put_Top(((1.0F - fBitMapScale) * fShapeHeight) / 2.0F );
} else {
float fCellHeight = oCell.get_Height();
oShape.put_Height(fCellHeight * fBitMapScale);
oShape.put_Top((fCellHeight - fShapeHeight) / 2.0F);
}
}
}
pcMyVal = NULL;

MM_DOEVENTS;
} // if (eVppType & eVppType_FLAG_GRAPHICFILE)

 

[Cindy M -WordMVP-]

Hi Mef526,

and is in a cell (typical), I place the
bitmap in the cell and scale it (using fBitMapScale) so that it fully fits
into the cell.

In Word 2000 this works fine, in Word 2003 the graphics are all at the top
and not in cells at all.

Here is the relevant code:

OK, I think I follow the relevant portions of the code. You're missing
shp.RelativeHorizontalPosition
shp.RelativeVeritcalPosition

that would tell Word to position the shapes relative to the anchoring range
(you range variable for the bookmark range), instead of relative to the page.
The enum is basically the same as you can set in Format
[Object]/Layout/Advanced/Picture position. For horizontal you'd probably want
column within a table (and that's what happens automatically in the UI when I
put a graphic behind a cell).

The relative vertical position should probably be to "paragraph".

FWIW, this should also work in Word 2000 exactly the same; the properties are
in the object model. I just completed a fairly complicated project with
graphics (replacing existing ones) spanning Word 2000 through 2003; I have to
use these properties in the code; and it works the same across the three
versions.

In this case, I'd agree with you that MS did break COM. Converting from
InlineShapes to Shapes really ought to default to the same property settings.
The one thing that occurs to me that could be behind the behavioral
difference is that, starting in Word 2002, the user can for the first time in
history set the default "text wrap" for inserting Shapes. It may be that the
conversion varies, depending on this setting.

Cindy Meister
INTER-Solutions, Switzerland
http://homepage.swissonline.ch/cindymeister (last update Jun 8 2004)
http://www.word.mvps.org

This reply is posted in the Newsgroup; please post any follow question or
reply in the newsgroup and not by e-mail