fields queries and utter disaster

[google]

I suspect that regrettably, in this case the Excel team got to it, the Word one did not

ODBC is hard to do on the Mac

It's not THAT hard! ;-)

No more difficult than on Windows, actually. I'm sure the Mac Word
team has more than enough talent to implement ODBC if it makes it on to
the feature list.

Jonathan Monroe
Actual Technologies - ODBC for OS X
http://www.actualtechnologies.com

 

[John McGhie [MVP - Word and Word Macintosh]]

'Course it does

"Expertise" is not the resource that's scarce here...

Just the same as in your company, the issue is the length of the piece of
string. And as with any software company, the ropes we're talking about are
the ones attached to Product Marketing's budget and schedule

Cheers

It's not THAT hard! ;-)

No more difficult than on Windows, actually. I'm sure the Mac Word
team has more than enough talent to implement ODBC if it makes it on to
the feature list.

Jonathan Monroe
Actual Technologies - ODBC for OS X
http://www.actualtechnologies.com

--

Please reply to the newsgroup to maintain the thread. Please do not email
me unless I ask you to.

John McGhie <[email protected]>
Microsoft MVP, Word and Word for Macintosh. Consultant Technical Writer
Sydney, Australia +61 (0) 4 1209 1410

 

[Jim Gordon]

Hi John & Jonathan,

Every once in a while I wander into the ODBC and other database oriented
newsgroups. They are very active places. Easily 10X the traffic in the
Mac groups. I have no doubt that there is a huge untapped demand for
data connectivity within Mac Office and that this demand is the only
major remaining hold-back for future large scale switching to Mac Office
by Windows users.

Until ActualTechnologies (3 cheers to Jonathan) came along there was not
a low-cost easy to use way to implement some key database features in
Mac Office. I always felt that OpenLink's stuff was too restrictive and
expensive requiring a complicated 2-tier network oriented setup.

At any rate, as I mentioned before it's a chicken or egg situation. ODBC
drivers are not part of MacOS and Mac BU was disinclined to provide them
as part of Office. Mac BU had to wait till 3rd party drivers hit the
market. Thankfully, now they have. Jonathan's company has made a dual
binary version, which can be taken advantage of by Mac Office, even for
Microsoft Access.

The next Mac version of office is going to be a 2-way port. One port is
existing functionality into the new XML file format. The other port is
to a dual binary. When making a port the main goal is to get everything
you already have working. You try not to rock the boat by introducing
new functionality. So I am not holding my breath for new ODBC support in
the upcoming release of Office.

But the next step after making the port IS to introduce new
functionality. Office v.X was a port. Office 2004 introduced new
functionality on a grand scale. I am hoping that right after Office 2007
equivalent for Mac Office hits the streets that database functionality
will become a high priority for Mac BU. If there ever was a window of
opportunity to expand the user base for Mac Office it would be at that
time. The key areas of growth that I see for Mac Office are with regard
to databases. A restoration of full programmatic support of ODBC is a
must. No one has ever done much creatively with a SQL-GUI. If you look
at Oracle, MS Access, FoxPro, FileMaker - they are all pretty much the
same. A 3-D drag and drop interface would be a real nice kick for Mac MS
Query. Adding the ability to read and create MS Access forms and reports
to MS-Query for Mac would make a port of MS Access unnecessary. MacBU
could take the same approach for MS Query as they did with Entourage
with regard to Outlook: it doesn't have to be the same. It just has to
be able to do the same work and work with the files. Indeed - this is a
golden opportunity to show off what a Mac interface can do. And along
the way MacBU could re-work the MS Word ODBC connectivity and get that
working again.

OK - now I'm off my soapbox. Back to work and play.

-Jim Gordon
Mac MVP

 

[John McGhie [MVP - Word and Word Macintosh]]

Hi Jim:

Thanks for an eloquent and persuasive argument, which I thoroughly applaud.

However, I would be a little tougher on them that you have been. I see no
reason why this next version of Mac Office "needs" to be a two-way port. I
would have thought this was a golden opportunity to make it a "one"-way
port: take the whole of Office 2007 and bring it to the Mac.

Yes, I am keenly aware that in software terms this makes it a much larger
task. Something like 80 per cent of the computer's time in Microsoft Office
on the PC is spent running Windows code. Because the same vendor had the
opportunity to build the two to fit together, Office makes heavy use of
Windows functions. They'd be silly if it didn't.

