I am currently coding a VB 6 DLL and a VB 6 EXE, each uses Excel 2003.

Both projects require the use of the Office 11 object library, which results
in a reference to the mso.d11 for Office 11, version 11.0.8221.0.

However, certain constants are not defined unless I include the MSO.dll for
what is called the Office 12 object library, version 12.0.6320.5000.

The file is Program Files\Common Files\Microsoft Shared\OFFICE12\mso.dll.
Office 2007 has never been on the computer being used.

Where did that file come from?
From an update to Office 2003?

Neither version is listed at http://support.microsoft.com/dllhelp/.

Hi Howard,

If the reference is set to the Office-11 mso.dll do *not* use any named
constants that are new in Office-12. Simply define your own say at module
level, you can use the same names, or use the intrinsic values.

Public Const msoThemeDark1 As Long = &H1

I can't imagine how \OFFICE12\mso.dll ever got onto the computer if Office
2007 has never been installed.

Regards,
Peter T

"Howard Kaikow" wrote in message
...
I am currently coding a VB 6 DLL and a VB 6 EXE, each uses Excel 2003.

Both projects require the use of the Office 11 object library, which
results
in a reference to the mso.d11 for Office 11, version 11.0.8221.0.

However, certain constants are not defined unless I include the MSO.dll
for
what is called the Office 12 object library, version 12.0.6320.5000.

The file is Program Files\Common Files\Microsoft Shared\OFFICE12\mso.dll.
Office 2007 has never been on the computer being used.

Where did that file come from?
From an update to Office 2003?

Neither version is listed at http://support.microsoft.com/dllhelp/.

"SvenC" wrote in message
...
I doubt that strongly. Just checked an WinXP SP3 with Office 2003 all
fully patched from microsoft update.
No Office12 folder and hence no mso.dll.

There must be some other component you installed which cause this.
Maybe some add on which tries to install some office modules or
the PIAs? Maybe the OpenXML or PDF converters?

Well, not only is the Office12 mso.dll present in my Office 2000, Office XP
and Office 2003 systems, the Office 11 and Office 10 mso.dll files no longer
contain references to constants related to the CommandBars object, at least
forthose constants I am using. Those are now in the Office 12 mso.dll. I
have not checked in Office 9, but the Office 2000 system is different im
that it has no Office9 directory, but it does have an Office 12 directory
with an mso.dll file,

Such a change would only be made by MSFT.

A ha!
I just noticed that the Office 2003 system has an J:\Documents and
Settings\Howard Kaikow\Application Data\OfficeUpdate12 directory. The
directory is dated in March 2009, when I ran the updates. It has the install
files for what likely created Office12.

Ditto for the Office 2000 and Office XP systems.

Thus far, I have only noticed a problem for mso* constants related to the
CommandBars object.

It may be that MSFT decided to separate those into an Office12/mso.dll to
facilitate moving back/forth with Office 2007.

Hi Howard,

Well, not only is the Office12 mso.dll present in my Office 2000, Office
XP
and Office 2003 systems, the Office 11 and Office 10 mso.dll files

What are the version numbers of those mso.dlls?

no longer
contain references to constants related to the CommandBars object, at
least
forthose constants I am using. Those are now in the Office 12 mso.dll. I
have not checked in Office 9, but the Office 2000 system is different im

Which constants? Please give some concrete examples. The only thing which
makes sense to me would be that you used constants new to Office 12 and
thought they should have been there in earlier versions of Office as well.

Such a change would only be made by MSFT.

I pretty much doubt that MS would create dependencies between
Office versions.

A ha!
I just noticed that the Office 2003 system has an J:\Documents and
Settings\Howard Kaikow\Application Data\OfficeUpdate12 directory. The
directory is dated in March 2009, when I ran the updates. It has the
install
files for what likely created Office12.

Typically Microsoft put its files in a Microsoft subdirectory, so having an
OfficeUpdate12 directory directly in Application Data looks strange.

What kind of update service do you use?
Microsofts online update service or an offline WSUS?

BUT: back to your original question:

I am currently coding a VB 6 DLL and a VB 6 EXE, each uses Excel 2003.
Both projects require the use of the Office 11 object library, which
results
in a reference to the mso.d11 for Office 11, version 11.0.8221.0.
However, certain constants are not defined unless I include the MSO.dll
for
what is called the Office 12 object library, version 12.0.6320.5000.

