Support Forum / Форум поддержки

Posted: **Sun Aug 07, 2016 1:31 pm**

The launcher-program from Ricardobytes viewtopic.php?f=20&t=1499
proved so useful that I have rearranged my directories in the Smart Basic app.
Because now you can quickly start the apps from the launcher, it is no longer a burden if the tree is fairly deep.
The contents in my root-directory are now limited to 2 files and 2 directories, apart from the initial content of 'hello world' and 'Examples'
"- Launcher.sb" is the 'standard' launcher

Code: Select all

/* include-file
Included function will recall the launcher.
To be included on exit of program.
*/
CALL ReturnToLauncher

DEF ReturnToLauncher
path$="/- My Launcher.sb"
IF FILE_EXISTS(path$) THEN RUN path$
TEXT ! TEXT CLEAR
PRINT "Returnpath to launcher not found"
END DEF

which is included at the end of the programs.
It activates the launcher-program "- My Launcher.sb" which is adapted to my wishes.

Some programs however are difficult to adapt to automatic return to the launcher.
In those cases I add a copy of "- Launcher.sb" in the appropriate directory.
By starting that program, the actual launcher "/- My Launcher.sb" will be activated.

: Launcher in tree.JPG (128.68 KiB) Viewed 2246 times

A major advantage of the 'clean' root-directory is that a complete backup to Dropbox or re-install from Dropbox is quite simple now.

Posted: **Sun Aug 07, 2016 4:39 pm**

A very useful concept! I have done some work to get my programs into folders, but I will move toward this structure.

I have also found some programs that are more difficult to return to the launcher. They consist mostly of definitions, and if you test for an exit button while in a definition and then try to run the launcher definition, you get the error "Can't run a definition while in a definition" or similar.

So you have to restructure the program to escape the definition before calling the launcher definition.

Posted: **Mon Aug 08, 2016 10:45 am**

The program structure should be such that the main programflow is via calls to user-defined functions and always ends at the 'END' command. The launcher can then simply be added just before the 'END' statement.
In the following dummy 'program' the main-loop ends via setting '.Quit=1' somewhere in the user-defined functions. Another possibility is via flow-transfer to the exit-label: 'GOTO Exit'

Code: Select all

'Dummy code with launcher
GOSUB Initialise 
DO
  CALL Function-1
  ……
  IF … THEN Exit
  …
  CALL Function-n
UNTIL Quit
Exit:
GOSUB Finish 'clean and delete
{/- Launcher.sb}
END

Best approach is to avoid calls to subroutines in the main section apart from the initialization of global settings and or clean-up before exit.
Frequent usage of GOTO commands will result in so-called 'spaghetti-code' in which the program-flow is unclear.

I have already adapted several programs for launcher-usage, also from other forum-members.
I will start to publish them soon.

Posted: **Mon Aug 08, 2016 3:04 pm**

Good information. Thanks.

Posted: **Wed Aug 10, 2016 5:48 pm**

I have changed the calls to the launcher in my programs.
The call is now conditional on the variable 'Launcher' in the beginning of my programs.
During development I can now disable the launcher by setting 'Launcher=0'
The adapted testprogram is:

Code: Select all

'- My launcher recall test
'by Dutchman august 2016
Launcher=1
GOSUB SomeActivity
IF Launcher THEN
  {/- Launcher.sb}
ENDIF
END

SomeActivity:
sw=SCREEN_WIDTH()
sh=SCREEN_HEIGHT()
SET BUTTONS CUSTOM
DRAW COLOR 1,1,0
FILL COLOR 1,0,0
n$="stop" ! t$="Press to return to launcher"
BUTTON n$ TEXT t$ AT sw/2-150,100 SIZE 300,50  
DO ! SLOWDOWN
UNTIL BUTTON_PRESSED(n$)
BUTTON n$ DELETE
RETURN

Support Forum / Форум поддержки

Launcher 'protocol'

Launcher 'protocol'

Re: Launcher 'protocol'

Re: Launcher 'protocol'

Re: Launcher 'protocol'

Re: Launcher 'protocol'