CHAIN command not working

[TerryRitchie]

I had someone contact me about using the CHAIN command and not being able to get it to work for them. They sent me their source code and after a few rewrites I can't get it to work either? QB64 continuously complains that it can't find QB64.bas two parent directories below the current working directory.

This also happens regardless if I'm using two .BAS programs from within the editor or using two compiled .EXE files outside the editor as pointed out by the CHAIN Wiki entry.

Has anyone been able to successfully use the CHAIN command? If so, please post some example code so I can see what I may be doing wrong.

For now I gave the user that contacted me other ways of achieving their goal without using CHAIN. I also explained to this user that CHAIN is really no longer needed as it's a relic from the golden age of BASIC, however I would still issue a possible bug report all the same.

Terry

[bplus]

As I recall CHAIN comes from days QB was an interpreter and a compiler, CHAIN assumes bas code to interpret which no longer happens in QB64. RUN is usually the work around but there you need compiled proggies. (Update #2, no not according to Wiki, in fact today I just fixed a program with Run and happy I could restart a program like that.)

Update: Wiki does give impression it still works, with one really bad example!

[mdijkens]

I've got a simple example working, but I'D STRONGLY DISCOURAGE using CHAIN


chain1.bas

Code: (Select All)

Common Shared a
a = 3
Print "CHAIN 1", a
Chain "chain2"

chain2.bas

Code: (Select All)

Common Shared a
Print "CHAIN 2", a

I ran from the IDE but had to compile chain2.bas to an exe (F11) to get it working
With both exe's I could just start chain1.exe

[Kernelpanic]

It works for me anyway. "Shared" must be used when transferring to an external function in the called program. Otherwise not necessary.

Program 1

Code: (Select All)

'Beispiel fuer Chain. - 8. Juli 2022
'Aufruf einer externen Funktion die
'den GGT berechnet

Common Shared Zahl1, Zahl2 As Long

Print
Print "Berechnet den GGT zweier Zahlen"
Print

Input "Zahl 1: ", Zahl1
Input "Zahl 2: ", Zahl2

'Ruft externes Programm auf das mit
'den Zahlen den GGT berechnet
Chain "GGT-externe-Funktion"

End

Program 2 (Will be called.)

Code: (Select All)

'Wird von "Aufruf-externe-FunktionGGT" aufgerufen - 8. Juli 2022
'Berechnet mit den uebergebenen Zahlen
'den GGT

'Geht nur mit dem Schluesselwort "Shared"
Declare Function ggt(zahl1, zahl2 as Long) as Long

Common Shared Zahl1, Zahl2 As Long

Print: Print
Print Using "Der gemeinsame Teiler von ##### und ##### ist: ####"; Zahl1, Zahl2, ggt(Zahl1, Zahl2)

End 'Externes Hauptprogramm

Function ggt (zahl1, zahl2 As Long)

  Dim temp As Long

  While (zahl1 > 0)
    If (zahl1 < zahl2) Then
      temp = zahl1: zahl1 = zahl2: zahl2 = temp
    End If
    zahl1 = zahl1 - zahl2
  Wend
  ggt = zahl2

End Function

[TerryRitchie]

Thanks for looking into this guys. Yeah, I agree, avoiding the use of CHAIN is highly recommended. I did pass that onto the person that contacted me as well.

[Kernelpanic]

Thanks for looking into this guys. Yeah, I agree, avoiding the use of CHAIN is highly recommended. I did pass that onto the person that contacted me as well.

Great, then I could have saved myself all the clutter.

[TerryRitchie]

Thanks for looking into this guys. Yeah, I agree, avoiding the use of CHAIN is highly recommended. I did pass that onto the person that contacted me as well.

Great, then I could have saved myself all the clutter.

LOL, I do appreciate the effort as I now know how to use this ancient command properly. Thank you :-)

[mnrvovrfc]

I've got a simple example working, but I'D STRONGLY DISCOURAGE using CHAIN
:

I'm not sure where I read it (QB64 wiki?) but the QB64 system has to use files to keep track of the data going from one program to another. This means that, especially on Linux, this could present a security issue, which is the main reason why the use of "CHAIN" is discouraged. Somebody who knows how QB64 operates could make malicious arrangements such as scrambling file or directory permissions. It's hard enough to detect if a program is already running and, if an attempt is made to run it again, to just pick up the parameters from the command line, like "Audacious" media player could do on Linux to order it to start, stop, resume and so on. That's an alternative to using "CHAIN" but that could also be screwed up intentionally by a vengeful person.

[SMcNeill]

That's exactly how QB64 handles CHAIN. Common Shared variables are basically saved to the drive when the program hits chain, and then they're loaded from the drive when the second program starts. It's really rather old school and quite clunky and inefficient, and I'd honestly suggest that instead of using CHAIN for sharing such chunks of data, one would be better off to simply write and clean up a data file themselves. By writing your own data to disk, you have more control over it -- when it gets written to, when it gets deleted, how you store it, if you decide to compress it, ect, ect.

My personal advice is to just pretend that CHAIN doesn't exist. If you need to share values, do so with your own data file -- don't rely on the clunky system which QB64 has implemented in place to do it for you.

[Pete]

Back in the good ol' QJurassic Period, I put 14 programs together using a database file (what Steve was getting at) to transfer the data to each new program that was run from the main program. I never used CHAIN. I thought it was sucky and if I remember right, it had some limitations with stand-alone exes. So basically, you could say I yanked my CHAIN. I know Steve would happily put it that way!

Pete