On Tue, 22 Nov 2011 17:42:28 +0000 (UTC), "Auric__"
Post by Auric__Post by who whereI am modifying an old QB45 program to find some information embedded
within the folder "C:\Program Files\whatever" which of course in DOS
8.3-speak becomes "C:\Progra~1\whatever".
If I attempt to directly set up a string with the required path and
file name, the ~ character is omitted and the file open fails. The
same happens if I fabricate the string using CHR$(126). Even
executing a CD command to the required folder via SHELL has the same
limitation.
Is there a workaround for this?
Post your actual code. This should not be happening. (Doesn't happen to me
under WinXP using QBasic or QBX 7.1; don't have QB4.x installed to test on.)
What happens if you just do this?
CHDIR "\PROGRA~1"
SHELL "CD"
Part of the problem I am facing is that there appears to be no *easy*
way to ascertain what is the CURRENT PATH in the QB45 IDE, or if there
is I haven't discovered it.
The QB operation isn't on the C: drive, which may have complicated
things. What I was doing is of the form:
CD$ = "something"
SHELL CD$
to try and get the current path to point to C:\Progra~1\whatever, as
direct statements like
PF$ = "C:\Progra~1\whatever"
OPEN PF$+"\folder1\file1" FOR INPUT AS #1
or
PF$ = "C:\Progra~1\whatever\folder1\file1"
OPEN PF$ FOR INPUT AS #1
didn't work while the current drive was E:. If I inserted a
breakpoint between those lines, examining PF$ with a Ctrl-RtMouse
showed the ~ character not present. I must admit it was a leap of
faith (in MS) to assume that this faithfully displayed the string.
Since posting, I have tried a lot more bits in the SHELL example above
(so the actual failing code is NLA), and did actually get the desired
result with:
CD$ = "CD\"
SHELL CD$
(probably redundant going to root of E:)
CD$ = "C:\"
SHELL CD$
CD$ = "CD " + "Progra~1\Whatever"
SHELL CD$
(note that it would NOT change direct to a folder in C:
in a single step ...)
SELECT CASE J$
CASE IS = "44"
PF$ = "copy 44\Whatever.ini c:\ini2ini.txt"
SHELL PF$
....
OPEN "c:\ini2ini.txt" FOR INPUT AS #1
Note that an OPEN containing the ~ character within a named string, or
even with a current path containing it and the ~ not in the OPEN
string per se, would still fail. The copy-then-parse approach did
work, however.
When I am doing quick'n'dirty mods in the IDE, I tend not to use error
trapping. Rather, I use breakpoints and examine variable values to
ensure things are happening the way I want. In this exercise the
parsing routine which examined the .ini file never found the target
until I employed the copy/parse approach. Clunky but it worked, and
all the data we needed to recover from the files was rapidly found.