Is there any difference about speed, stability, threading behavior or other "hardcore stuff" if I compile a User Contol into an OCX or if I embeded a User Control into my EXE project?
Printable View
Is there any difference about speed, stability, threading behavior or other "hardcore stuff" if I compile a User Contol into an OCX or if I embeded a User Control into my EXE project?
I think an ocx that is a stand-alone ocx rather than being built-in to your program will execute faster than if it were built-in. That is being the stand-alone ocx would only have to do what its functions require and not have to wait for other code to start and finish before it can start/stop.
Thanks 4 you answer
Still waiting for detail info... anyone??
Controls compiled separately involve some additional creation and call overhead compared to those compiled inline in the client. As far as I know they will never be "faster" to use in any meaningful way. There is even more overhead for controls from an out-of-process library (ActiveX EXE). Another "dimension" of overhead is whether early or late binding is used.
Compiling internal classes, controls, and forms isn't "embedding" in any technical Windows sense of the term such as OLE. Call overhead is about the same as calls into static (BAS) modules once an instance has been loaded.
Threading won't be significant when using in-process libraries created in VB6, but various threading models are available out-of-process.
I have no clue what "stability" means in this context, perhaps you could explain this.
The main advantages of separate compilation to create libraries are (a.) sharing by multiple applications, (b.) separate servicing (updating), and (c.) managing development in smaller chunks. They can also aid in test-driven development and of course out-of-process libraries offer additional benefits of their own such as running in a separate machine from the client.
Moved To General Developer
Also, I reckon standalone is better if at some stage you need to share the functionality with another developer or two. If not an embedded ocx would be better.
dilettante :
yes, "embedding" is not a correct word. What I mean is my User Control compiled along with my (standard) EXE, I just can't find a proper word for that :)
Threading.. if I use such intensive work in the user control (manipulating image), isn't it the process in the EXE app will be queued until that work is done? (like Nightwalker83 state above?
stability... just forget about it, I don't know how to desribe it :D
So.. if I'm gonna use this User Control for this App only (all the sharing advantages thing not considered), it is better to have the Control bundled into the EXE?
If you think you really need multithreading then you don't have a lot of choice except to use an ActiveX EXE. Your OCX code written in VB6 is limited to running on the UI thread of your application just like any logic you write in your main EXE.
One way we get around this is to use OCXs written in C++ which can have worker threads. But if you are trying to do everything in VB6 that isn't an option.
Most of the time when you think you need multithreading you don't. When you do your problem may not be well suited to VB6. When you must anyway, then either an ActiveX EXE or a worker process (separate program) are about the only reliable choices.
Ther are also some 3rd party libraries to help you have VB6 threads but they are not widely used and take time and study to understand. For example look at the Advanced COM topics at http://www.newobjects.com/pages/ndl/ which describes the free ActiveX Pack1. This can be used for threading (and lots of other stuff) in either VBScript or VB 5 & 6.
If I recall, from the old VB6 days, there's no perceivable difference in speed/performance, etc. Basically, test it for yourself, based on what you are going to do on the control.
The disadvantage of an external file (OCX) is the registration requirement. the disadvantage of 'embedded' is the inability to modify just the control, and a larger executable (not that that means much these days).
AXPack1 is a gem of an ActiveX controls that I have ever used.Quote:
Originally Posted by dilettante