So the job is a lot bigger than cutting the user interface off the thing and
cross-compiling it.

But it's not impossible!

And I am afraid I don't share Jim's rosy interpretation of how little we
have to do to trigger that wholesale "switch".

Currently, the first question any prospective switcher asks is "If I go
there, what *won't* it do? Currently, that's a huge list. Database
connectivity is only a small part of it.

This thing can't even inter-operate successfully with ITSELF!! You can't
take a file from Mac Office and send it to your PC workmate and guarantee
s/he will see the same result.

Yes, it will get close. Yes, the file formats are the same. Yes, there are
no worries about being able to open or edit the file on either platform.
But 100 per cent functionally compatible? Nope.

Yes, it is true that 80 per cent of users use only ten per cent of the
application's capabilities. And that Mac Office applications have more like
90 per cent of the functionality their PC Office equivalents.

The problem is that 100 per cent of Office users use "some" of the functions
"other people rarely use". Just that each of us use different ones

If I were creating a major corporation from scratch, I could easily specify
"Macintosh Only" on the desktops, and conduct business very successfully.
We have a large phone company in Australia that did just that, with great
success.

The rot sets in when you try to create a "mixed" environment. Bring PCs
into a Mac-only shop, or Macs into a PC-only shop, and you get more than
twice the problems. The first thing a corporation wants to do is to make
its user's environment "purpose designed" for the work they're to do.

And that's where we're run into problems in a mixed environment. You can
(and should...) radically customise Mac Office using AppleScript. Or PC
Office, using VBA. Regrettably, when you try to move those customisations
over to the other platform, you get to do all the work again. Since the
amount of work involved in a full-scale customisation is huge, you wouldn't
want to have to do it all twice.

That's one place we could make a huge leap with Office Next on the Mac, if
we get it right. Customisation in Office 2007 relies a lot less on writing
VBA and a lot more on tweaking configuration files using XML. Those tweaks
should simply open up and work in Mac Office.

If they do, that's a very important part of the Switcher story written. We
need to make a big effort during the beta for the next version of Mac Office
to ensure that any tweaks done to the PC Office XML work correctly on the
Mac.

As people get into this, you will hear a LOT of noise from the tree-huggers
and vested interests about the new Office user interface.

OK, let me agree with them right off the bat: The new UI is nothing like the
old one That's intentional. In MY experience, the new UI works a hell
of a lot better than the old one. Provided I am willing to accept that the
old keystrokes and the old approach to making documents have gone forever.

The new UI in Microsoft Office enables us to make better documents faster.
But it does not work the same way as the old interface. And the Mac version
of it will NOT look exactly the same as the Windows Vista version. It
can't. This is a *Mac*, for heaven's sale!

Just thought I would prepare you for that

Cheers

Hi John & Jonathan,

Every once in a while I wander into the ODBC and other database oriented
newsgroups. They are very active places. Easily 10X the traffic in the
Mac groups. I have no doubt that there is a huge untapped demand for
data connectivity within Mac Office and that this demand is the only
major remaining hold-back for future large scale switching to Mac Office
by Windows users.

Until ActualTechnologies (3 cheers to Jonathan) came along there was not
a low-cost easy to use way to implement some key database features in
Mac Office. I always felt that OpenLink's stuff was too restrictive and
expensive requiring a complicated 2-tier network oriented setup.

At any rate, as I mentioned before it's a chicken or egg situation. ODBC
drivers are not part of MacOS and Mac BU was disinclined to provide them
as part of Office. Mac BU had to wait till 3rd party drivers hit the
market. Thankfully, now they have. Jonathan's company has made a dual
binary version, which can be taken advantage of by Mac Office, even for
Microsoft Access.

The next Mac version of office is going to be a 2-way port. One port is
existing functionality into the new XML file format. The other port is
to a dual binary. When making a port the main goal is to get everything
you already have working. You try not to rock the boat by introducing
new functionality. So I am not holding my breath for new ODBC support in
the upcoming release of Office.