How about installing a clean Windows with a clean Office 2003 and apply
only their current service packs. Are there still CommandBar related
constants
missing? If yes, which - they might be new to Office 2007 and would have
no meaning in older versions.

--
SvenC

"Howard Kaikow" wrote in message

Well, not only is the Office12 mso.dll present in my Office 2000, Office
XP
and Office 2003 systems, the Office 11 and Office 10 mso.dll files no
longer
contain references to constants related to the CommandBars object, at
least
forthose constants I am using. Those are now in the Office 12 mso.dll. I
have not checked in Office 9, but the Office 2000 system is different im
that it has no Office9 directory, but it does have an Office 12 directory
with an mso.dll file,

Surely not. As you have VB6 you'll presumably have tlbinf32.dll and should
be able to run this

Sub ListConstants()
' requires tlbinf32.dll is registered on the system
Dim a As Long, i As Long
Dim sFile As String
Dim TLIApp As Object 'TLI.TLIApplication
Dim XLInfo As Object 'TLI.TypeLibInfo
Dim c As Object 'ConstantInfo
Dim m As Object 'Members

'Set TLIApp = New TLI.TLIApplication ' early binding
Set TLIApp = CreateObject("TLI.TLIApplication") ' late binding

' << change sFile to suit
'sFile = Application.Path & "\Excel.exe"
'sFile = ThisWorkbook.VBProject.References("OFFICE").FullPa th ' "VBA"
etc
sFile = "C:\Program Files\Common Files\Microsoft
Shared\OFFICE12\MSO.DLL"

On Error Resume Next
Set XLInfo = TLIApp.TypeLibInfoFromFile(sFile)
On Error GoTo 0
If XLInfo Is Nothing Then
MsgBox "file not found or registered" & vbCr & sFile
Exit Sub
End If

Columns("A:D").Clear
For Each c In XLInfo.Constants
a = a + 1
Cells(a, 1) = c.Name
Set m = c.Members
For i = 1 To m.Count
a = a + 1
Cells(a, 2) = m(i).Name
Cells(a, 3) = m(i).Value
Cells(a, 4) = "H " & Hex(CLng(m(i).Value))
Next
Next
Columns("A:D").EntireColumn.AutoFit
End Sub

Regards,
Peter T

"SvenC" wrote in message
...
What are the version numbers of those mso.dlls?

For Office 2003: Office11\mso.dll is 11.0.8221.0, Office12\mso.dll is
12.0.6320.5000.
For Office XP: Office10\mso.dll is 10.0.6845.0, Office12\mso.dll is same as
above.
For Office 2000: Office12\mso.dll is same as above. No other mso.dll in
Office 2000.

Which constants? Please give some concrete examples. The only thing which
makes sense to me would be that you used constants new to Office 12 and
thought they should have been there in earlier versions of Office as well.

I've already stated that this is with old code, no new constants.

I've posted an example below.
When compiling wit VB 6, ONLY the Office12\mso.dll is listed.
However, I can browse and add a reference to Office11\mso.dll.
Either mso.dll does the job.

Somewhere MSFT mut have documented (silly me, asking for documentation) this
change.

I pretty much doubt that MS would create dependencies between
Office versions.

There would be no other reson for creating such a library.
Having anf Office 12 mod.dll likely facilitates Office 2007 importing
critters from earlier versions.

Typically Microsoft put its files in a Microsoft subdirectory, so having
an
OfficeUpdate12 directory directly in Application Data looks strange.

These are MSFT files.

What kind of update service do you use?
Microsofts online update service or an offline WSUS?

MSFT update.
..
How about installing a clean Windows with a clean Office 2003 and apply
only their current service packs. Are there still CommandBar related
constants
missing? If yes, which - they might be new to Office 2007 and would have
no meaning in older versions.

No reason to do that.
This update is clearly from MSFT and, if needed, I can brute force to the
old Office11 mso.dll.

The puzzle is why some others are not seeing this update.

In another forum, I have found folkes that do have the Office12 critter.

No point in discussing furthe.
Somebody here likely has contacts at MSFT who can explain what's going on.

