Reply
 
LinkBack Thread Tools Search this Thread Display Modes
  #1   Report Post  
Posted to microsoft.public.excel.programming
external usenet poster
 
Posts: 7
Default Pls explain this VBA oddity

I am looking at some VBA code in an effort to help someone. One sub
has the following statements juxtaposed:

foobar = 1234
foobar = 1234

First, what sense could there be in assigning the value twice? Does
VBA have a concept of event variables, such that each assignment
triggers an event? (Just a wild guess.)

Second, "foobar" is never used on the right-hand side of any statement
within the sub. I have done a "find" on the entire project, and I
cannot find any declaration of a global scope.

Is there some other way that I can determine where and how "foobar" is
declared?

PS: This VBA code seems to be developed by a professional. So I
doubt that the code is as purposeless as it appears.

TIA for any insights.
  #2   Report Post  
Posted to microsoft.public.excel.programming
external usenet poster
 
Posts: 367
Default Pls explain this VBA oddity

It looks like dummy code.....the author maybe forgot to delete it.

put ' in front of those two lines and check if there are problems.

But in my opinion, without seeing the code, you don't need this
variable.

hth

Carlo

On Dec 18, 4:24 pm, wrote:
I am looking at some VBA code in an effort to help someone. One sub
has the following statements juxtaposed:

foobar = 1234
foobar = 1234

First, what sense could there be in assigning the value twice? Does
VBA have a concept of event variables, such that each assignment
triggers an event? (Just a wild guess.)

Second, "foobar" is never used on the right-hand side of any statement
within the sub. I have done a "find" on the entire project, and I
cannot find any declaration of a global scope.

Is there some other way that I can determine where and how "foobar" is
declared?

PS: This VBA code seems to be developed by a professional. So I
doubt that the code is as purposeless as it appears.

TIA for any insights.


  #3   Report Post  
Posted to microsoft.public.excel.programming
external usenet poster
 
Posts: 7
Default Pls explain this VBA oddity

On Dec 17, 11:38 pm, carlo wrote:
It looks like dummy code.....the author maybe forgot to delete it.


You could be right. There is other code in the project that is
commented out. Hmm, maybe I am wrong about my assumption that the
code is professionally developed.

(The code I am looking was developed some years ago, according to
comments. It is not currently under development.)

put ' in front of those two lines and check if there are problems.


Problem is: I am just looking at the code in VBE. I have not enabled
macros for fear of hidden dangers.

But in my opinion, without seeing the code, you don't need this
variable.


Probably right. But I have one other "wild ass thought" for
consideration.

The code is in a sub. If the sub were called from another VBA
procedure, could the sub access variables that are declared in the
calling procedure(!)?

That would surprise me. But I vaguely some computer language that did
permit that -- kinda like #define's in C. (But of course, references
to #define's merely substitute text; they are not actual calls.)

It's probably a moot point anyway because I cannot find any place
where the "useless" sub is called -- bolstering your theory that the
sub is either vestigial or dummy code. Still curious, though.

Thanks again for any insights.
  #4   Report Post  
Posted to microsoft.public.excel.programming
external usenet poster
 
Posts: 367
Default Pls explain this VBA oddity

as it is a sub it cannot return a value.
And if the Variable is declared inside the sub the scope should be
inside it as well. I don't know if you can get access to that
variable, but i'd say 99% no. I'm not a professional, maybe somebody
else can give you a more satisfying answer to that.

