RUN or CHAIN

[Juanjogomez]

Hi,
To load a program without having to send variables, is it better to use "RUN" or can you use "CHAIN" anyway?
By not having to use an intermediate file to pass variables, "RUN" would load the other program more quickly?.

[luke]

If you just want to run another program without any fancy passing of data it seems easiest to do SHELL _DONTWAIT  s$ : SYSTEM.

[Juanjogomez]

If it is to execute another QB64 program, would it also be done like this? I thought that was just to run external programs

[FellippeHeitor]

Another QB64 program will always be an external program, since QB64's not an interpreter, but a compiler. CHAIN/RUN do a few background tricks to ensure compatibility with older code that required splitting modules due to size constraints. For a program you're writing nowadays you'll either (i) not need to split your program across different binaries or (ii) just actually use SHELL to invoke an external program, if you need to for some reason.

[SpriggsySpriggs]

@Juanjogomez

I've found something for WinAPI for creating a shared memory object. I've never done this before so I can't guarantee it works. I won't be available today until around 7 PM EST. I'll check tonight and see what all is involved with making a named shared memory object. Here is a link to an example from the MSDN pages. It's what I will be trying later. https://docs.microsoft.com/en-us/windows/win32/memory/creating-named-shared-memory

[Juanjogomez]

Another QB64 program will always be an external program, since QB64's not an interpreter, but a compiler. CHAIN/RUN do a few background tricks to ensure compatibility with older code that required splitting modules due to size constraints. For a program you're writing nowadays you'll either (i) not need to split your program across different binaries or (ii) just actually use SHELL to invoke an external program, if you need to for some reason.

In my case, it is a billing and warehouse management program that consists of a main menu and 67 programs of 3,000 - 5,000 lines each, so it would be very difficult to group everything into a single program and manage it. When an option is chosen from the menu, that program is loaded and when finished, it returns to the menu to be able to choose another option.
Hence the question, because when you go from one to another there is a moment (a fraction of a second) when you see the windows desktop and then it blinks until the program screen appears and I see it somewhat annoying

[SpriggsySpriggs]

So you are actually sharing information between these programs? Are you the one supporting/writing these programs? If so, I could see it being simple to do something. Otherwise, nothing will be simple.

If you are supporting these programs then do a SHELL and pass the values you need in the command line to be read on the other end using COMMAND$ after execution. For example,

"Parent"

Code: QB64: [Select]

1. numcars = 25
2. SHELL "otherprogram.exe numcars=" + LTRIM$(STR$(numcars))

"Child"

Code: QB64: [Select]

1. IF COMMAND$ <> "" THEN
2.     IF INSTR(COMMAND$(1), "numcars") THEN
3.         numcars = VAL(MID$(COMMAND$(1), INSTR(COMMAND$(1), "=") + 1))
4.     END IF
5.     PRINT numcars
6. ELSE
7.     SYSTEM
8. END IF

Of course, you can wrap the above code in a function and call for each variable

You could kill the calling window from the "child" by doing a process kill using WinAPI (or some command line program) after the window is rendered. If passing variables through the command line is not something you want to do then you could use a TCP/IP connection like Fellippe does. You could SHELL the program then send data to it through TCP/IP right before ending.

If you are not the one supporting these programs:
To put it simply, you are probably screwed.

[Pete]

As an old QB45 business coder, I can tell you I never liked or used "CHAIN" in any of my apps. Much like you, I had several programs that needed to interact with each other, so I just sent the variables to data file, and had the new program load them. Simple and worked like a charm.

Another alternative is to take advantage of QB64 memory, and just combine all those programs. That's no small task, but that's what I ended up doing. It gave me one 80,000+ lines of code and it was during the time Rob was developing QB64, so it helped with beta testing. Those were exciting times.

Pioneer Pete