Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations John Tel on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Goto Variable 2

Status
Not open for further replies.

TLowder

Programmer
Mar 20, 2002
224
Is is possible to use goto with a variable?

It probably just isn't possible in the same way you can't refer to forms and controls directly as variables.

For example -
Code:
Dim x as integer

x = (retrieve some value - 1,2,3 etc.)

goto x

1..

2..

3..

Without having to doing this -
Code:
Dim x as integer

x = (retrieve some value - 1,2,3 etc.)

select case x

case 1
 goto 1
case 2
 goto 2
case 3
 goto 3

end select
1..

2..

3..

Thanks,


Tom
 
I don't know what exactly you are doing so I don't want to sound like I am questioning your logic but why not just use a select case with a function called from each case. Something like this:
Code:
Private Sub Control()
    Select Case iX
        Case 1
            One
        Case 2
            Two
        Case 3
            Three
    End Select
End Sub

Private Sub One()
    'code
End Sub

Private Sub Two()
    'code
End Sub

Private Sub Three()
    'code
End Sub


If you choose to battle wits with the witless be prepared to lose.

[cheers]
 
Foada - Thanks, but thats what I'm trying to avoid as shown in my second example described "Without having to do this". Regardless of calling lines or functions, with using select case I'll end up with a long list as it's not just 1,2 & 3. It's not a big deal, but I just wanted to avoid it if possible and make the code more efficient and shorter. Like I said, I don't think its possible, but just wanted ask others to know for sure.

Tom
 
In this case I don't think you can simplify it. Here is another possible way.

Code:
Dim x as integer

x = (retrieve some value - 1,2,3 etc.)
ZZ(x)

sub ZZ(pValue as integer)
   Select case pValue
      Case 1

      case 2
...
end sub

I would suggest using this example or Foada's example as the code is cleaner (and easier to follow) than your example. The more options that are in a routine, the more complex it becomes. Procedures should be kept to a minimum and only do what is necessary. When it becomes to combersome, the code should be broken up into smaller procedures.
 
Thanks, I use the lines because it is an update procedure. I keep track of which database version they are on then start at that line of code and go through the rest from there so version 20 runs 20+, version 30 runs through 30+ etc. In other words an end function is not what I want. The lines also serve markers to record the last line # in the update. The database update itself is error handled if table/ field already exists so DB version isn't entirely necessary and it doesn't hurt to run through the whole procedure. But there are also other msgbox's on what has changed, new features/reports to setup or discuss with client, etc. I have reports at the end of the update showing what has changed. I don't like to repeat through this if they have already had that part of the update, while at the same time I leave them in the procedure for those who haven't yet had the update.

Tom
 
Showing my age, in VIC20 basic you could say
Code:
On X Goto 100, 200, 300, 400
which would Goto line 100, 200 etc depending on X being 1, 2, 3 etc. And the good news is, it works in VB6 too! You'll get an error if the line numbers you're going to don't exist though.

- Andy
___________________________________________________________________
If you think nobody cares you're alive, try missing a couple of mortgage payments
 
Thanks Andy,

Looks like it's going to be as short as it can get. It's a shame there isn't something like cLiteral(variable) - if that makes sense.

The same would be nice for forms too. I have some forms that are created from an original and loaded with different graphical buttons based on end user values, including the form name, that vary from client to client. It would save me some coding if I could refer to them directly as variables too. I'm going to be rewriting that section of code very soon and changing some logic. Right now I have a dozen or so predifined common names that they can use but I am going to make it fully user customizable. I'll probably have to do an array of forms and set the tag to the user name so I know which is which when reshowing the form. And that isn't as clean as I'd like, as I have to loop through the array reading the tag values, show if found or load new if not found. Where (FormVariable).show would be nice and simple.

Anyway neither of these issues are a big deal, just an annoyance.

Thanks,

Tom
 
You might be able to simplify your code like this:
Code:
Dim FormObj As Object
Select Case X
  Case 1: Set FormObj = Form1
  Case 2: Set FormObj = Form2
  Case 3: Set FormObj = Form3
End Select
FormObj.Show 1

- Andy
___________________________________________________________________
If you think nobody cares you're alive, try missing a couple of mortgage payments
 
Thanks, I probably won't be changing that part of the code till next week. I'll take a look at it then.

Tom
 
>including the form name ... (i)t would save me some coding if I could refer to them directly as variables too

I've shown code in this forum where you can do exactly that ... a keyword search shoud find the posts
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top