The log file from the install has:
V3_2|514182|INSTALL|MSPUB_8103_INTL||2006-11-29 03:07:36|9|SUCCESS|||
V3_2|514379|INSTALL|POWERPNT_8110_INTL||2006-11-29 03:07:36|9|SUCCESS|||
V3_2|514374|INSTALL|WINWORD_8106_INTL||2006-11-29 03:07:36|9|SUCCESS|||
V3_2|514382|INSTALL|MSXML5_8107_INTL||2006-11-29 03:07:36|9|SUCCESS|||
V3_2|513905|INSTALL|GPFILT_8030_ENG||2006-11-29 03:07:36|9|SUCCESS|||
V3_2|514383|INSTALL|MSO_8107_INTL||2006-11-29 03:07:36|9|SUCCESS|||
V3_2|514366|INSTALL|EXCEL_8105_INTL||2006-11-29 03:07:36|9|SUCCESS|||
V3_2|518405|INSTALL|OUTLFLTR_8111_INTL||2006-11-29 03:07:36|9|SUCCESS|||
V3_2|518408|INSTALL|LCCWIZ_8111_ENG||2006-11-29 03:07:36|9|SUCCESS|||
V3_2|514387|INSTALL|STLIST_8104_INTL||2006-11-29 03:07:36|9|SUCCESS|||
V3_2|518780|INSTALL|OUTLOOK_8119_INTL||2007-02-09 01:32:52|9|SUCCESS|||
V3_2|518718|INSTALL|EXCEL_8117_INTL||2007-02-09 01:32:52|9|SUCCESS|||
V3_2|518720|INSTALL|OUTLFLTR_8119_INTL||2007-02-09 01:32:52|9|SUCCESS|||
V3_2|518532|INSTALL|RICHED20_8114_INTL||2007-07-22 13:50:17|9|SUCCESS|||
V3_2|519161|INSTALL|EXCEL_11.0.8142_INTL||2007-07-22 13:50:17|9|SUCCESS|||
V3_2|518939|INSTALL|MSO_11.0.8132_INTL||2007-07-22 13:50:17|9|SUCCESS|||
V3_2|518938|INSTALL|WINWORD_11.0.8134_INTL||2007-07-22 13:50:17|9|SUCCESS|||
V3_2|518937|INSTALL|POWERPNT_11.0.8134_INTL||2007-07-22
13:50:17|9|SUCCESS|||
V3_2|519339|INSTALL|OUTLFLTR_11.0.8143_INTL||2007-07-22
13:50:17|9|SUCCESS|||
V3_2|518828|INSTALL|EUROTOOL_8118_INTL||2007-07-22 13:50:17|9|SUCCESS|||
V3_2|519988|INSTALL|MAINSP3_11.0.8173_ENG||2008-06-08 08:35:51|9|SUCCESS|||
V3_2|525359|INSTALL|OUTLFLTR_11.0.8215_MANY||2008-06-08
08:35:51|9|SUCCESS|||
V3_2|525342|INSTALL|MSPUB_11.0.8212_MANY||2008-06-08 19:51:29|9|SUCCESS|||
V3_2|524657|INSTALL|EXCEL_11.0.8211_MANY||2008-06-08 19:51:29|9|SUCCESS|||
V3_2|525349|INSTALL|WINWORD_11.0.8215_MANY||2008-06-08 19:51:29|9|SUCCESS|||
V3_2|523488|INSTALL|MSO_11.0.8202_MANY||2008-06-08 19:51:29|9|SUCCESS|||
V3_2|524858|INSTALL|VBE6_11.0.8203_MANY||2008-06-08 19:51:29|9|SUCCESS|||
V3_2|524861|INSTALL|OUTLOOK_11.0.8206_MANY||2008-06-08 19:51:29|9|SUCCESS|||
V3_2|520996|INSTALL|OLKINTL_11.0.8201_ENG||2008-06-08 19:51:29|9|SUCCESS|||
V3_2|524860|INSTALL|WORKS632_11.0.8202_MANY||2008-08-06
05:47:00|9|SUCCESS|||
V3_2|527524|INSTALL|OUTLFLTR_11.0.8223_MANY||2008-08-06
05:47:00|9|SUCCESS|||
V3_2|527525|INSTALL|OUTLOOK_11.0.8217_MANY||2008-08-06 05:47:00|9|SUCCESS|||
V3_2|532336|INSTALL|MSO_12.0.6324.5002_MANY||2009-03-07
18:00:41|9|SUCCESS|||
V3_2|536389|INSTALL|WINWORD_11.0.8237_MANY||2009-03-07 18:00:41|9|SUCCESS|||
V3_2|531879|INSTALL|MSO_11.0.8221_MANY||2009-03-07 18:00:41|9|SUCCESS|||
V3_2|527668|INSTALL|GPFILT_11.0.8203_ENG||2009-03-07 18:00:41|9|SUCCESS|||
V3_2|530067|INSTALL|POWERPNT_11.0.8227_MANY||2009-03-07
18:00:41|9|SUCCESS|||
V3_2|531884|INSTALL|GDIPLUS_11.0.8230_MANY||2009-03-07 18:00:41|9|SUCCESS|||
V3_2|531453|INSTALL|SNAPVIEW_11.0.8229_ENG||2009-03-07 18:00:41|9|SUCCESS|||
V3_2|536366|INSTALL|MSXML5_11.0.8237_MANY||2009-03-07 18:00:41|9|SUCCESS|||
V3_2|536361|INSTALL|EXCEL_11.0.8237_MANY||2009-03-07 18:00:41|9|SUCCESS|||
V3_2|536416|INSTALL|OUTLFLTR_11.0.8246_MANY||2009-03-07
18:00:41|9|SUCCESS|||