Another thing what makes me think it is dummycode is the name of the
variable "foobar" (http://en.wikipedia.org/wiki/Foobar)
i often use this or similar variablenames for testing an idea. I also
forget them a lot....you don't have by any chance one of my codes,
right?? hehe, just kidding, sorry!

Well, that's my point of view....maybe somebody else will contribute
something as well.

Cheers Carlo


On Dec 18, 4:54 pm, wrote:
On Dec 17, 11:38 pm, carlo wrote:

It looks like dummy code.....the author maybe forgot to delete it.


You could be right. There is other code in the project that is
commented out. Hmm, maybe I am wrong about my assumption that the
code is professionally developed.

(The code I am looking was developed some years ago, according to
comments. It is not currently under development.)

put ' in front of those two lines and check if there are problems.


Problem is: I am just looking at the code in VBE. I have not enabled
macros for fear of hidden dangers.

But in my opinion, without seeing the code, you don't need this
variable.


Probably right. But I have one other "wild ass thought" for
consideration.

The code is in a sub. If the sub were called from another VBA
procedure, could the sub access variables that are declared in the
calling procedure(!)?

That would surprise me. But I vaguely some computer language that did
permit that -- kinda like #define's in C. (But of course, references
to #define's merely substitute text; they are not actual calls.)

It's probably a moot point anyway because I cannot find any place
where the "useless" sub is called -- bolstering your theory that the
sub is either vestigial or dummy code. Still curious, though.

Thanks again for any insights.


  #5   Report Post  
Posted to microsoft.public.excel.programming
external usenet poster
 
Posts: 10,593
Default Pls explain this VBA oddity

If it has been declared, select the variable and then hit Shift-F2. That
will take you to the line where it is declared.

--
---
HTH

Bob


(there's no email, no snail mail, but somewhere should be gmail in my addy)



wrote in message
...
I am looking at some VBA code in an effort to help someone. One sub
has the following statements juxtaposed:

foobar = 1234
foobar = 1234

First, what sense could there be in assigning the value twice? Does
VBA have a concept of event variables, such that each assignment
triggers an event? (Just a wild guess.)

Second, "foobar" is never used on the right-hand side of any statement
within the sub. I have done a "find" on the entire project, and I
cannot find any declaration of a global scope.

Is there some other way that I can determine where and how "foobar" is
declared?

PS: This VBA code seems to be developed by a professional. So I
doubt that the code is as purposeless as it appears.

TIA for any insights.





  #6   Report Post  
Posted to microsoft.public.excel.programming
external usenet poster
 
Posts: 6,582
Default Pls explain this VBA oddity

i often use this or similar variablenames for testing an idea. I also
forget them a lot....


Just because the code may have been "professionally" developed, doesn't mean
the developer didn't do something like this, then forget to clean it up.
Once something works, there is often not time (nor need) to make it more
elegant.

- Jon
-------
Jon Peltier, Microsoft Excel MVP
Tutorials and Custom Solutions
Peltier Technical Services, Inc. - http://PeltierTech.com
_______


"carlo" wrote in message
...
as it is a sub it cannot return a value.
And if the Variable is declared inside the sub the scope should be
inside it as well. I don't know if you can get access to that
variable, but i'd say 99% no. I'm not a professional, maybe somebody
else can give you a more satisfying answer to that.

Another thing what makes me think it is dummycode is the name of the
variable "foobar" (http://en.wikipedia.org/wiki/Foobar)
i often use this or similar variablenames for testing an idea. I also
forget them a lot....you don't have by any chance one of my codes,
right?? hehe, just kidding, sorry!

Well, that's my point of view....maybe somebody else will contribute
something as well.

Cheers Carlo


On Dec 18, 4:54 pm, wrote:
On Dec 17, 11:38 pm, carlo wrote:

It looks like dummy code.....the author maybe forgot to delete it.


You could be right. There is other code in the project that is
commented out. Hmm, maybe I am wrong about my assumption that the
code is professionally developed.

(The code I am looking was developed some years ago, according to
comments. It is not currently under development.)

put ' in front of those two lines and check if there are problems.


Problem is: I am just looking at the code in VBE. I have not enabled
macros for fear of hidden dangers.

But in my opinion, without seeing the code, you don't need this
variable.


Probably right. But I have one other "wild ass thought" for
consideration.

The code is in a sub. If the sub were called from another VBA
procedure, could the sub access variables that are declared in the
calling procedure(!)?

That would surprise me. But I vaguely some computer language that did
permit that -- kinda like #define's in C. (But of course, references
to #define's merely substitute text; they are not actual calls.)

It's probably a moot point anyway because I cannot find any place
where the "useless" sub is called -- bolstering your theory that the
sub is either vestigial or dummy code. Still curious, though.

Thanks again for any insights.




  #7   Report Post  
Posted to microsoft.public.excel.programming
external usenet poster
 
Posts: 7
Default Pls explain this VBA oddity

On Dec 18, 1:32 am, "Bob Phillips" wrote:
If it has been declared, select the variable and then hit Shift-F2. That
will take you to the line where it is declared.


V-e-r-y useful! Thanks. Works for references to user-defined
procedures, too. With is worked for user-defined types. But of
course, there is only one place their declarations can be (that I know
of). Thanks again.
  #8   Report Post  
Posted to microsoft.public.excel.programming
external usenet poster
 
Posts: 7
Default Pls explain this VBA oddity

On Dec 18, 12:13 am, carlo wrote:
if the Variable is declared inside the sub the scope should be
inside it as well. I don't know if you can get access to that
variable, but i'd say 99% no.


Right. Immediately after posting my "fishing" speculation, I realized
that the only instances (that I know of) where a procedure has access
to variables declared in the caller are languages where procedures can
be defined within in the scope of other procedures (e.g. Algol-W).

Oh well, I just trying to give the programmer the benefit of the
doubt, stretching to find some meaning for the code. I'm sure now
that there is none.

Another thing what makes me think it is dummycode is the name of the
variable "foobar"


Sorry, the choice of the name was mine, just for posting purposes. It
bears no relationship to the real name. I had already searched the
Object Browser to no avail.

Thanks again. I think your comments have put the final nail in the
coffin.
  #9   Report Post  
Posted to microsoft.public.excel.programming
external usenet poster
 
Posts: 256
Default Pls explain this VBA oddity

As to why it's there twice, imagine you have a segment of code that
you're editing in a separate window prior to pasting it into the main
module. You started in the main module but decided to separate it out
so as not to confuse what's where.

The first portion of this code segment contains the following
assignment:

foobar = 1234

You paste that into your separate window, finish your editing, and
paste it back to your main module. However, the code you highlight to
replace excludes the original foobar=1234. Therefore you get it
twice.

This happens pretty often for people copying code from newsgroups,
with things such as Option statements.


On Dec 18, 11:47 am, wrote:
On Dec 18, 12:13 am, carlo wrote:

if the Variable is declared inside the sub the scope should be
inside it as well. I don't know if you can get access to that
variable, but i'd say 99% no.


Right. Immediately after posting my "fishing" speculation, I realized
that the only instances (that I know of) where a procedure has access
to variables declared in the caller are languages where procedures can
be defined within in the scope of other procedures (e.g. Algol-W).

Oh well, I just trying to give the programmer the benefit of the
doubt, stretching to find some meaning for the code. I'm sure now
that there is none.

Another thing what makes me think it is dummycode is the name of the
variable "foobar"


Sorry, the choice of the name was mine, just for posting purposes. It
bears no relationship to the real name. I had already searched the
Object Browser to no avail.

Thanks again. I think your comments have put the final nail in the
coffin.


Reply
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules

Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
COUNTIF oddity Phil C Excel Worksheet Functions 1 May 30th 07 09:19 AM
An oddity if not a bug Harlan Grove Excel Worksheet Functions 21 July 17th 06 05:36 PM
Oddity with HSI Mike[_51_] Excel Programming 2 July 14th 06 06:33 PM
Chart oddity Ron P Charts and Charting in Excel 2 February 16th 06 03:05 PM
Another Excel oddity Steve Excel Discussion (Misc queries) 5 January 5th 05 08:50 PM


All times are GMT +1. The time now is 11:51 PM.

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 ExcelBanter.
The comments are property of their posters.
 

About Us

"It's about Microsoft Excel"