Office97 to 2003 upgrade (Office2003)

Topic

New Reply

Currently my company uses Office97, running on NT. We are upgrading our desktops to XP Pro at the end of this year, at the same time, switching to Office2003.

We have a large number of applications that are Office, VBA based, and I have been asked to produce a position paper on the likely problems that we will face in running these applications on the new platform.

Can anyone help point to possible problems that may blindside us. I know it’s a large jump from 97 to 2003 but… that’s the way our company works. Thanks in advance

Reply | Quote

Replies

The situation differs from application to application. Although each Office application has issues, the most radical changes are in Access and Outlook.
– Does your company use Access?
– Does your company have applications that automate Outlook (for example, use VBA to process or send e-mails)?

Reply | Quote

Thanks for the reply.

Our Company uses Lotus Notes and we will be loading Access 97 onto our XP platform. So it looks as if there’s not too much of a problem .

Reply | Quote

You may still run into problems with Word and Excel. I don’t use Office 2003 myself (I have Office XP/2002), but I gather that macro security is much more severe in Office 2003. I know that fellow Lounger jujuraf has had a lot of problems with Excel macros in Office 2002.

But Word documents and Excel workbooks created in the 97 version can be opened in the 2003 version without converting. If some people start using Office 2003, while others are still using Office 97, the use of new features should be avoided.

Reply | Quote

You may still run into problems with Word and Excel. I don’t use Office 2003 myself (I have Office XP/2002), but I gather that macro security is much more severe in Office 2003. I know that fellow Lounger jujuraf has had a lot of problems with Excel macros in Office 2002.

But Word documents and Excel workbooks created in the 97 version can be opened in the 2003 version without converting. If some people start using Office 2003, while others are still using Office 97, the use of new features should be avoided.

Reply | Quote

Thanks for the reply.

Our Company uses Lotus Notes and we will be loading Access 97 onto our XP platform. So it looks as if there’s not too much of a problem .

Reply | Quote

The situation differs from application to application. Although each Office application has issues, the most radical changes are in Access and Outlook.
– Does your company use Access?
– Does your company have applications that automate Outlook (for example, use VBA to process or send e-mails)?

Reply | Quote

HI there, it’s me jujuraf – always the wet blanket warning folks about the hidden bombs of moving VBA-enabled projects from older to newer versions of Word/Excel. I only work in Excel 97/2000/2002 so far and have stumbled on tons of problems just using the bare bones basic VBA, no extra references, and no new features. None of these problems are documented, it’s purely a surprise attack when you stumble on them. In my case, the apps I write are for internal and external users so I have to worry about many versions of Excel. In your case if your users are internal and all moving from 97 to 2003 then it’s somewhat easier (two versions to test not four). Will you have problems? Hard to say w/o knowing how complex your VBA apps are. Tread lightly and test, test, test.

Most problematic? Dynamically creating/updating charts in VBA, writing to a non-active worksheet, hiding/showing rows/cols, sheet protection (e.g., in one case code in Excel 2002 to protect a workbook will actually unprotect it – this works fine in older versions), and blah and blah…

Deb

Reply | Quote

We are upgrading from Office 97 to Office 2003 too. We’ve developed a lot of “intelligent” templates in Word, which are dynamically built based on user choices, in dropdown formfields or with a commandbarbutton. That requires quite some VBA code, put in a single code-template that sits in the Word Startup directory. None of the other templates contains any code at all.

Loading the code-template in Word 2003 caused only a couple of problems and some minor inconveniences.
Word 97 VBA only has 1 event on application level that you can use to control opening documents by users: DocumentChange. This event fires whenever user creates or opens a document or changes to another document (menu Window). Loaded in Word 2003 the event-handling Sub wdApp_DocumentChange is run several (up to 32!) times before it triggered the rest of the code. And when you try to create a new document from a template, the event-handler goes into an endless loop… I haven’t found a reason, nor a solution / workaround for this. Apparently this event doesn’t work exactly the same as in Word 97. So I had to convert to 2 events which are not in Word 97 VBA: NewDocument and DocumentOpen. And that worked fine. But it means that I have to maintain 2 versions of my code template until our last user is upgraded to Office 2003.

The second problem is hijacking menu entries and commandbar buttons the way it was done. If you do that properly (using the same name as the built-in Word command for your Sub) then you don’t have a problem. But unfortunately in the early days we didn’t know that and used dutch names for our own routines. And replaced the standard menu entries and commandbar buttons with ones that pointed to the Sub’s we created. Because the menubar in Word 2003 is organised differently, some entries showed up twice or even three times. So we decided to rename our Sub’s to match the built-in names and restore the original menubar and commandbar Standard.