ident.ini has:
[cabpools]
ServerCount=2
default=2
Server1=http://Office.microsoft.com/officeupdate/catalog/ident/Officemicroso
ftcom
Server2=http://download.microsoft.com/download/0/5/9/0590D3F9-106B-4A0B-8841
-C3C999C9A81A/
[v3]
ServerCount=1
default=1
Server1=http://Office.microsoft.com/officeupdate/content
[content]
ServerCount=1
default=1
server1=http://Office.microsoft.com/officeupdate/catalog

OK, here's the example.

I have to include either the Office12\mso.dll or the Office11\mso.dsl as a
reference, as well as the reference for Excel.

Option Explicit
Private Sub btnExit_Click()
appExcel.Quit
Set appExcel = Nothing
Unload Me
End Sub

Private Sub btnRunMe_Click()
Set appExcel = New Excel.Application
CreateToolbar
End Sub

and

Option Explicit
Public appExcel As Excel.Application
Private Const sToolbarName As String = "Nuts"

Public Sub CreateToolbar()
With appExcel
.Workbooks.Add
'Get rid of any existing toolbar
On Error Resume Next
.CommandBars(sToolbarName).Delete
On Error GoTo 0

'Create new toolbar
With .CommandBars.Add(Name:=sToolbarName)
With .Controls.Add(Type:=Office.msoControlButton)
.Style = Office.msoButtonCaption
.Caption = "Nuts are good for you!"
.OnAction = "ListNuts"
.ToolTipText = "Ask any squirrel!"
End With
.Position = Office.msoBarTop
.Visible = True
End With
Debug.Print .CommandBars(sToolbarName).Name
.ActiveWorkbook.Close SaveChanges:=False
End With
End Sub

Public Sub CreateToolbarNoOffice()
With appExcel
.Workbooks.Add
'Get rid of any existing toolbar
On Error Resume Next
.CommandBars(sToolbarName).Delete
On Error GoTo 0

'Create new toolbar
With .CommandBars.Add(Name:=sToolbarName)
With .Controls.Add(Type:=msoControlButton)
.Style = msoButtonCaption
.Caption = "Nuts are good for you!"
.OnAction = "ListNuts"
.ToolTipText = "Ask any squirrel!"
End With
.Position = msoBarTop
.Visible = True
End With
Debug.Print .CommandBars(sToolbarName).Name
.ActiveWorkbook.Close SaveChanges:=False
End With
End Sub

I compiled 2 versions of the test program on my Office 2003 system.

In one, I used the Office12\mso.dsl. In the other, I used the
Office11\mso.dll.

I then copied the prohects for each to my Office 2007 system.

I opened each project on the Office 2003 system using VB 6. In both cases,
the Office 2007 Office12 mso.dll was substituted

