Word 2007 Programming?

[JeffP->]

I've been reading about some of the programming and new document types with
Office 2007.

Currently we use an addin that enables all of our templates to merge data
via DDE from the primary CRM application.

I may need to replace Office 2000 with Office 2007 and port this VBA addin
to the new Office 2007.

I'd like to know if the .Net version is capable of instantiating DDE when a
template is launched?

Can I simply port the current addin dot to Office 2007 dot by copy paste
into a new Office 2007 template? I think that the .Net version works with
the new document types and may contain the code in an assembly centrally
located; I'm hoping that the older .dot files are compatible with Office
2000 as far as the VBA is concerned are still capable of being installed in
the startup folder, any info would be helpful.

TIA

 

[Jonathan West]

I've been reading about some of the programming and new document types
with
Office 2007.

Currently we use an addin that enables all of our templates to merge data
via DDE from the primary CRM application.

I may need to replace Office 2000 with Office 2007 and port this VBA addin
to the new Office 2007.

I'd like to know if the .Net version is capable of instantiating DDE when
a
template is launched?

You might not need .Net. Office 2007 still has VBA.

Can I simply port the current addin dot to Office 2007 dot by copy paste
into a new Office 2007 template?

If you are using VBA in a dotm file, then you can simply open the file in
Office 2007 and then re-save in the new file format. Back up the file first!

You will then need to test the code in Word 2007 and see what has broken.
Work on the assumption that something almost certainly has broken, for
instance because the new file formats have different filename extensions. Do
you want the Word 2007 version to support both old and new filetypes?

One point of concern is this use of DDE. Although (as far as I know) the old
DDE commands inherited by VBA from WordBasic are still present, they aren't
documented any more, and this will probably have to be a particular focus of
your testing, to see if they still work as before.

I think that the .Net version works with
the new document types and may contain the code in an assembly centrally
located;

Unless you have a particular need to change to a VB.NET/VSTO solution, I
would recommend that you stay with VBA, as moving away from VBA will
certainly involve pretty much a complete rewrite of your application. VB.NET
is just sufficiently different from VBA that it looks like it is the same
langauge while doing key things differently. (As a trivial example, an
Integer is now 32 bits, and a Long is 64 bits. Even something as simple as
this can have unexpected effects.) In addition, the way in which the add-in
is connected to Word and initialised is quite different, and will require
new code. It is probably not worth the effort of rewriting unless you have
some major new feature that you want to add which either relies on or is
much easier to implement with the assistance of the .net framework.

I'm hoping that the older .dot files are compatible with Office
2000 as far as the VBA is concerned are still capable of being installed
in
the startup folder, any info would be helpful.

Both .dot and .dotm files placed in the Word 2007 startup folder will be
loaded automatically as add-ins.

 

[JeffP->]

Jonathan,

Thanks for your post. I expect that a numeric pointer or similar may break
if not explicitly created, called and passed to another component and that
most likely something will be broken, I'll need to look hard and test well to
avoid production errors.

Just as an aside, most of our printing is done by automated process with no
human intervention. We merge any combination of 600 documents (less as I
program similar docs to morph) which print a response to our clients requests
and moving them through the sales and billing processes.

Of the 20 or so pages of code that reside w/in the main dde addin, I only
need about 3 or 4. There are many functions that are never used as well as a
huge language conversion etc. The addin is part of a retail product, however
over the years I've had to tweak it a bit to work as we expect. However I
feel as if I'm "...pulling a tractor with an elephant because I don't have a
fresh spark-plug..., LBJ. and I'd really like to lighten the load and get
down to our essential processes and supporting functions.

JeffP...

 

[Karl E. Peterson]

I'd like to know if the .Net version is capable of instantiating DDE when a

template is launched?

My understanding is, .NET languages (vFred, at least) don't support DDE -- it's
considered "obsolete" technology, ergo useless.

 

[JeffP->]

That runs counter to what I've heard, not seen; namely that although your
statement is somewhat true, the instance of DDE is still supported, which is
what I'm praying for.

If DDE is not supported how is a template started which sees the current
record's data? I have created some templates that use both, the legacy DDE
to grab the current records unique ID, then do other processes that yield
data external to our primary application. But this still begins with DDE.

Note: The issue is to continue to use DDE is to facilitate an out-of-the-box
application which broadcasts DDE. To whit, we print enough documents each day
to be in the top 10 in sales nationwide in our field, the only others in that
group are large scale operations or banks. We're just an agent in an office
doing double the business the office does printing with DDE, it works well.
We process some 50K current client records, print any combination of 600
documents and anywhere from 1000 to 5000 print jobs each business day.

 

[Karl E. Peterson]

I'd like to know if the .Net version is capable of instantiating DDE when a

That runs counter to what I've heard, not seen; namely that although your
statement is somewhat true, the instance of DDE is still supported, which is
what I'm praying for.

If DDE is not supported how ...

Don't take me as the final word on any of this. I'm not a Convert.NET myself! Not
by any means. I can only go by the propodogma MSFT (and its minions) publishes.
Some of which includes:

<q src=http://migrationguide.artinsoft.com/Migration-Guide-Faq-Chapter-9.aspx#faq14>
What advantages do I get from using COM in Visual Basic .NET instead of DDE?
At one time, Dynamic Data Exchange (DDE) was one of the few ways you could pass
data between applications without using a shared file. However, DDE has since been
replaced by COM. With COM, you can share data and invoke methods between
applications in a more efficient and scalable manner. Because most Windows-based
applications that expose public data and methods do so by way of COM, DDE is not the
primary way that you retrieve public data and invoke public methods in a
Windows-based application. As a consequence, COM can be used as a means of
communicating with most Windows-based applications.
</q>


<q src=http://www.codeproject.com/vb/net/Migration.asp>
The following features in VB projects are not supported in the VB.NET environment:

* OLE Container Control
* Dynamic Data Exchange (DDE)
...
</q>

<q src=http://www.aivosto.com/project/help/enterprise-netcheck-rules.html>
DDE unsupported by VB.NET. DDE is not available in VB.NET. You will have to use
other kind of inter-process communication. Work required after upgrade.
</q>

<q src=http://www.codeguru.com/Csharp/.NET/net_asp/miscellaneous/article.php/c6975/>
Windows Forms has no support for Dynamic Data Exchange (DDE).
</q>

And, perhaps as clearly as it can be said, ...

<q src=http://msdn2.microsoft.com/en-us/library/14w905kc(VS.80).aspx>
Visual Basic 2005 has no support for Dynamic Data Exchange (DDE).
</q>

Sorry...