Then there is this is strange behaviour of AutoText fragments that are saved with the template and placed in a document by VBA code. These fragments can contain both plain text and formfields. On some (!) PC’s the plain text was in Arial, as intended, but for the formfields the (ugly!) font MS Mincho was used. We can’t figure out why this happens. Eventually we decided to delete this font (present in both Windows XP and Office 2003 CAB files) from all PC’s. After that, Word used Arial Unicode MS for the formfields. But because there’s no visible difference with standard Arial, we can live with that.

The first mouseclick on a control in a dialog panel didn’t always do what you expect. It looks like the panel you just put on the screen (.Show) didn’t set the focus on the panel and that the first mouseclick just does set the focus on the panel. So you have to click again to fire the code behind the clicked control. We observed this both in Word XP (almost every time) and in Word 2003 (about fifty-fifty) when Windos XP Pro (dutch) and Office XP/2003 Enterprise Edition (dutch)were installed out-of-the-box. After a complete re-install of the PC’s, with all the latest patches for both Windows and Office applied, this problem seems to be solved. We never found out why it occurred in the first place.

Pagenumbering (page x of y) still is not perfect. At first we removed all code for updating the y-value because we thought that this was – finally – solved in Word XP / 2003. But in some cases we again encounterd document with the 1 of 1, 2 of 1, 3 of 1, etc. numbering. So we put the removed code back in…

The last issue I’d like to mention is that creating and opening documents takes more time in Word 2003 than it did in Word 97, up to 4x slower. These observations were made on a 2.53 Mhz Pentium 4 with 256 Mb memory and only Windows and Office installed.

Regards,
JanB

Reply | Quote

Thanks to all who replied. Aren’t forums great

Reply | Quote

Thanks to all who replied. Aren’t forums great

Reply | Quote

We are upgrading from Office 97 to Office 2003 too. We’ve developed a lot of “intelligent” templates in Word, which are dynamically built based on user choices, in dropdown formfields or with a commandbarbutton. That requires quite some VBA code, put in a single code-template that sits in the Word Startup directory. None of the other templates contains any code at all.

Loading the code-template in Word 2003 caused only a couple of problems and some minor inconveniences.
Word 97 VBA only has 1 event on application level that you can use to control opening documents by users: DocumentChange. This event fires whenever user creates or opens a document or changes to another document (menu Window). Loaded in Word 2003 the event-handling Sub wdApp_DocumentChange is run several (up to 32!) times before it triggered the rest of the code. And when you try to create a new document from a template, the event-handler goes into an endless loop… I haven’t found a reason, nor a solution / workaround for this. Apparently this event doesn’t work exactly the same as in Word 97. So I had to convert to 2 events which are not in Word 97 VBA: NewDocument and DocumentOpen. And that worked fine. But it means that I have to maintain 2 versions of my code template until our last user is upgraded to Office 2003.

The second problem is hijacking menu entries and commandbar buttons the way it was done. If you do that properly (using the same name as the built-in Word command for your Sub) then you don’t have a problem. But unfortunately in the early days we didn’t know that and used dutch names for our own routines. And replaced the standard menu entries and commandbar buttons with ones that pointed to the Sub’s we created. Because the menubar in Word 2003 is organised differently, some entries showed up twice or even three times. So we decided to rename our Sub’s to match the built-in names and restore the original menubar and commandbar Standard.

Then there is this is strange behaviour of AutoText fragments that are saved with the template and placed in a document by VBA code. These fragments can contain both plain text and formfields. On some (!) PC’s the plain text was in Arial, as intended, but for the formfields the (ugly!) font MS Mincho was used. We can’t figure out why this happens. Eventually we decided to delete this font (present in both Windows XP and Office 2003 CAB files) from all PC’s. After that, Word used Arial Unicode MS for the formfields. But because there’s no visible difference with standard Arial, we can live with that.

The first mouseclick on a control in a dialog panel didn’t always do what you expect. It looks like the panel you just put on the screen (.Show) didn’t set the focus on the panel and that the first mouseclick just does set the focus on the panel. So you have to click again to fire the code behind the clicked control. We observed this both in Word XP (almost every time) and in Word 2003 (about fifty-fifty) when Windos XP Pro (dutch) and Office XP/2003 Enterprise Edition (dutch)were installed out-of-the-box. After a complete re-install of the PC’s, with all the latest patches for both Windows and Office applied, this problem seems to be solved. We never found out why it occurred in the first place.

Pagenumbering (page x of y) still is not perfect. At first we removed all code for updating the y-value because we thought that this was – finally – solved in Word XP / 2003. But in some cases we again encounterd document with the 1 of 1, 2 of 1, 3 of 1, etc. numbering. So we put the removed code back in…

The last issue I’d like to mention is that creating and opening documents takes more time in Word 2003 than it did in Word 97, up to 4x slower. These observations were made on a 2.53 Mhz Pentium 4 with 256 Mb memory and only Windows and Office installed.

Regards,
JanB

Reply | Quote