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.
I don't think there would be any noticeable difference. Your computer thinks very fast.
Quote from: Stealth on April 04, 2004, 11:03 PM
Your computer thinks very fast.
Mine doesn't :(.
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.
Quote from: CrAz3D on April 05, 2004, 07:26 PM
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". :-\
In the little picture, OCX's are fine, in the big picture, they are not.
Quote from: Noodlez on April 05, 2004, 09:15 PM
In the little picture, OCX's are fine, in the big picture, they are not.
What does that mean?
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. :P
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.
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.
Quote from: iago on April 07, 2004, 11:38 AMAnyway, if you're concerned about efficently, don't use Visual Basic.
Why not? I think VB makes for very efficient programming.
Quote from: Grok on April 07, 2004, 12:16 PM
Quote from: iago on April 07, 2004, 11:38 AMAnyway, 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.
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.
Quote from: Grok on April 07, 2004, 01:21 PM
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.
In terms of efficiency, I'm talking about:
Quote from: CrAz3D on April 04, 2004, 10:50 PM
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.
Quote from: Adron on April 07, 2004, 01:45 PM
Quote from: Grok on April 07, 2004, 01:21 PM
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?
Choosing VB has some implications in design and architecture, some of which you cannot escape. VB is almost unique in that by selecting it, you WILL be using Microsoft Windows as your platform. This reduces the number of decisions you have to make from personnal and project management perspectives. It affects debugging, testing, and even deployment, in ways that differ from planning generic, without prior knowledge of the language. So in many ways, selecting VB ahead of time actually makes the entire project more efficient.
QuoteAnd 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.
I have no doubt that the performance of the resulting application could be possible to make as good or better with C++ instead of VB. I suppose I was responding to the term "efficient" from a project management angle, while iago may have meant efficient as in tight code.
I do want to add that the skill level of the programmer probably has more of an impact on the final efficiency of either the VB or the C++ code than the language of choice, assuming an average amount of time and resources are given to each programmer.
With limited time/need for power, Java all the way :)
But yes, me and Grok were taking different definitions of the word "efficient"
Yay, terrible RAM consumption, slow startup time, slow, thread-happy GUI library, and incompatible class file versions! Woohoo!
Quote from: St0rm.iD on April 10, 2004, 09:00 AM
Yay, terrible RAM consumption, slow startup time, slow, thread-happy GUI library, and incompatible class file versions! Woohoo!
Aren't you the same storm that used to hype up Java all the time? What happened? Anyways, I like it. :P