Sub Routine arrays

[AdamWhitehouse]

This is probably easy to some of you out there? I am trying to call sub routines from an array, but can not seem to manage it, ie:

dim count(50)
dim i

count=count+1
call step(count)

Private sub count(1)
end sub

private sub count(2)
end sub

etc: This obviously doesn't work, but is there a way of acheiving this, any help enthusiastically appreciated.

Adam

 

[Guest_imported]

Hay Adam!
I'm not sure that I understand it right, but try to do this:

dim count=50
dim i
for i=0 to count
i=i+1
call count & i
next
Private sub count1()
end sub

private sub count2()
end sub
, or explane what is step(count) and whre from do you call count subs!

 

[AdamWhitehouse]

palnd (Visitor)

Sorry about the syntax of my coding, what I am trying to achieve is to be able to call upto 70 procedures from one or two lines of code, the procedures are labelled as:
step1()
step2()
I
I
step70()

I am trying to call these from a single line of code such as 'call step & i' where I can increment the variable I to the required step level, this obviously doesn't work because VB will not let me call a variable or have a proceudre with a variable name.

Adam

 

[chiph]

You can do a On..Goto statement, which will jump to different labels in your code depending on the value of a variable.

But, this and other similar statements will not be supported in the next release of VB. What you should do to prepare your code is use a select..case statement. Yes, it's a bit wordy, but it really is more readable.
[tt]
Dim i as integer

for i = 0 to 49
[tab]select case i
[tab]case 0:
[tab][tab]call Sub1()
[tab]case 1:
[tab][tab]call Sub2()
[tab]case 2:
[tab][tab]call Sub3()
[tab]:
[tab]:
[tab]:
[tab]case 49:
[tab][tab]call sub50()
[tab]end select
next i
[/tt]

Notice also that I went from 0 to 49 instead of 1 to 50. That's because starting in VB7, all array indices will start at 0. It wasn't really needed here to do that, but it's a good idea to get into the habit now.

Chip H.

 

[AdamWhitehouse]

Thanks for the reply, it is very similar to how I am addressing the situation at the moment ie:

Do
if i=70 then i = 0
if i=69 then call step69
..
..
if i=1 then call step1
If i=0 then call step0
DoEvents
Loop

but it seemed a long winded way of programming and uses a lot of valuable cycle time, It controls a motion system on a laser welder, and I am 4 seconds over the required, and any I can pull back is a bonus at this stage.

 

[rvBasic]

Remember that the different cases need not be in numerical ascending or decending order. So, if speed is important, then for a large list of items you might consider putting the most frequently expected values at the top of the list.

The disadvantage of this approach is that you easily miss an item (out of the fifty or so) and that program readability is considerably worse. You also will still miss the time target for the items at the bottom of your list (but this may be acceptable). _________________________________
In theory, there is no difference between theory and practice. In practice, there is. [attributed to Yogi Berra]

 

[MichaelRed]

If sped is the issue, the standard approach would be to trash the logic. Just lst the subs in the order you want them called:

Call Sub0()
Call Sub1()
[tab].
[tab].
[tab].
[tab].
Call SubN

I "LOOKS LIKE" this all you are accomplishing anyway, you are just complicating the process with the If statements.

Also, I would loose the do events, as this releases the process to do EVERYTHING the O.S. wants to do while yoiu are in the critical timing area.

Basic approach to timing critical issues:
DO NOT use logic (ESPECIALLY THE IF ... )
DO NOT Release the Processor to the O.S. (DoEvents et al)
Avoid loops
Aviod conditional Loops even more (They ALWAYS include conditionals)
AVIOD updating the monitor (this is at least as bad as the Release of the processor/O.S.)



MichaelRed
mred@duvallgroup.com
There is never time to do it right but there is always time to do it over