Re-dimension a vector in True Basic

[RobinC]

Thanks. I'll try DOSBox forum.

Robin

[bob]

Jul 13, 2018 19:12:19 GMT 1 RobinC said:

Yeah, I do use Tru Basic in Windows when I have to. It's just clumsier than in DOS.

Agreed: I use their Windows version "when I have to."

I have True BASIC version 3.05, but my preference is version 3.00 in Windows XP.

With the help of vDOS, I have been using True BASIC 3.00 effectively and efficiently in Windows 7 for years.

Now I am using Windows 10 -- "when I have to" -- and trying to get True BASIC to run in a way that is both familiar and useful in Windows 10.

Unhappily, Windows 10 seems to have broken a much-used feature of vDos 2015.10.1: the ability to paste text with [Win][Ctrl]+V.

I prefer to use the "no extended keyboard" mode in True BASIC 3.00. That mode is enabled by starting True BASIC with this command line -- hello/noxkb-- with no spaces.

That command line worked as intended in the vDos 2015.10.1 with Windows 7.

In vDos 2020.03.1 with Windows 10, it stops with: "No such file."

[Jos]

If you program doesn’t use [Ctrl]+V, you can still use that.

You could start vDos with the log option (….vDos.exe /log). Then look in the generated vDos.log file where the "No such file." comes from.

Jos

[bob]

Aug 8, 2020 15:56:44 GMT 1 Jos said:

If you program doesn’t use [Ctrl]+V, you can still use that.

You could start vDos with the log option (….vDos.exe /log). Then look in the generated vDos.log file where the "No such file." comes from.

Jos

Thank you, Jos, for the fast and informative reply.

Yes, [Ctrl]+V works in True Basic 3.00 with vDos 2020.03.01. Being able to access the Windows clipboard from within the DOS program is immensely helpful.

The values returned by True BASIC's "GET KEY" statement -- and my customizations of the key bindings that are possible in version 3.00's editor (which I find to be much more user friendly and interactive than the editor in any of their Windows versions I have used) -- are affected by the "no extended keyboard" mode.

I had not used the log option before. The resulting file is attached.

The "hello.exe" program (to start the True BASIC editor, with on-demand interactive program execution) is expecting "noxkb" to be a True BASIC program file (noxkb.tru) that is to be run immediately (instead of opening the editor) upon startup of the language system.

For some reason, the '/noxkb' command line switch will be recognized only if there are no spaces between the program name and the slash for the switch.

I don't recall using any other program that disallowed a space before a command line switch.

vDos 2015.10.1 accommodated this quirky behavior. It seems that vDos 2020.03.01 does not.

Attachments:

vDos.log (864 B)

[Jos]

The line "OpenFile failed: NOXKB.TRU(2) => c:\a\b\NOXKB.TRU(2)" states there's no NOXKB.TRU file in the current DOS working directory (no path supplied), resolving to Windows c:\a\b\NOXKB.TRU.
NOXKB.TRU is located somewhere else?

Jos

[bob]

There is no intention for there to be a NOXKB.TRU file in any location.

"/noxkb" is a command line switch so the language system will report the same key codes from corresponding keys in an "extended" keyboard, wherever they are located:
1) the numeric key pad (number, arrows, etc.)
2) the QWERTY/navigation sections of the keyboard.

The slash seems to be getting converted to (or prefaced with) a space, so the IDE (integrated development environment) in the hello.exe program is seeing noxkb as a file name (with an implied .tru extension), not as a command line switch.

[Jos]

Sorry, didn’t read your message that good.
That extra space is added by vDos. The only versions that didn’t do that were 2015.10.01 – 2016.10.01. Seemingly that gave problems with other programs, so it was reinstated.
Perhaps that space should not be added if the first character is a '/' or '-'?

Jos

[bob]

Aug 8, 2020 20:04:57 GMT 1 Jos said:

Perhaps that space should not be added if the first character is a '/' or '-'?

Jos

I would like that for the '/' character, but: I am biased, I am a sample size of one, and I didn't experience the issues that the change addressed.

It might be safe to forego inserting a space before a '/' character within the first continuous group of non-space characters in the command line. 

But if a program name contains a '-' character and the user omits the extension for the program, the user's intent may be less clear.

A user might have two programs:

Program name		Purpose
prog.exe		Print the value of the command line switch, or '0' if there is none
prog-1.exe		Print 'hello world'

If the user omits the .exe extension and the '-' is interpreted as the start of a command line switch, then the desired result from a 'prog-1' command line may be ambiguous.

[Jos]

I probably wasn’t clear.

When the vDos command line interpreter parses a line, that is split into two parts:
The command (internal or an external program) to be executed.
The remainder (passed on to the internal command or external program).

That remainder is then eventually prefixed by a space. To comply to the behavior of NTVDM or some program(s) expecting that (don’t recall).
What I intended was to check that remainder for a leading '/' or '-', then skip adding a space.

Jos

[bob]

It seems I don't understand how the vDos command line interpreter parses a 'prog-1' line in a context where both 'prog-1.exe' and 'prog.exe' are valid external programs. And you have been more than gracious in your attention to my posts.

I request that vDos skip adding a space.

[Jos]

Basically the command line is split at the first space, tab, '/' or '=' character. The first part is evaluated as an internal or external command. The second part is passed on to that command.

So "prog-1 -more" would become "prog-1" and " -more". If "prog-1" with a ".com", ".exe" or ".bat" extension is found (w/o a path, eventually in the PATH environment variable), that program is started with " -more" as its command line.

I’ll remove adding a space if the command line (the mentioned second part) doesn’t start with one.

Jos