"Jason is probably more qualified to answer the technical questions."
No slight intended.
Ummm Greg, it never even occurred to me to think that. Relax dude. I was simply responding to something in my nerdy way I thought I could comment on. It is more a reflection of my big mouth than anything else. No slight taken...even slightly. I have too high an opinion of you to go there (thinking there was an intended slight). It's all good.
I'm relaxed. Really I'm relaxed!
You're funny guys.
From what I can tell, all of you have great knowledge in this field. Though you may have possibly gathered it from a different background, and some may be more technical than others, I doubt there is any "competition" between you (or intend to show off or to offend others in any way).
I assume that what brought you on this forum is, before anything else, your passion for programming and helping others! It really is great to be able to communicate with experts (as you are) without having to contact some technical hotline with people who first want to collect money before even hearing what your problem is.
Though I understand that beginners' questions (or points of view) may sometimes be frustrating to you, you keep helping us and leading us to the right direction.
So thank you for your help! Keep it that way!
You are welcome. And questions are never really frustrating. What IS frustrating are people who clearly do not know things who refuse to listen, and insist that their incorrect ideas are correct. And insist that we are wrong. Well if you are so sure, why are you even asking. Greg for one has a massive store of practical knowledge - his web site shows that - and it is so weird to see someone blindly ignoring that.
You are doing well, willing to learn with a good attitude. You will do well.
Gerry,
Well said. glencoe appears not only eager to catch his own fish, but to fish well and become a better fisherman! Things are starting to get a little gooey here so I'm going to step out
Greg, I see that you like serving people, but feelings are not to be shown. Sounds like the good old times in the Navy? *Just saying it to show you I did have a quick look at your website! I haven't had time yet to go into much detail, but this certainly is a great resource to use!
Glad you've all worked out the technical details, so I didn't have to come in and explain everything. Hehe.
I'm pretty self-taught as well, and I'm always learning things from others. For example: I didn't know that integers get converted to longs by VBA. Thanks, Fumei!
I would also guess that modifying the property of a range object (.Start = .End) is going to be exactly the same performance as use of the .Collapse method, and which to use is probably more preference of coding style... BUT -- you never really know. The thing about optimizing code for actual performance is that some actual bottlenecks in the processing of code will surprise you. But changing from use of Selection to Range is a huge benefit on performance by any measure, and should always be attempted at the outset.
But here's an example of a "waste" of performance optimization energy:
If Len(strText) = 0 Then
vs
If strText = "" Then
*Technically* -- testing the length of a string uses less processing power than checking the content of a string... but unless you were doing thousands upon thousands operations, the noticeable gain in performance will be significantly less (to me) than the obsfucation of code involving a string using a number value vs just checking to see if that string is blank or not. It also prevents easily converting to other logic structures (like a Select Case statement) without additional hoops to jump through. But if you were really really used to seeing that Len(strText) = 0, it would be both an optimization increase with no downside.
The lesson? Don't do granular performance optimization until you're at the stage of "polishing the cannonball" -- try to write your code as easily-readable as possible, and then find out where the bottlenecks are later.
This has been an enjoyable thread to participate in-- thanks for bringing such a good attitude, glencode.
- Jason aka Frosty
ha ha, "glencode"! That's a good one! My nickname is "glencoe" (after some great place in the Scottish Highlands), but I appreciate the joke, even if it was not made on purpose! ;-)
As for finding out what's the best code, I'm not sure how VBA works "behind the scene". I remember when I learnt a bit of C/C++ and Assembler (a while ago, don't ask me anything now, I forgot all of it), we were taught that each line of C is converted in Assembler, and therefore, one function in C will give more or less Assembler lines (*or something like that*), i.e. simple move/add operations.
Anyway, I only mean to say that it is not an easy task to guess which code will perform faster for the same result. It's a bit like picking up one solution among all the suggestions you guys gave me for my issue! All your codes looked great. Assuming they gave the *same* result (with some minor changes), which one would be the fastest? Hard to say. We may assume that a shorter line or a shorter number of lines may be processed faster, but as you pointed it out, it may not always be the case...
Also considering that PCs are always faster, bottlenecks may not bother some users as much as before (though that's not a reason to produce a low quality code).
I was also told once that it may be more efficient to code everything in a single routine rather than using many subroutines/functions with extra arguments. You guys said otherwise and I'm happy with that, since optimizing code is not just finding ways to use more efficient functions, but also writing the code cleverly.
I assume that it is better to call one routine 10 times rather than write it 10 times within the same project...
Daniel (glencoe)
Hmmmm. I wonder about that person's background. I would strongly disagree with that. If efficient covers all aspects of writing code (including debugging), then it is an absurd statement.I was also told once that it may be more efficient to code everything in a single routine rather than using many subroutines/functions with extra arguments. You guys said otherwise and I'm happy with that, since optimizing code is not just finding ways to use more efficient functions, but also writing the code cleverly.
I assume that it is better to call one routine 10 times rather than write it 10 times within the same project...
I would agree with Jason. Do not sweat micromanaging tiny efficiencies. As a personal opinion, if you can work out using Ranges and the use of objects, those two things alone will improve the efficiency by multiple orders of magnitude. Oh, and two other things: Scope and the best methods for code routing and execution (e.g. when to use things like Select Case).
I got your point!
As for scope, I assume you talk about global/public or local declarations?
Yes.
Speaking of frustrating...
There was a guy who posted code where the value of variable did not persist where he thought it should. We pointed out that it has fallen out of Scope. He would not believe that was the reason and went on and on that we were deliberately trying to keep something from him. Why aren't we telling him the real reason, telling him instead about some minor problem that could not possibly be the reason. He kept on insisting there was a "bug" in Word. He would not admit that a) he did not understand Scope; and b) he could possibly make such a newbie error. After all, didn't we know...he was an IT professional. maybe dude, but that does not mean you know crap.
Well, I'm glad I'm NOT an IT professional! :-p Though this would still be stupid, such an error from me would not be as bad! ;-)
If you notice an out-of-scope error from me, ask me to watch the variable through the debugging process, it should be a good hint! ;-)
Reply With Quote
