Answer these imp questions on vb

[shilpa]

Hi Friends


Can you please give the answers to below questions. Please help others in finding best solutions….





1)What is meant by "Early Binding" and "Late Binding"? Which is better?

2)What is the different between ActiveX EXE and ActiveX DLL in Visual Basic?

[balaji_citcs]

Hi Friends


Can you please give the answers to below questions. Please help others in finding best solutions….





1)What is meant by "Early Binding" and "Late Binding"? Which is better?


2)What is the different between ActiveX EXE and ActiveX DLL in Visual Basic?

[balaji_citcs]

Normal saying both are same.

Activex dll will run in the process space of the called application, so it is called in-process component.

acitvex exe - is out-process component. It runs as different process space from the called application.
------------------------------------------------------------ -----


CAn also refer..............


http://kandkconsulting.tripod.com/VB.../activex_exe_t utorial.htm

[Hemanth_2u]

Early vs. Late Binding Article contributed by Dave Rado There are two ways to use Automation (or OLE Automation) to programmatically control another application. Late binding uses CreateObject to create and instance of the application object, which you can then control. For example, to create a new instance of Excel using late binding: Dim oXL As Object Set oXL = CreateObject("Excel.Application") On the other hand, to manipulate an existing instance of Excel (if Excel is already open) you would use GetObject (regardless whether you're using early or late binding): Dim oXL As Object Set oXL = GetObject(, "Excel.Application") To use early binding, you first need to set a reference in your project to the application you want to manipulate. In the VB Editor of any Office application, or in VB itself, you do this by selecting Tools + References, and selecting the application you want from the list (e.g. “Microsoft Excel 8.0 Object Library”). To create a new instance of Excel using early binding: Dim oXL As Excel.Application Set oXL = New Excel.Application In either case, incidentally, you can first try to get an existing instance of Excel, and if that returns an error, you can create a new instance in your error handler. Advantages of Early Binding Your code will run considerably faster, because it can all be compiled up front. With late binding, the code relating to an application you declared as an object has to, in effect, be compiled as it runs. Because your code can all be compiled up front, debugging is far easier – select Debug + Compile, and the compiler will be able to spot syntax errors which would have been missed had you used late binding. You have full access in your project to intellisense (type a keyword and a dot to get a popup list of properties and methods supported by that keyword, select one to insert it; type a keyword and press F1 to launch the Help topic on that keyword). You have full access to the application's object model via the Object Browser and VBA Help. You have access to the application's built-in constants. For instance, if you are automating Word from Excel, you can use: Dim objWord As Word.Application Set objWord = New Word.Application With objWord .Visible = True .Activate .WindowState = wdWindowStateMaximize .Documents.Open ("c:\temp\temp.doc") End With Furthermore, when you type .WindowState = you'll get a pop-up list of the supported constants, and can simply pick “wdWindowStateMaximize” from the list. If you used late binding, you would need to use: .WindowState = 1 .. and you would need to know (by looking it up in Word's Object Browser) that the value of the constant “wdWindowStateMaximize” happens to be 1. All this makes programming using early binding immeasurably easier than using late binding. Advantages of Late Binding The main advantage is that code which uses late binding is more certain to be version-independent If you set a reference in a Word 97 project to “Microsoft Excel 8.0 Object Library”, then the project will run OK on a machine which has Office 2000 installed. Word 2000 changes the reference on the fly to the “Microsoft Excel 9.0 Object Library”. But as they famously say, YMMV. Problems have been found in certain circumstances. For instance, if you run a Word 97 project containing a reference to the Excel 8.0 object library on a machine with Office 2000 installed, it will run OK, but you may get the occasional “cannot open macro storage” error unless you save the project in Word 2000. If you do save it in Word 2000, the reference will change to the Excel 9.0 object library. So if you use early binding and support a mixed environment, it may be safest to create separate Word 97 and Word 2000 versions of your addins, despite the maintenance overhead. The more references your project contains, the larger the file size and the longer it takes to compile. Some programming environments don't allow you to create references to another application. Summary Personally, as someone who finds programming difficult at the best of times, I would never dream of using late binding – why make life harder for yourself than it has to be? But some programming geniuses prefer to use late binding, because of the peace of mind it gives them regarding version independence – or maybe some of them just enjoy the challenge! <g> But you pays your money and makes your choice ... To those unfortunate souls using programming environments in which you have to use late binding, all I can say is: Look on the bright side – you could have ended up as an Assembly language programmer ...

< =text/>

agentType=navigator.appName
if ((agentType!="Microsoft Internet Explorer")){
{ if( self != top )
parent.footer.location.reload();}}
//-->

[Hemanth_2u]

The biggest difference is where the code runs.



An ActiveX [/B]DLL[/B] runs from the same process space as the application that is
using it. For this reason, it's often called an "in-process" server.



An ActiveX [/B]EXE[/B] is given it's own process space to run in when it's loaded.
That's why it's called an "out-of-process" server.



When running in the VB IDE, you only have one process space to work with so
referencing an out-of-process component is not possible. Since the VB IDE
is single-threaded, you can't have two processes, and therefore, two threads
of execution, running simultaneously.



According to the calling program, both types look the same. There are
various reasons you might prefer one over the other. DLLs typically scale a
little better than EXEs (both in my experience and according to the MS KB).
If an ActiveX [/B]EXE[/B] bombs, it won't bring down your application since it runs
in another process (and of course, YOU'RE trapping for errors so it won't
bring you down with it). If you want to play in MTS's neighborhood, the DLL[/B]
is your only option. If you want to try to so two (or more things)
simultaneously, the ActiveX [/B]EXE[/B] is the "easier" option (not the only one).

[webrsk]

[img]smileys/smiley32.gif[/img]Nice Hemanth Effort

[Hemanth_2u]

Thank Q webrsk

[BINNY]

Hemanth_2u .. .. good information

[Hemanth_2u]

Thank You. Binny