QLCommander v 2.2.7- For Testers!

[Andrew]

I wasnt aware the toolkit code had to be LRESPRed prior. Will it be baked in, as one does, in the final version?

Toolkits needed to run the program

On SMSQ/E
• Turbo Toolkit turbo_sms_code
• Toolkit 2
• qlcsms_code

On Minerva
• Turbo Toolkit turbo_tk_code
• Toolkit 2
• Pointer Environment (at least ptr_gen - hot_rext and wman are not mandatory for QLCommander)
• qlcmin_code

I can add the tookit to the program, but I prefer not to. I have 2 reasons for this:
1. there are different versions of QLC_code, one for SMSQE and one for Minerva. If I link them into the program then I will end up with 2 versions of QLCommander. And I tried really hard to create a single version that will run on all system
2. QLC_Code includes some extentions that I use in other programs also: Chans, Function and Header code from DIY Toolkit, More, MDInfo and Outln (this one only in qlcmin_code, for Minerva), so I prefer have them loaded only once for all programs instead of bakeing them into all programs

[tofro]

I wasnt aware the toolkit code had to be LRESPRed prior. Will it be baked in, as one does, in the final version?

Toolkits needed to run the program

On SMSQ/E

• Toolkit 2

I have my doubts about this one SMSQ/E should have all of this built in.

[pjw]

The way I see it there are two main categories of toolkits: 1. systems extension, and 2. ad hoc toolkits. Systems extensions are potentially used by many programs and should be loaded at boot. Ad hoc toolkits are only used by the application that needs them and should therefore (only) be loaded/included by that application.

I know there is this gray area in between, where you have an application that relies on one or more "proglets" that all rely on some ad hoc extensions. For me the answer is to make those toolkits as small and as targeted as possible (ie include only those specific commands that are needed by that proglet) and bake them into each.

What one considers systems extensions depends on one's religion, so we wont go there..

If certain commands are used on one platform that are not available in an other, it is still possible to have a single application by using dummies and platform tests within the program. With Qlib it is easy, using the EXT_XX directives. I dont know if there is anything similar in Turbo, but there are other workarounds.

Here is an example of a program that both compiles and runs on SMSQmulator and QPC2. QPC2 has no JVASGET and doesnt need anything like it:

Code: Select all

100 rem $$asmb=dev4_Q_stf_STUFF_BIN,0,10
..
110 EXT_PROC 'JVASGET'
112 :
114 IF MACHINE = 20: JVASGET
116 STUFF -5, SCRAP_GET$
118 QUIT

The program stuffs the contents of the Scrap into the keyboard queue. STUFF_BIN is, of course, the single keyword STUFF toolkit. They can be found at Knoware somewhere.

You could compile this with Turbo under SMSQmulator (without line 110) and the program should run on both QPC2 and SMSQmulator. However, if you were to compile it with Turbo under QPC2, youd have to create a dummy keyword JVASGET, as I tried to explain earlier in this thread, unless there is a Turbo-equivalent directive of EXT_PROC.

[desin]

make_dir ram1_test
save ram1_test_bas
wdir ram1_
test ->
wdir ram1_test
test_bas

QLCommander shows

QLC subdirectory.png (3.58 KiB) Viewed 403 times

Greetings from Switzerland
Markus

[Andrew]

make_dir ram1_test
save ram1_test_bas
wdir ram1_
test ->
wdir ram1_test
test_bas

QLCommander shows
QLC subdirectory.png

Greetings from Switzerland
Markus

Yes, this is normal!
You created on drive ram1_ a directory named test_. It's full name is ram1_test_.
Then you saved the file ram1_test_bas - this means that you saved the file named bas into directory ram1_test_
This is clearly explained in the SMSQE manual and the Superbasic manual: https://superbasic-manual.readthedocs.i ... l#make-dir
Please read the manuals!

[RalfR]

However, the problem is known, so you have to be careful. In this case, you have to save "ram1_test_test_bas."

[desin]

a$=file_select$ (''Test",,ram1_,,,)

menu_rext subdirectory.png (8.85 KiB) Viewed 379 times

Greetings from Switzerland
Markus

[javier2112]

Hello Andrew.

Tested new version. I only can see differences in exe file.

• Renaming directory with a trail underscore is corrected. Now you aren't allowed to do that -> OK

• If you type an invalid path or unmonted partition in panels path, application beeps and you cannot change the path. Also if an unmounted partition is configured as initial path, QLC uses win1_ instead. -> OK

• Problem unzipping or viewing contents of a zip whose filename constains a space character: now QLC does the work. -> OK

• Problem with unzip o viewzip after reopening QLC doesn't happen anymore. -> OK

I cannot detect any other error so, congratulations Andrew, great work!

[Andrew]

Hello Andrew.

Tested new version. I only can see differences in exe file.

• Renaming directory with a trail underscore is corrected. Now you aren't allowed to do that -> OK

• If you type an invalid path or unmonted partition in panels path, application beeps and you cannot change the path. Also if an unmounted partition is configured as initial path, QLC uses win1_ instead. -> OK

• Problem unzipping or viewing contents of a zip whose filename constains a space character: now QLC does the work. -> OK

• Problem with unzip o viewzip after reopening QLC doesn't happen anymore. -> OK

I cannot detect any other error so,
congratulations Andrew, ¡great work!

Thank you Javi! You've been really, really helpful! I appreciate it!

[javier2112]

Andrei, I've got a suggestion for future releases: now, when you rename a directory, the used destination name is always relative to the current directory, but if the new path starts with a device name, I think QLC could ask user to rename to an absolute path or not, or at least, rename to an absolute path without asking.

What do you think?