Solved: Call?

[mvidas]

Hi Everyone,

I'm looking to get some opinions on the use of Call. Does anyone use it?
I see 2 benefits to using it, neither of which are of much importance to me, but I'm thinking others might disagree. The two things I can think of:
-A way of reminding future code editors that you're referring to a coded procedure rather than inherent procedure
-A way of reminding future code editors that there is no return value of the procedure being called

Just curious
Matt

[Ken Puls]

Matt,

I ALWAYS use call. It makes it obvious that you're going to another procedure. The code becomes a little more self documenting.

I always make an effort to make sure that the code is documented so that others can maintain it in future. One day I won't be here, and to me it's something about being a professional.

Just my 2 cents.

[mvidas]

But as far as speed, theres no difference (even a ver y slight one)?

[Ken Puls]

Honestly, Matt, I've never tested it.

My understanding is that the call word is optional, as it is implied. Much like Activesheet is implied when you ask for a Range object. I still code Activesheet.Range, and also use call. It changes the syntax a bit, but that's it:

[vba]Call MyMacro(arg1)
'vs
MyMacro arg1[/vba]

I'd be surprised to find any diference in execution speed worth talking about, to be honest.

[mvidas]

I feel the same way (and I doubt any difference would be noticed, even iterating thousands of times).

As I only qualify things when absolutely necessary (or are writing for someone who knows next to nothing), and rarely comment, I'll stick to not using Call.
I never said I was a good programmer

Thanks

[Ken Puls]

LOL!

I never said that I was a good programmer either, but I tend to work completely opposite to the way you do. I try to be very explicit in my coding (Option Explicit is more than just some keywords to me).

For example I (almost) always:
-Set a reference to Activesheet (and use it with If blocks)
-Set references to all workbooks if I'm using more than one
-Use Call statements
-Declare my variables with non-Variant types

I'm also trying to get into the habit of passing variants ByRef and ByVal to other functions.

[Bob Phillips]

I tend to side with ken on these particular style aspects.

I also use Call all of the time, eveb for non-returning functions (in fact I often just use functions), mainly so that a control break out of this procedure is immediately identifiable, and also so that parameters are always conatined in parentheses.

My particular stylistics include:
- setting references to objects as much as I can
- extensive use of With ... End With
- NEVER use default properties
- use Call
- (mainly) use Function instead of Sub
- NEVER use shortcut notation
- keep procedurse short
- always decalre variables, even variant types
- keep comments short

and so on.

[mvidas]