But the next step after making the port IS to introduce new
functionality. Office v.X was a port. Office 2004 introduced new
functionality on a grand scale. I am hoping that right after Office 2007
equivalent for Mac Office hits the streets that database functionality
will become a high priority for Mac BU. If there ever was a window of
opportunity to expand the user base for Mac Office it would be at that
time. The key areas of growth that I see for Mac Office are with regard
to databases. A restoration of full programmatic support of ODBC is a
must. No one has ever done much creatively with a SQL-GUI. If you look
at Oracle, MS Access, FoxPro, FileMaker - they are all pretty much the
same. A 3-D drag and drop interface would be a real nice kick for Mac MS
Query. Adding the ability to read and create MS Access forms and reports
to MS-Query for Mac would make a port of MS Access unnecessary. MacBU
could take the same approach for MS Query as they did with Entourage
with regard to Outlook: it doesn't have to be the same. It just has to
be able to do the same work and work with the files. Indeed - this is a
golden opportunity to show off what a Mac interface can do. And along
the way MacBU could re-work the MS Word ODBC connectivity and get that
working again.

OK - now I'm off my soapbox. Back to work and play.

-Jim Gordon
Mac MVP

--

Please reply to the newsgroup to maintain the thread. Please do not email
me unless I ask you to.

John McGhie <[email protected]>
Microsoft MVP, Word and Word for Macintosh. Consultant Technical Writer
Sydney, Australia +61 (0) 4 1209 1410

 

[Phillip M. Jones, CE.T.]

Why don't you go back to Word 6 Excel 5 format that was exactly
identical to windows 96 version. If you were to cover up everything
about the computer except just the viewable part of the screen and had
tow people look, They would look exactly identical, and except mapping
the option key on mac to alt key on PC and Command to the windows key
the command set was identical.

As a Matter of Fact I could do some thing in those versions (especially
Word) I can't do in versions now.

one example. I could click the icon for paragraph mark and view hidden
Characters I could double click on the little black boxes and change
format of one complete paragraph by typing in or selecting itallacs,
bold underline, left, center, right or Justified.

To this day, I have been unable to, do this in Office 2004.

I know to Mac people the windows 95 look and feel looked awful. But, I
go used to it, I was able to do a lot of stuff, I can't do now.

Hi Jim:

Thanks for an eloquent and persuasive argument, which I thoroughly applaud.

However, I would be a little tougher on them that you have been. I see no
reason why this next version of Mac Office "needs" to be a two-way port. I
would have thought this was a golden opportunity to make it a "one"-way
port: take the whole of Office 2007 and bring it to the Mac.

Yes, I am keenly aware that in software terms this makes it a much larger
task. Something like 80 per cent of the computer's time in Microsoft Office
on the PC is spent running Windows code. Because the same vendor had the
opportunity to build the two to fit together, Office makes heavy use of
Windows functions. They'd be silly if it didn't.

So the job is a lot bigger than cutting the user interface off the thing and
cross-compiling it.

But it's not impossible!

And I am afraid I don't share Jim's rosy interpretation of how little we
have to do to trigger that wholesale "switch".

Currently, the first question any prospective switcher asks is "If I go
there, what *won't* it do? Currently, that's a huge list. Database
connectivity is only a small part of it.

This thing can't even inter-operate successfully with ITSELF!! You can't
take a file from Mac Office and send it to your PC workmate and guarantee
s/he will see the same result.

Yes, it will get close. Yes, the file formats are the same. Yes, there are
no worries about being able to open or edit the file on either platform.
But 100 per cent functionally compatible? Nope.

Yes, it is true that 80 per cent of users use only ten per cent of the
application's capabilities. And that Mac Office applications have more like
90 per cent of the functionality their PC Office equivalents.

The problem is that 100 per cent of Office users use "some" of the functions
"other people rarely use". Just that each of us use different ones

If I were creating a major corporation from scratch, I could easily specify
"Macintosh Only" on the desktops, and conduct business very successfully.
We have a large phone company in Australia that did just that, with great
success.

The rot sets in when you try to create a "mixed" environment. Bring PCs
into a Mac-only shop, or Macs into a PC-only shop, and you get more than
twice the problems. The first thing a corporation wants to do is to make
its user's environment "purpose designed" for the work they're to do.

And that's where we're run into problems in a mixed environment. You can
(and should...) radically customise Mac Office using AppleScript. Or PC
Office, using VBA. Regrettably, when you try to move those customisations
over to the other platform, you get to do all the work again. Since the
amount of work involved in a full-scale customisation is huge, you wouldn't
want to have to do it all twice.

