Through traffic or no?

[Pete]

Back in the Stone Age, when computers did not have clocks in the taskbar, I made my own clock routine to display the time. The problem was it needed to be constantly looped to keep the time displayed accurately. To accomplish this, I made all my sub-routines flow-through routines. No matter how nested the routines became, the program always flowed back to and cycled through the main. Now that was a PITA when it came to variable management, but at least I didn't have to place a clock call in every sub-routine that had loop routines. 

How about the rest of you folks; what method do you prefer to use for large projects when it comes to keeping the flow in each routine or always passing control back through the main? Currently I favor avoiding flow-through routines.

Pete

[Petr]

Hi. I'll just put it in the same subroutine that draws the output graphic fields. And depending on whether it should be on top or below something, the order of drawing is just set.

Continuous subroutines are sometimes needed, for example for the mouse, for the keyboard and so on.

[Pete]

I always combine my keyboard input and mouse routines in a single sub. If I knew back then what I know now, I would have combined the clock routine in that sub-routine, too. Then just call the keyboard/mouse/clock in every program closed loop. It was a bit harder back then, with multi-modular programming, but still doable. By using TYPE variables, there is a lot less to code to pass variables so that is helpful, but I wish we could type arrays. Back then to save on memory, I used almost all global variables no longer than 2 characters. Lucky for you guys I was a chiropractor, because if not, the cost of your aspirin would have been double back then, due to supply shortages!

Pete

- Pete is tremendous but Steve's just amazing!

[SMcNeill]

Usually when I need to do what Pete is suggesting, I create a self-monitoring routine and only have it report an a solution once it's finished.

Let's say I have an interactive game where you're in a spaceship flying around with other players all connected via TCP/IP.  You can use the mouse to move and interact with the spaceship.  You want to type a message to others.

Now, at this point, you DON'T want the game to freeze up, so I'd set a few flags.

IF ALT + M THEN 'the player hit the alt-m buttons to flag they were sending a message
    PlayerMessage = True  'set a flag so we now check for what they're typing
END IF

Below all these flag setters, I'd have some code to call my routines:
IF PlayerMessage Then 
    Msg2Send$ = GetInputForMessage
    IF Msg2Send$ <> "" THEN PlayerMessage = 0 'we got a message.  we don't need to look for anymore
END IF

And outside my main loop would be something like:

FUNCTION GetInputForMessage$ (k as Long) 'key is my key stroke as read in the main loop and passed along faithfully
    STATIC partMsg$
    IF k <> CHR$(13) THEN
      partMsg$ = partMsg$ + chr$(k)
    ELSE
       GetInputForMessage = partMsg$ 'the player hit ENTER, finishing what he was trying to type in
       partMsg$ = ""
     END IF
END FUNCTION

---

The idea here is that main loop keeps looping.  The subroutines ONLY get called when necessary to reduce strain and resource usage in the main loop.  Those subroutines ONLY return a value once they're finished do whatever they do, otherwise, they just return blank.  

If it's a routine that returns a number, I'll choose some fanciful non-existent type number for them, or else I'll pass a FINISHED flag with them if I can't pass an invalid solution.  For example, think of a routine that asks for someone to enter a number from 0 to 9.  IF they haven't hit 0 to 9 yet, I'd simply return a value of 123 as a "nope!  no valid info here yet.  We're still counting fingers and toes waiting on it..."

So a lot of my longer junk that I code relies on this style coding.  Set a flag, only check the routine when that flag is set, keep checking it until that flag is cleared or the process is complete, use the completed result and reset that flag so we don't check that routine anymore and free up processing cycles.

[Pete]

Similar to just setting a flag but doing so with an event...

Code: (Select All)

' Main

Cls

Locate 10, 2: Print "Message";: Color 7 + 16: Print ":";: Color 7, 0

Do



    keyboard key$



    If Len(key$) Then

        If LCase$(key$) >= "a" And LCase$(key$) <= "z" Or key$ = " " Then



            message key$



            If key$ = Chr$(13) Then

                Locate 10, 11: Print Space$(_Width - Pos(0)); ' Message sent.

                Locate 10, 2: Print "Message";: Color 7 + 16: Print ":";: Color 7, 0 ' Ready for next message.

            End If

            If key$ = Chr$(27) Then Exit Do

        End If

    End If



    animate



Loop

End



Sub keyboard (key$) ' Flow-through sub-routine.

    _Limit 30

    key$ = InKey$

End Sub



