Late binding, anyone?

[Former Member]

I have a small app that generates Excel and PowerPoint documents. In order to become more version independent I turned from early to late binding.

Early binding: Dim XLApp as Excel.Application

Late binding: Dim XLApp as Object

As there are many SBO versions and patch levels out there, and more in the pipeline, I decided to give a shot and turn SBO DIAPI and UIAPI to late binding, too.

Everything went quite OK (I hope): it seems that I can run the same .exe on any SBO version. Just installed SBO2005 Pre Eval, faced no major problems (the SBO functionality I have coded is quite basic).

There seems to be some issues that I can live with

- some properties are not available (IDispach -problems)

- SBO events can not be hooked at all

My questions are

1. Do you use late binding?

2. What issues you have faced?

3. What work-arounds / practices you use in order to deal with issues?

Any information & comments on this will be highly appreciated.

Thanks in advance

Juha

[Former Member · Accepted solution]

Hi Juha,

why should you use late binding when you can use early binding? Ealy binding is faster and safer. Late binding will not give you any advantage concerning newer versions of SBO. If a method or property does not exist when called, you will get an error anyway. With early binding you get the error at design time, with late binding you (or your customer) will get it at runtime.

I prefer the design time one.

HTH

Lutz Morrien

<b>Quote (Microsoft):</b>

<i>If possible you should attempt to early bind...

Early binding not only increases performance, but you get syntax and type checking at compile-time. If you can't early bind you must use late binding, which is slower and doesn't allow you to catch simple errors (such as type mismatches) until run time.

Early binding should be used whenever possible. However, there are programming situations in which late binding is preferred. If you are implementing polymorphic code (one call can represent multiple different objects), then late binding is required. For example, you can create three classes widgets, gidgets, and gadgets all with a Create method. By defining your variable as an object, you can call the Create method for any of the three classes based on run-time conditions.</i>

<b>Another quote:</b>

<i>Early binding allows developers to interact with the object’s properties and methods during coding. You can enjoy the benefits of intellisense. Also, early binding permits the compiler to check your code. Errors are caught at compile time. Early binding also results in faster code. It’s disadvantage is that you cannot create a generic object which may be bound to different types of objects.

Late binding on the other hand permits defining generic objects which may be bound to different objects. Eg you could declare myControl as Control without knowing which control you will encounter. You could then query the Controls collection and determine which control you are working on using the TypeOf method and branch to the section of your code that provides for that type. This is the only benefit of late binding. It’s disadvantages are that it is error prone and you will not enjoy much intellisense whilst coding.</i>

Message was edited by: Lutz Morrien

[Former Member · Accepted solution]

Yes, coding-wise I prefer early binding, too.

My assumption is that if I am early binding, then I am more dependent on specific versions of COM objects. Not sure about this, though. The question that I don't have a full answer to is that if I code with early binding then how to deploy the app so that it works on any SBO version?

Quote (Microsoft):Late binding in this fashion has the advantage of removing some of the version dependencies that are inherent with early binding.

Regards,

Juha

Message was edited by: Juha Lassila

[Former Member · Accepted solution]

Hi Juha,

I think the only way of creating an addon which works with several versions is to only use methods, objects and properties which are included in all versions. Hence you will end up not using the newer ones, since they are not included. (And your customer will not get the latest shiny bits of SAP technology)

I doubt that late binding can change this matter. Also, there are other changes which do not have anything to do with binding at all. Take the changes in addon installation procedure for one. You need to implement these changes to get your addon up an running.

The intention of a universal addon is good and the goal is clear, but I think there is no way around coding several versions of addons for several versions of SBO.

HTH Lutz Morrien

[Former Member · Accepted solution]

I may be a bit paranoid here, but if I use late binding then I can avoid deploying pieces made by others (say Microsoft & SAP). My current perception is that this way I get at least 2 benefits:

1. Intellectual property point of view: I'm not distributing pieces made by others => I am not breaching license agreements => I don't have think about this issue at all.

2. Support point of view: The less pieces I distribute with my app the less if issues I will meet in the case that some of the pieces go out of sync or override the setup in target PCs. Result: less finger-pointing to my direction.

I totally agree with you on the downside of late binding. However, the amount of pain may stay under control with appropriate coding, development and testing practices.

I can live with the pain and without the shiny bits of newest versions. The app is quite mature and is based on core stuff that I expect to be around for long. Anyway, I would like to see one old bug in SBO to be fixed immediately: Combobox.Select doesn't work in non-English UI:

Thanks for your cool comments, Lutz.

The temperature here is almost 30, and rising. Therefore, I would like to see more comments on real or perceived benefits/downsides of late binding.

Regards,

Juha

[Former Member]

Juha,

Actually , what you are talking about is not late binding vs early binding but strong typing vs loose typing.

Late binding is about the fact that you use CreateObject as opposed to NEW.

You can use strong typping in combination with late binding. Strong typing has the advantage that you still can use IntelliSence.

With Excel, yes, do use late binding. It comes in very handy because excel sort of guarantees that downward compatibilty will be maintained. B1 however is kind of a different story.

If strong typing and early binding doesn't work towards a newer B1 version I'ld prefer my AddOn's to crash instead of doing something I do not wish them to do. You are working with an important piece in the administrative chain of your organisation and that is not something you should take lightly!!