| Author |
Message |
|
vova
#1 / 12
|
 Early Binding - Late Binding I need to program some MS Outlook processes. If I use early binding I have no problem with using events. In this case I have to set a reference to Microsoft Outlook 12. But I'm afraid that if application users will have different versions of MS Office on their workstations my application won't work. If in the future workstations will be upgraded to let's say MS Office version 13 then my app will stop to work. How to overcome this problem?
Thank you
vovan
|
| Mon, 04 Jul 2011 10:00:18 GMT |
|
 |
|
Bill McCarth
#2 / 12
|
Early Binding - Late Binding Hi vovan, You might get more informed responses in one of the office programming
groups, but usually Office keeps the same basic interfaces. So binding to
the Outlook 12 object model should still work in Outlook 13. You can of
course test this today as Outlook 13 is Outlook 2007.
Quote: >I need to program some MS Outlook processes. If I use early binding I have >no problem with using events. In this case I have to set a reference to >Microsoft Outlook 12. But I'm afraid that if application users will have >different versions of MS Office on their workstations my application won't >work. If in the future workstations will be upgraded to let's say MS Office >version 13 then my app will stop to work. > How to overcome this problem?
> Thank you
> vovan
|
| Mon, 04 Jul 2011 10:07:17 GMT |
|
|
|
vova
#3 / 12
|
Early Binding - Late Binding Thank you Bill. You say Office keeps the same basic interfaces. Does it mean that I won't need to reset reference and recompile my application wor workstations with different versions of MS Office? vovan
Quote: > Hi vovan, > You might get more informed responses in one of the office programming
> groups, but usually Office keeps the same basic interfaces. So binding to
> the Outlook 12 object model should still work in Outlook 13. You can of
> course test this today as Outlook 13 is Outlook 2007.
>>I need to program some MS Outlook processes. If I use early binding I have
>>no problem with using events. In this case I have to set a reference to
>>Microsoft Outlook 12. But I'm afraid that if application users will have
>>different versions of MS Office on their workstations my application won't
>>work. If in the future workstations will be upgraded to let's say MS
>>Office version 13 then my app will stop to work.
>> How to overcome this problem?
>> Thank you
>> vovan
|
| Mon, 04 Jul 2011 10:13:11 GMT |
|
|
|
expv
#4 / 12
|
Early Binding - Late Binding
Quote: > Thank you Bill.
> You say Office keeps the same basic interfaces. Does it mean that I won't
> need to reset reference and recompile my application wor workstations with
> different versions of MS Office?
I don't think that it will stop working. I believe that MS maintains binary compatibility, which means that software that used older versions will still work, unless they decide to break compatibility just like what they did with VB6. I also believe that your software should work with older Office versions as long as you don't use any features in later versions. Some use type libraries for Outlook 98 or 2000 just to be sure, which don't show the new features. I don't know if these type libraries are freely available. The following article list their file names: How to automate Outlook by using Visual Basic
http://support.microsoft.com/kb/220595
You don't need to recompile for each version of Outlook. It will work on the
smallest version that supports the features that you used. If you used a
feature introduced in Outlook 12, and someone was using your software with
Outlook 10, then a run time error will occur at the line that used that
feature, but you won't get any errors in Outlook 12 and after.
|
| Mon, 04 Jul 2011 10:31:13 GMT |
|
|
|
Bill McCarth
#5 / 12
|
Early Binding - Late Binding Hi vovan, If your reference is to the Office type library then there should be no
problems running your app on the other machines. Opening your code in the
VB6 IDE on other machines however will cause issues such as type library not
found. But you actual exe shouldn't need a reference to the office dll as it
will be loading them from the com entries in the registry.
Quote: > Thank you Bill. > You say Office keeps the same basic interfaces. Does it mean that I won't > need to reset reference and recompile my application wor workstations with > different versions of MS Office? > vovan
>> Hi vovan,
>> You might get more informed responses in one of the office programming
>> groups, but usually Office keeps the same basic interfaces. So binding to
>> the Outlook 12 object model should still work in Outlook 13. You can of
>> course test this today as Outlook 13 is Outlook 2007.
>>>I need to program some MS Outlook processes. If I use early binding I
>>>have no problem with using events. In this case I have to set a reference
>>>to Microsoft Outlook 12. But I'm afraid that if application users will
>>>have different versions of MS Office on their workstations my application
>>>won't work. If in the future workstations will be upgraded to let's say
>>>MS Office version 13 then my app will stop to work.
>>> How to overcome this problem?
>>> Thank you
>>> vovan
|
| Mon, 04 Jul 2011 10:30:45 GMT |
|
|
|
Norm
#6 / 12
|
Early Binding - Late Binding Quote:
>> Thank you Bill. >> You say Office keeps the same basic interfaces. Does it mean that I >> won't need to reset reference and recompile my application wor >> workstations with different versions of MS Office? > I don't think that it will stop working. I believe that MS maintains
> binary compatibility, which means that software that used older
> versions will still work, unless they decide to break compatibility
> just like what they did with VB6. I also believe that your software
> should work with older Office versions as long as you don't use any
> features in later versions. Some use type libraries for Outlook 98 or
> 2000 just to be sure, which don't show the new features. I don't know
> if these type libraries are freely available. The following article
> list their file names:
> How to automate Outlook by using Visual Basic
> http://support.microsoft.com/kb/220595
> You don't need to recompile for each version of Outlook. It will work
> on the smallest version that supports the features that you used. If
> you used a feature introduced in Outlook 12, and someone was using
> your software with Outlook 10, then a run time error will occur at
> the line that used that feature, but you won't get any errors in
> Outlook 12 and after.
I am not sure about Outlook, but Microsft did break some backward compatibility with Office 2007. There are some functions that are not included in Office 2007 such as FileSearch. I ran into a problem with this one and had to rewrite quite a bit of a Security Program to deal with it another way. So I would not trust Microsoft to keep all future versions compatible with
the present one.
--
Norm
Don't blame me, my programming is
self-taught and my teacher was not
very experienced. :-)
|
| Tue, 05 Jul 2011 08:29:45 GMT |
|
|
|
C Kevin Provanc
#7 / 12
|
Early Binding - Late Binding
| So I would not trust Microsoft to keep all future versions compatible with | the present one. I wouldn't trust MSFT with *anything* at this point.
|
| Tue, 05 Jul 2011 08:42:56 GMT |
|
|
|
Bill McCarth
#8 / 12
|
Early Binding - Late Binding Hi Norm,
Quote: > I am not sure about Outlook, but Microsft did break some backward
> compatibility with Office 2007. There are some functions that are not
> included in Office 2007 such as FileSearch. I ran into a problem with this
> one and had to rewrite quite a bit of a Security Program to deal with it
> another way.
Was that Word ? And was the method still there but didn't work, or was the actual interface changed ?
|
| Fri, 08 Jul 2011 08:45:31 GMT |
|
|
|
Norm
#9 / 12
|
Early Binding - Late Binding Quote:
> Hi Norm,
>> I am not sure about Outlook, but Microsft did break some backward
>> compatibility with Office 2007. There are some functions that are not
>> included in Office 2007 such as FileSearch. I ran into a problem
>> with this one and had to rewrite quite a bit of a Security Program
>> to deal with it another way.
> Was that Word ? And was the method still there but didn't work, or
> was the actual interface changed ?
I believe it is Office 2007 totaly, I don't believe the FileSearch routine was included at all and my understanding is that it will not work in Excel, Access or Word. My program was only using it in Word so I cannot say for sure on the others,
but I also believe there was some other functionality left out of Office
2007.
--
Norm
Don't blame me, my programming is
self-taught and my teacher was not
very experienced. :-)
|
| Sat, 09 Jul 2011 08:47:08 GMT |
|
|
|
Bill McCarth
#10 / 12
|
Early Binding - Late Binding Hi Norm,
Quote: > I believe it is Office 2007 totaly, I don't believe the FileSearch routine
> was included at all and my understanding is that it will not work in
> Excel, Access or Word.
> My program was only using it in Word so I cannot say for sure on the
> others, but I also believe there was some other functionality left out of
> Office 2007.
Thanks Norm. I found this page which lists other changes: http://technet.microsoft.com/en-us/library/cc178954.aspx
I also saw the Project API documentation said it was "hidden", but I haven't
confirmed that for Office.
|
| Sat, 09 Jul 2011 10:07:57 GMT |
|
|
|
Norm
#11 / 12
|
Early Binding - Late Binding Quote:
> Hi Norm,
>> I believe it is Office 2007 totaly, I don't believe the FileSearch
>> routine was included at all and my understanding is that it will not
>> work in Excel, Access or Word.
>> My program was only using it in Word so I cannot say for sure on the
>> others, but I also believe there was some other functionality left
>> out of Office 2007.
> Thanks Norm. I found this page which lists other changes:
> http://technet.microsoft.com/en-us/library/cc178954.aspx
> I also saw the Project API documentation said it was "hidden", but I
> haven't confirmed that for Office.
Bill, That list is funny in that they say FileSearch was not used by most users,
but it was used a lot by anyone automating word or excel. What it broke in
my application was when I made reference to the Word object and then tried
to use FileSearch with the object.
When I was searching for another way of working with searchs through Word
documents I ran into a lot of people that were having problems with the
automation routines.
Norm
--
Norm
Don't blame me, my programming is
self-taught and my teacher was not
very experienced. :-)
|
| Sat, 09 Jul 2011 11:11:13 GMT |
|
|
|
Bill McCarth
#12 / 12
|
Early Binding - Late Binding Hi Norm,
Quote: >> Thanks Norm. I found this page which lists other changes: >> http://technet.microsoft.com/en-us/library/cc178954.aspx
>> I also saw the Project API documentation said it was "hidden", but I
>> haven't confirmed that for Office.
> Bill,
> That list is funny in that they say FileSearch was not used by most users,
> but it was used a lot by anyone automating word or excel. What it broke in
> my application was when I made reference to the Word object and then tried
> to use FileSearch with the object.
> When I was searching for another way of working with searchs through Word
> documents I ran into a lot of people that were having problems with the
> automation routines.
I wouldn't call that funny, more peculiar ;) That's certainly no reason to remove it. I think the real reason is more akin to what the rest of the statement hints at in that there are better ways to search. Even still that's not a reason to remove it, they should instead include a flag to say use the desktop search or whatever if it is there. Given the sheer size of Office, and the amount of change they made in the UI and document formats (xdoc etc), it's really amazing to see how little is broken. FileSearch would seem relatively trivial for them to have kept, so I think there is more to this.
|
| Sat, 09 Jul 2011 11:28:34 GMT |
|
| |