I will frequently use With blocks to refer to an object (if I don't have a variable for it) like Activesheet in case that needs to be changed, but at what point do you stop?
Range("A1")
ActiveSheet.Range("A1")
ActiveWorkbook.ActiveSheet.Range("A1")
Application.ActiveWorkbook.ActiveSheet.Range("A1")

I do (almost) always declare my variables with non-variant types, generally unless it is notepad (for vbs) or unless it should be a variant, you'll rarely find me use one.
I got used to the byval/byref (at least in the procedure declaration, not while calling) a while ago when I learned the difference.

And I still don't have the option set to put "option explicit" everywhere. I usually hand-type it in, but not even always.

I guess since I don't get paid to program, I think it is ok to sometimes have poor programming practices as long as it doesnt crash something and it works fast.

[Bob Phillips]

I will frequently use With blocks to refer to an object (if I don't have a variable for it) like Activesheet in case that needs to be changed, but at what point do you stop?

Use object variables and it is much simpler.

Range("A1")
ActiveSheet.Range("A1")
ActiveWorkbook.ActiveSheet.Range("A1")
Application.ActiveWorkbook.ActiveSheet.Range("A1")

4 examples of one of my absolute no-nos!

[mvidas]

Perhaps I should un-solve this thread, I'm liking these responses. And maybe change the title to "programming practices"

I tend to side with ken on these particular style aspects.

I also use Call all of the time, eveb for non-returning functions (in fact I often just use functions), mainly so that a control break out of this procedure is immediately identifiable, and also so that parameters are always conatined in parentheses.

My particular stylistics include:
- setting references to objects as much as I can
- extensive use of With ... End With
- NEVER use default properties
- use Call
- (mainly) use Function instead of Sub
- NEVER use shortcut notation
- keep procedurse short
- always decalre variables, even variant types
- keep comments short

I almost always use functions as well (at least while coding for myself) and only use Subs for entry points (less choices of what to choose..).
I do occasionally use default properties, though thinking about it now I think the only one I use is a cell's .value property (maybe 50/50 chance of me using it)

I try not to use shortcut notation (I'm assuming you're referring to the evaluate shortcut?), I can probably count on one hand the number of times ive used it in the past year.

I can't keep comments short when I use them, I'm waaay too verbose for that. Probably why I don't comment much (I know I should)

I guess just a confirmation question regarding creating objects and with blocks.. is method 2 any better (memory-wise) than method 1 here? just a simple example:
[vba]'1
With CreateObject("wscript.shell")
.Popup "hi", 1
End With

'2
Dim WSHell As Object
Set WSHell = CreateObject("wscript.shell")
WSHell.Popup "hi", 1
Set WSHell = Nothing[/vba]Does the memory get freed when End With is reached?

and so on.

Keep em coming!

[Ken Puls]

...at what point do you stop?
Range("A1")
ActiveSheet.Range("A1")
ActiveWorkbook.ActiveSheet.Range("A1")
Application.ActiveWorkbook.ActiveSheet.Range("A1")

If all I'm doing is working on the Activsheet and will not change it, I'll go with ActiveSheet.Range("A1"). Any deeper than that, or if I will need to change the sheet at any point, I set a reference to an object.

And I still don't have the option set to put "option explicit" everywhere. I usually hand-type it in, but not even always.

I guess since I don't get paid to program, I think it is ok to sometimes have poor programming practices as long as it doesnt crash something and it works fast.

I completely disagree. While you are not being paid to program, per se, you are being paid by your employer, and you are programming. I personally try to make all my stuff stand up for long after I'm gone, as I don't want a bad reputation to follow me anywhere.

[mvidas]

4 examples of one of my absolute no-nos!

I've noticed myself having variables for a lot more things since I made my first com add-in, but for setting a cell, would you always have a worksheet variable in something like:[vba]set cll = ws.range("A1")[/vba]? What if it is for a function to always interact with the activesheet, do you create a variable for the activesheet?

Say for example this, which is one of the few procedures I have assigned to a keyboard shortcut:[vba]Sub insRow()
Selection.EntireRow.Insert
End Sub[/vba]It never fails me, but as far as good programming practice goes, how would you code that instead?

One of my friends on EE at one point told me the last 4 letters of my username stood for "I Despise Active Sheet", since I almost never use that keyword.

[mvidas]

I completely disagree. While you are not being paid to program, per se, you are being paid by your employer, and you are programming. I personally try to make all my stuff stand up for long after I'm gone, as I don't want a bad reputation to follow me anywhere.

True, but most of the programming I do here is not work related, more for increasing knowledge (while helping on the forums). The few things I have here that are for other people are well made and documented; I really only make that kind of thing on request. I am trying to convert my procedures that I know inside-and-out to a form that a future coder would understand, but as my job in no way calls for anyone who even knows what a programming language is, it isn't entirely necessary. I'm really only doing it now so that when I'm done with it (after extensive testing) I can tell my boss "I'm leaving, but heres a program to do my work for me"

[Bob Phillips]

I try not to use shortcut notation (I'm assuming you're referring to the evaluate shortcut?)

Yeah, that is what I mean.

I can't keep comments short when I use them, I'm waaay too verbose for that. Probably why I don't comment much (I know I should)

The problem with verbose comments is two-fold:
- if they are tool long, it probably also means they are probably not succinct or clear, so people will get bored and ignore them
- if they are too long, it probably means the code is not clear enough, therefore is bad code

I guess just a confirmation question regarding creating objects and with blocks.. is method 2 any better (memory-wise) than method 1 here? just a simple example:
[vba]'1
With CreateObject("wscript.shell")
.Popup "hi", 1
End With

'2
Dim WSHell As Object
Set WSHell = CreateObject("wscript.shell")
WSHell.Popup "hi", 1
Set WSHell = Nothing[/vba]Does the memory get freed when End With is reached?

I wouldn't use method 1 personally, if it doesn't refer to at least two objects, it doesn't become more readable (less so IMO), and the overhead isn't warranted.

As to memory, With creates an implicit object variable, but one that you cannot explicitly release. It doesn't get released at the End With, buts should at the end of the sub. Howevere, if you don't trust VBA's garbage collection handler, then you might think you have a problem. I have heard some claim that they cannot kill instances of Excel because of these implied objects, never come across it myself.

[Bob Phillips]

I've noticed myself having variables for a lot more things since I made my first com add-in, but for setting a cell, would you always have a worksheet variable in something like:[vba]set cll = ws.range("A1")[/vba]? What if it is for a function to always interact with the activesheet, do you create a variable for the activesheet?

That wasn't my no-no. I meant

[vba]

Range("A1")
[/vba]

instead of

[vba]
Range("A1").Value
[/vba]

Personally, I rarely set a range object, unless I will use it later in the code, or it is a variable cell.

Say for example this, which is one of the few procedures I have assigned to a keyboard shortcut:[vba]Sub insRow()
Selection.EntireRow.Insert
End Sub[/vba]It never fails me, but as far as good programming practice goes, how would you code that instead?[/vba]

I wouldn't!

There are 6 commands in the toolbar commands for inserting/deleting cells/rows/columns,, so I have a custom toolbar with tjose 6 on (besides others).

[Bob Phillips]

I'm really only doing it now so that when I'm done with it (after extensive testing) I can tell my boss "I'm leaving, but heres a program to do my work for me"

You wa nt tgo be careful that he doesn't find out, and decide that your program canj do your work NOW.

[mvidas]

There are 6 commands in the toolbar commands for inserting/deleting cells/rows/columns,, so I have a custom toolbar with tjose 6 on (besides others).

I did often use the right-click key (I don't know the real name for it), and then 'I' or 'I-R' or 'I-C', the above just makes it easier for me for one of my sheets (I try to not use the mouse when possible). The only other macro with a keyboard shortcut I have (the only other excel related macro I use more than once a month) is one to rename the active sheet (easier than alt-o-h-r for me)

You wa nt tgo be careful that he doesn't find out, and decide that your program canj do your work NOW.

Actually my bosses know I use scripts to get my stuff done, but they do like that. The person who did my job before me did everything manually, and a months worth of work for her is a few hours for me (with everything extra that they've given me after people left it is at about a week now). They know I spend a lot of my time 'practicing' and fine-tuning what I do. I'm about a month or two from getting most of my job automated now, unfortunately the programmer working my request is slow.
Ever used powerbuilder? want a job?

[mvidas]

As to memory, With creates an implicit object variable, but one that you cannot explicitly release. It doesn't get released at the End With, buts should at the end of the sub. Howevere, if you don't trust VBA's garbage collection handler, then you might think you have a problem. I have heard some claim that they cannot kill instances of Excel because of these implied objects, never come across it myself.

Interesting.. I didn't think the memory would be freed until after the sub was finished, but I thought it was possible it was set to nothing after the End With. I don't think I've ever done it like that ('think' being the key word), and now I won't

[Bob Phillips]

Ever used powerbuilder? want a job?

Used PowerBuilder, but that was some years ago, just before theyt brought out their web-enabled version.

[malik641]

[vba]Sub insRow()
Selection.EntireRow.Insert
End Sub[/vba]It never fails me, but as far as good programming practice goes, how would you code that instead?

I would do one of two things different with this (both for the same reason)...

[vba]Sub insRow()
On Error Resume Next
Selection.EntireRow.Insert
End Sub[/vba]-Or-[vba]Sub insRow()
If TypeName(Selection) <> "Range" Then Exit Sub
Selection.EntireRow.Insert
End Sub[/vba] Only because if you have an OLE object on your worksheet, and it's selected...then that object becomes "Selection", and you get an error

As far as using call, I always use call. And I, too, have been recently using ByRef and ByVal and getting into a habbit with that.

I try to make each procedure as short as possible, and (more recently) break up my code into Functions/Subs that are called on to do something common that I think I'll have the chance of calling in a future procedure (although I should have been doing this a while ago...) ...I've learned recently how much nicer everthing looks with less code in a main sub procedure, especially when everything's commented properly (using Bob's standards).