That's one place we could make a huge leap with Office Next on the Mac, if
we get it right. Customisation in Office 2007 relies a lot less on writing
VBA and a lot more on tweaking configuration files using XML. Those tweaks
should simply open up and work in Mac Office.

If they do, that's a very important part of the Switcher story written. We
need to make a big effort during the beta for the next version of Mac Office
to ensure that any tweaks done to the PC Office XML work correctly on the
Mac.

As people get into this, you will hear a LOT of noise from the tree-huggers
and vested interests about the new Office user interface.

OK, let me agree with them right off the bat: The new UI is nothing like the
old one That's intentional. In MY experience, the new UI works a hell
of a lot better than the old one. Provided I am willing to accept that the
old keystrokes and the old approach to making documents have gone forever.

The new UI in Microsoft Office enables us to make better documents faster.
But it does not work the same way as the old interface. And the Mac version
of it will NOT look exactly the same as the Windows Vista version. It
can't. This is a *Mac*, for heaven's sale!

Just thought I would prepare you for that

Cheers

--
------------------------------------------------------------------------
Phillip M. Jones, CET |LIFE MEMBER: VPEA ETA-I, NESDA, ISCET, Sterling
616 Liberty Street |Who's Who. PHONE:276-632-5045, FAX:276-632-0868
Martinsville Va 24112 |[email protected], ICQ11269732, AIM pjonescet
------------------------------------------------------------------------

If it's "fixed", don't "break it"!

mailto[email protected]

<http://www.kimbanet.com/~pjones/default.htm>
<http://www.kimbanet.com/~pjones/90th_Birthday/index.htm>
<http://www.kimbanet.com/~pjones/Fulcher/default.html>
<http://www.kimbanet.com/~pjones/Harris/default.htm>
<http://www.kimbanet.com/~pjones/Jones/default.htm>

<http://www.vpea.org>

 

[John McGhie [MVP - Word and Word Macintosh]]

Hi Phillip:

Why? Because Mac users hated it

Like you, I took to it like a duck to water: I walked from one desk running
Windows to the other running Word 6 Mac, and I was right at home. But that
was not the experience for people who had never used Windows

I really don't believe anyone will ever produce a definitive answer the
question as to which user interface style is "better" If you are
comparing Windows XP and OS X, I think it depends a lot on what you're
doing. Maybe Windows has the edge for doing office tasks, if you know it
well. But it's a small edge. Mac OS X probably has the edge if you're
working on graphics or music. But it's a small edge.

Now, we have Microsoft gleefully claiming that Vista is a better Mac than
Mac. They're probably right: it is very good. On the other hand, we have
Apple cheerfully chortling that the next version of OS X (I can't keep up
with the names... Some large feline...) is a "better Vista than Vista". I
suspect they're right too...

However, the real task is to make Mac Office work well on the Mac. And for
that, they need to throw out the Windows/Vista user interface and make the
same functions available using the OS X user interface.

