OCX & Efficency

[CrAz3D]

Would using an ActiveX control for purposes such as CleanSlateBot be efficent to most bot standards?  Would it slow things?  Would it use less memory?

Any input apreciated.

[Stealth]

I don't think there would be any noticeable difference. Your computer thinks very fast.

[SNiFFeR]

Your computer thinks very fast.

Mine doesn't .

[CrAz3D]

Neither did my old one, but ASSUMABLY most people have upgraded their computers before I did.  My '96 IBM lasted 8yrs, & my mom still uses it.

[Eli_1]

Neither did my old one, but ASSUMABLY most people have upgraded their computers before I did.  My '96 IBM lasted 8yrs, & my mom still uses it.

Me and my Tandy 2000 "r0x0r y0r b0x0rs".  

[Noodlez]

In the little picture, OCX's are fine, in the big picture, they are not.

[Grok]

In the little picture, OCX's are fine, in the big picture, they are not.

What does that mean?

[Noodlez]

What I meant to say was that for projects that don't mean anything they are fine, but ones that are going to be running on tons of different systems and get stressed out they aren't. Now that I think about it, my initial remark was poorly thought through and is incorrect.

For a projects such as a bot, that will not be heavily distributed and installing OCX's is a mere inconvenience, they are fine. When optimum execution speeds are required, they are not.

I try to avoid using OCX's as much as possible, due to the fact that they bloat the filesize of my tiny little programs, and increase execution time. I strive for smallest file size + least memory usage and fastest executing code, however, I'm only writing small little programs that are irrelavant to anyone but me.  

[Grok]

I disagree with your reasoning.  The justification you give for not using OCXs on projects which will run on many (tons?) systems does not support your conclusion.

An OCX is a code component, a wrapper for a library, that happens to include zero or more behaviorally-determined graphical interfaces (controls).  An OCX compiled in VB6 supports more COM interfaces than your standard COM DLL compiled by VB6.  Other than this, there is not much difference between an OCX and a DLL.

Whether to use COM, or not, is not so much a distribution issue as it is a speed issue.  Even as a speed issue, it is more important and beneficial to talk about whether you are doing in-process or out-of-process, whether you are remoting or not (DCOM), the number and types of interfaces in use such as callbacks, and most importantly, good design and architecture of the code itself.

In my view of Windows graphical application programming, on which I make my living, if I can write a good DLL or OCX, my bank account is rewarded 20 times over during the next couple years.  A useful OCX will find its way into project after project, and you'll rarely have to touch it again.  It's self-describing interface makes it simple to code against by reminding you of its abilities, assuming you used well-named your functions properties and parameters.

[iago]

ASSUMABLY?

Anyway, if you're concerned about efficently, don't use Visual Basic.  Or Java, for that matter.  But if you're already using VB, I couldn't see an ocx being any worse than any other function call.

[Grok]

Anyway, if you're concerned about efficently, don't use Visual Basic.

Why not?  I think VB makes for very efficient programming.

[iago]

Anyway, if you're concerned about efficently, don't use Visual Basic.

Why not?  I think VB makes for very efficient programming.

If you write the same program in C++ and VB and Java, C++ will have clearly the better performance.  Unless you mean personal efficiency, in which case VB wins, but I'm talking about overall performance.

[Grok]

I think you have to require a pretty narrow definition of performance to say that C++ has more performance overall.  There's way more to application development than coding and debugging, which should be at worst a fifth of your time.

[Adron]

I think you have to require a pretty narrow definition of performance to say that C++ has more performance overall.  There's way more to application development than coding and debugging, which should be at worst a fifth of your time.

This confuses me. Why would your time other than coding and debugging be affected much by your choice of language?

And why would the performance of the resulting application not be possible to make better or as good with C++, considering VB is most likely written in C++, i.e. using VB to do something is a subset of using C++ - in the worst case you'll have Microsoft give you the C++ sources for VB, compile your VB, and then write your app there.

[iago]

In terms of efficiency, I'm talking about:

Would it slow things?  Would it use less memory?

And I'm saying that, compared to other vb programs, no.  Compared to C++, yes, but as long as you're using an interpreted language you have to make sacrifices.