Re: Problem writing code to go to a label after calling a procedure

erewhon@xxxxxxxxxx (J French) wrote:

>On Sun, 27 Nov 2005 14:03:07 +1300, Brian <bclark@xxxxxxxx> wrote:
>
><snip>
>
>>I'm trying to convert a program that was written in Quick Basic to
>>Visual Basic so it will run happily with Windows.
>
>90% of your logic code should be simply cut and paste
>
>>I've drawn flow charts of the ordinal code to try and create a new
>>flow chart that will work will with Visual Basic.
>
>>I now think that it's not possible to restructure the ordinal code as
>>depending on the user input only certain parts of the code are
>>executed each time. There are too many conditions in the program. It
>>would be nice if the program followed the same path each time.
>
>That should not be a problem
>- one main control routine can drive subsidiary procedures
>
>>I first tried to create procedures for parts of the program to avoid
>>many jumps in the program code but then found that the program went
>>deep in following to many procedures.
>
>There is nothing wrong with going deep into procedures
>- the first trick is to separate 'generic' code and App specific code
>into separate areas
>
>- the next is to make sure that as many procedures as possible are
>'Black Boxes' with tightly defined input and output
>
>- one needs to ensure that nothing 'knows' anything about anything
>else unless it absolutely has to
>
>- avoid Global variables like the plague
>- avoid module level variables unless they are essential, generally in
>'normal' routines they are not essential
>
>- make everything 'Private' unless it absolutely has to be 'Public'
>
>- Use: Select Case rather than If .. Then .. Else
>
>>Maybe Visual Basic is not suitable for this type of program.
>
>If you could write it in Quick Basic, then you can transfer it to VB
>with very little trouble
>
>However, from what you have said so far, it sounds as if your App
>would benefit from a complete re-write

Thanks for the advice J French.

The Quickbasic code looks like a game of snakes and ladders with all
it's 'goto' commands. I know a good program structure avoids many goto
commands in the code. There are 'goto' commands in the subroutines
that jump to a line number outside the number range for the
subroutine, this is somthing I found that Visual Basic can't do.
The other problem is that there is a jump (goto) to a line number
within a subroutine from outside of the subroutine.

I might find some examples of Visual Basic code for complete programs
on the internet which I could study.

Regards Brian
.

Relevant Pages

  • Re: Problem writing code to go to a label after calling a procedure
    ... >>Thanks for the advice J French. ... I know a good program structure avoids many goto ... >>subroutine, this is somthing I found that Visual Basic can't do. ... >you rip out his code and re-write it, sometimes it is Ctl V and the ...
    (comp.lang.basic.visual.misc)
  • Re: Programming languages
    ... pipeline to be flushed. ... Subroutine calls are interruptions of an orderly flow, ... The compiler may even inline the function if it's small. ... the target of a goto, the compiler has to discard all cache and register ...
    (sci.lang)
  • Re: Programming languages
    ... they constitute unpredictable interruptions of what ... Subroutine calls are interruptions of an orderly flow, ... the target of a goto, the compiler has to discard all cache and register ... which requires the pipeline to be flushed. ...
    (sci.lang)
  • Re: Use of subroutines
    ... >>I still maintain that a subroutine is first and foremost a GOTO ... > GOTO transfers control with no provision to return and continue ... > continue execution. ...
    (comp.lang.fortran)
  • Re: Use of subroutines
    ... Go tos are not evil. ... >I still maintain that a subroutine is first and foremost a GOTO ...
    (comp.lang.fortran)