I then compiled both projects using VB 6 in the Office 2007 system, and
moved them back to the Office 2003 system. They both ran.

I guess that MSFT's goal is to permit such back and forth, as long as you do
not use features present in Office 2007 that are not in the earlier versions
of interest. This makes sense.

But the puzzle remains as to why some folkes have the Office12 mso.dll and
others do not.

one possibility is that one might have to have a compiler, such as VB 6 or,
some other language, and not just office.

If you just write VBA code within Office, the Office12 mso.dll is not listed
as a reference.

However, if you compile with, say, VB 6, the Office 12 mso is listed, but
the Office 11 mso.dll is NOT listed, thou you can browse and brute force
reference the Office 11 version. I ASSuME that the Office 12 mso could also
be referenced from within VBA, but I would not try it.

But the puzzle remains as to why some folkes have the Office12 mso.dll and
others do not.

one possibility is that one might have to have a compiler, such as VB 6 or,
some other language, and not just office.

The Compatibility Pack may install the MSO.DLL version in question. Of
possibly one or another of the Office viewer apps (though not the PowerPoint
viewer ... I just checked that).

"Steve Rindsberg" wrote in message
...
But the puzzle remains as to why some folkes have the Office12 mso.dll
and
others do not.

one possibility is that one might have to have a compiler, such as VB 6
or,
some other language, and not just office.

The Compatibility Pack may install the MSO.DLL version in question. Of
possibly one or another of the Office viewer apps (though not the
PowerPoint
viewer ... I just checked that).

I do not have the Compatibility Pack, at least I never asked for it to be
installed, not do I have any viewer on ANY of thse systems with Office 2000,
XP, or 2003.

How could I determine whether I have the Compatibility Pack?

After I installed the Compatibility Pack on Office 2003 SP3 (XP Pro,
SP3) Excel 2007 file types are now listed at the end of the Save As
Dialog in Excel (2003)

--
Clif

"Howard Kaikow" wrote in message
...
"Steve Rindsberg" wrote in message
...


How could I determine whether I have the Compatibility Pack?





--
Clif

"Clif McIrvin" wrote in message
...
After I installed the Compatibility Pack on Office 2003 SP3 (XP Pro,
SP3) Excel 2007 file types are now listed at the end of the Save As
Dialog in Excel (2003)

Thanx.

Then I do not have the compatibility pack.

Searching at MSFT's support site, I found only 1 article that referred to
OfficeUpdate12.
Not sure that is relevant, not yet read.

Title is
How to troubleshoot failures updating your Office installation from the
Office Update Web site
http://support.microsoft.com/kb/304498

In article , Howard Kaikow wrote:
"Steve Rindsberg" wrote in message
...
But the puzzle remains as to why some folkes have the Office12 mso.dll
and
others do not.

one possibility is that one might have to have a compiler, such as VB 6
or,
some other language, and not just office.

The Compatibility Pack may install the MSO.DLL version in question. Of
possibly one or another of the Office viewer apps (though not the
PowerPoint
viewer ... I just checked that).

I do not have the Compatibility Pack, at least I never asked for it to be
installed, not do I have any viewer on ANY of thse systems with Office 2000,
XP, or 2003.

How could I determine whether I have the Compatibility Pack?

Create or download (if you don't have Ofc2007) a PPTX or DOCX file.

Try to open it in the appropriate Office 2003 app. If it opens, you have the
compat. pack installed.

"Steve Rindsberg" wrote in message
...
Create or download (if you don't have Ofc2007) a PPTX or DOCX file.

Try to open it in the appropriate Office 2003 app. If it opens, you have
the
compat. pack installed.

Tried both Excel and Word.
Both asked whether I wanted to download the compatibility pack.

"Howard Kaikow" wrote in message
...
Searching at MSFT's support site, I found only 1 article that referred to
OfficeUpdate12.
Not sure that is relevant, not yet read.

Title is
How to troubleshoot failures updating your Office installation from the
Office Update Web site
http://support.microsoft.com/kb/304498

The article does indicate that OfficeUpdate12 directory will be in
Application Data, not Program Files.

To play safe, I'll have to try to remember to compile using
Office11\mso.dll, instead of Office12\mso.dsl.