Sub message (key$) ' Non-flow-through sub-routine.

    y = 10: x = 10

    Locate 10, 2: Print "Message:"; ' Stops colon from flashing.

    Do



        animate: Locate y, x + 1, 1 ' animation routine is called again here.



        If LCase$(key$) >= "a" And LCase$(key$) <= "z" Or key$ = " " Then

            If x < _Width Then x = x + 1: Locate y, x, 1: Print key$;: x = Pos(0) - 1

        End If

        If key$ = Chr$(8) And x > 10 Then Locate y, x: Print " ";: x = Pos(0) - 2



        keyboard key$



    Loop Until key$ = Chr$(13) Or key$ = Chr$(27)

End Sub



Sub animate ' Flow-through sub-routine.

    Static ii, z

    If Abs(Timer - z) > .25 Then

        z = Timer

        If ii Then Locate 15, ii, 0: Print " "; Else Locate 15, _Width: Print " ";

        ii = ii + 1

        Locate 15, ii, 0: Print Chr$(254);

        If ii = _Width Then ii = 0

    End If

End Sub

Okay, let's pretend that message routine was a full blown word processor of around 8000 lines of code. That would take some hefty planning to make it a flow through routine back to the animation in the main; so a solution is to do as in the code above, make it call the animate routine in both the main and the wp message routine. Of course if it was really just a small program, as above, I would have coded then message routine to flow through to the main. The reason is because a program is easier to understand and debug when the programmer can easily figure out which routine was the calling routine. One call to animate is better than two, in this case.

Pete

[JRace]

If memory serves, the system clock on the TRS-80 Models 1 through 4 were software based, updated by regular CPU interrupts.  That meant that long periods with disabled interrupts, such a writing to cassette tape or floppy disk, could cause the clock to run behind.  Always gotta serve the clock; the story of modern life.

When programming, it's usually easier for me to think in terms of — and keep track of  — the overall project, not subroutines.  I hate having to constantly jump around source code chasing down subs, so my programs are often large, monolithic main functions.  My subroutines tend to be small, simple afterthoughts added to clean up the main.  They're usually called by main and return quickly there.

There's nothing wrong with a "blocking" subroutine which hangs the program briefly while waiting for something, as long as the wait does not frustrate the user or cause other problems, but...
In the world of interactive software, that fall-thru method can be thought of as a form of multitasking, a way of keeping the program moving forward and keeping the user distracted so that small delays don't become annoying.

---

Speaking of falling through: In a prior life I spent 10 years as a control technician.  My primary job was programming HVAC controllers using a stripped-down version of Pascal which had no looping mechanisms, so every program was fall-thru.  As a program ran it would access the current state of things by reading temp sensors, pressure sensors, etc, then make subtle adjustments to get closer to the program's desired targets (the "setpoints").

(That Pascal variant also had no arrays, which was a major pain in the keester on a couple occasions.)

That version of Pascal did have functions & procedures, which were almost never used.  If a program became large enough to need subs, then the program was split up into two or more simple, single-purpose programs.

Coming as I did from a world of "normal" computer programs, with no prior HVAC experience, it was fun getting to know that system.  The first assignment my boss gave me was to improve the program which ran the building's problematic cooling towers.  The program I submitted was a monstrosity of conditionals testing for every possible good or bad state... something I learned was unnecessary on that system.  That beast of a program worked as intended, but it turned out that the real problem was not a software issue, but a hardware one.  Those control panels had been incorrectly wired since day one!

[Pete]

is Fallthough what we are discussing here? It may be, but I thought it described language differences where in blocks some languages require a 'break' or 'return' while others allow the statements to continue... fallthrough.

I like the term, but I'm not sure if it can also be applied to subroutines.

Pete

[JRace]

Fall-through specifically refers to the behavior of switch...case statement in C, C++, and other languages, where execution will fall through from one case statement to the next unless specifically stopped.  It's an often useful feature which can lead to bugs.

One definition found online: "Fallthrough: when a state machine can move to subsequent states in the same program cycle."
(So fallthrough could also occur in ladder logic, etc.)

When I Google "flow-through" I get pages of results about pilots, airlines, and training.

Flowthrough may be more correct, though personally I consider fall-thru & flow-thru to be equivalent.  But hey, I'm a self-taught hack who makes his own rules and terminology.

[Pete]

My use of 'Flow through' is a made up term, just to help describe what is happening. Likewise, absolutely no formal computer education so when it comes to correct terminology, I often don't know my ASCII from my elbow.

Pete