I predict (haven't seen it yet...) that the new Mac Office will look "quite
like" the Windows Office 2007 (I have seen that one). But there will be
substantial differences. It will work and behave exactly like its Mac
operating system does. Because the user interface will actually BE Mac OS
X, not Windows.

I confidently predict that there will be "A strip up the top that behaves
like the Ribbon". That's because I've had a chance to play with the Ribbon,
and I know how good it is. For driving Office

And before we go too far down the "what does that mean" path, I have to tell
you that Office 2007 does look better and work more nicely in Vista. Hope
so: that's what they designed it for But I am absolutely confident that
Mac Office Next will look and work better on the Mac than Office 2007 does
in Windows? Why? Because Mac Business Unit at Microsoft has the benefit of
going to market a bit later, and thus learning from the PC Office Product
Group's mistakes

Cheers

Why don't you go back to Word 6 Excel 5 format that was exactly
identical to windows 96 version. If you were to cover up everything
about the computer except just the viewable part of the screen and had
tow people look, They would look exactly identical, and except mapping
the option key on mac to alt key on PC and Command to the windows key
the command set was identical.

As a Matter of Fact I could do some thing in those versions (especially
Word) I can't do in versions now.

one example. I could click the icon for paragraph mark and view hidden
Characters I could double click on the little black boxes and change
format of one complete paragraph by typing in or selecting itallacs,
bold underline, left, center, right or Justified.

To this day, I have been unable to, do this in Office 2004.

I know to Mac people the windows 95 look and feel looked awful. But, I
go used to it, I was able to do a lot of stuff, I can't do now.

Hi Jim:

Thanks for an eloquent and persuasive argument, which I thoroughly applaud.

However, I would be a little tougher on them that you have been. I see no
reason why this next version of Mac Office "needs" to be a two-way port. I
would have thought this was a golden opportunity to make it a "one"-way
port: take the whole of Office 2007 and bring it to the Mac.

Yes, I am keenly aware that in software terms this makes it a much larger
task. Something like 80 per cent of the computer's time in Microsoft Office
on the PC is spent running Windows code. Because the same vendor had the
opportunity to build the two to fit together, Office makes heavy use of
Windows functions. They'd be silly if it didn't.

So the job is a lot bigger than cutting the user interface off the thing and
cross-compiling it.

But it's not impossible!

And I am afraid I don't share Jim's rosy interpretation of how little we
have to do to trigger that wholesale "switch".

Currently, the first question any prospective switcher asks is "If I go
there, what *won't* it do? Currently, that's a huge list. Database
connectivity is only a small part of it.

This thing can't even inter-operate successfully with ITSELF!! You can't
take a file from Mac Office and send it to your PC workmate and guarantee
s/he will see the same result.

Yes, it will get close. Yes, the file formats are the same. Yes, there are
no worries about being able to open or edit the file on either platform.
But 100 per cent functionally compatible? Nope.

Yes, it is true that 80 per cent of users use only ten per cent of the
application's capabilities. And that Mac Office applications have more like
90 per cent of the functionality their PC Office equivalents.

The problem is that 100 per cent of Office users use "some" of the functions
"other people rarely use". Just that each of us use different ones

If I were creating a major corporation from scratch, I could easily specify
"Macintosh Only" on the desktops, and conduct business very successfully.
We have a large phone company in Australia that did just that, with great
success.

The rot sets in when you try to create a "mixed" environment. Bring PCs
into a Mac-only shop, or Macs into a PC-only shop, and you get more than
twice the problems. The first thing a corporation wants to do is to make
its user's environment "purpose designed" for the work they're to do.

And that's where we're run into problems in a mixed environment. You can
(and should...) radically customise Mac Office using AppleScript. Or PC
Office, using VBA. Regrettably, when you try to move those customisations
over to the other platform, you get to do all the work again. Since the
amount of work involved in a full-scale customisation is huge, you wouldn't
want to have to do it all twice.

That's one place we could make a huge leap with Office Next on the Mac, if
we get it right. Customisation in Office 2007 relies a lot less on writing
VBA and a lot more on tweaking configuration files using XML. Those tweaks
should simply open up and work in Mac Office.

If they do, that's a very important part of the Switcher story written. We
need to make a big effort during the beta for the next version of Mac Office
to ensure that any tweaks done to the PC Office XML work correctly on the
Mac.

As people get into this, you will hear a LOT of noise from the tree-huggers
and vested interests about the new Office user interface.

OK, let me agree with them right off the bat: The new UI is nothing like the
old one That's intentional. In MY experience, the new UI works a hell
of a lot better than the old one. Provided I am willing to accept that the
old keystrokes and the old approach to making documents have gone forever.

The new UI in Microsoft Office enables us to make better documents faster.
But it does not work the same way as the old interface. And the Mac version
of it will NOT look exactly the same as the Windows Vista version. It
can't. This is a *Mac*, for heaven's sale!

Just thought I would prepare you for that

Cheers

Hi John & Jonathan,

Every once in a while I wander into the ODBC and other database oriented
newsgroups. They are very active places. Easily 10X the traffic in the
Mac groups. I have no doubt that there is a huge untapped demand for
data connectivity within Mac Office and that this demand is the only
major remaining hold-back for future large scale switching to Mac Office
by Windows users.

Until ActualTechnologies (3 cheers to Jonathan) came along there was not
a low-cost easy to use way to implement some key database features in
Mac Office. I always felt that OpenLink's stuff was too restrictive and
expensive requiring a complicated 2-tier network oriented setup.

At any rate, as I mentioned before it's a chicken or egg situation. ODBC
drivers are not part of MacOS and Mac BU was disinclined to provide them
as part of Office. Mac BU had to wait till 3rd party drivers hit the
market. Thankfully, now they have. Jonathan's company has made a dual
binary version, which can be taken advantage of by Mac Office, even for
Microsoft Access.

The next Mac version of office is going to be a 2-way port. One port is
existing functionality into the new XML file format. The other port is
to a dual binary. When making a port the main goal is to get everything
you already have working. You try not to rock the boat by introducing
new functionality. So I am not holding my breath for new ODBC support in
the upcoming release of Office.

But the next step after making the port IS to introduce new
functionality. Office v.X was a port. Office 2004 introduced new
functionality on a grand scale. I am hoping that right after Office 2007
equivalent for Mac Office hits the streets that database functionality
will become a high priority for Mac BU. If there ever was a window of
opportunity to expand the user base for Mac Office it would be at that
time. The key areas of growth that I see for Mac Office are with regard
to databases. A restoration of full programmatic support of ODBC is a
must. No one has ever done much creatively with a SQL-GUI. If you look
at Oracle, MS Access, FoxPro, FileMaker - they are all pretty much the
same. A 3-D drag and drop interface would be a real nice kick for Mac MS
Query. Adding the ability to read and create MS Access forms and reports
to MS-Query for Mac would make a port of MS Access unnecessary. MacBU
could take the same approach for MS Query as they did with Entourage
with regard to Outlook: it doesn't have to be the same. It just has to
be able to do the same work and work with the files. Indeed - this is a
golden opportunity to show off what a Mac interface can do. And along
the way MacBU could re-work the MS Word ODBC connectivity and get that
working again.

OK - now I'm off my soapbox. Back to work and play.

-Jim Gordon
Mac MVP


John McGhie [MVP - Word and Word Macintosh] wrote:
'Course it does

"Expertise" is not the resource that's scarce here...

Just the same as in your company, the issue is the length of the piece of
string. And as with any software company, the ropes we're talking about
are
the ones attached to Product Marketing's budget and schedule

Cheers


On 26/5/06 5:37 AM, in article
(e-mail address removed),

I suspect that regrettably, in this case the Excel team got to it, the
Word
one did not
ODBC is hard to do on the Mac
It's not THAT hard! ;-)

No more difficult than on Windows, actually. I'm sure the Mac Word
team has more than enough talent to implement ODBC if it makes it on to
the feature list.

Jonathan Monroe
Actual Technologies - ODBC for OS X
http://www.actualtechnologies.com

--

Please reply to the newsgroup to maintain the thread. Please do not email
me unless I ask you to.

John McGhie <[email protected]>
Microsoft MVP, Word and Word for Macintosh. Consultant Technical Writer
Sydney, Australia +61 (0) 4 1209 1410

 

[CyberTaz]

Hi All -

Have just been casually - yet with interest - observing the thread and
couldn't resist sticking my nose in with regard to your last post, Phillip.
Perhaps I am missing the point, but I am unclear as to any problem with the
following;

As a Matter of Fact I could do some thing in those versions (especially
Word) I can't do in versions now.

one example. I could click the icon for paragraph mark and view hidden
Characters

AFAIK, the Show/Hide button has not gone away - at least it still appears on
my Formatting Toolbar in 2004 and continues to function as it always has.

I could double click on the little black boxes and change
format of one complete paragraph

I'm not sure which "little black boxes" you're referring to, but the only
ones that come to mind are those that show to the left of a Styled para...
but only if certain Styles (such as Headings 1-4, Caption) have been
applied. I believe the only reason for those marks is to indicate styles
which are 'tagged' for use in TOCs, TOFs. Since they are otherwise not
there, I never came to rely on them for selecting anything. Dbl-Clk them to
call up the Format Para dialog, perhaps, but that's about it.

by typing in or selecting itallacs, bold underline,

which you can readily do if you either a) triple-click the para, or b)
dbl-clk in the margin left of the target para. Then apply whatever
*character* formatting you wish. However,

left, center, right or Justified.

are all *paragraph* formatting attribs - as are line spacing & spacing btw
paras - so selecting the para is unnecessary. Having the insertion point in
the target para is all that is necessary unless you want to change character
& paragraph formatting... But this all still revolves around *direct*
formatting and avoiding/negating the use of Styles.

Isn't it interesting how different users adopt such a diverse array of
*implementations* when presented with the same *implements*?

Regards |:>)
Bob Jones
[MVP] Office:Mac