Author |
Topic: Windows disk volume name and serial number? (Read 447 times) |
|
CirothUngol
New Member
member is offline

Odie, Odie, cha cha cha.

Gender: 
Posts: 44
|
 |
Re: Windows disk volume name and serial number?
« Reply #12 on: Jul 14th, 2017, 12:41am » |
|
Thanks again for the replies. I like the idea of using STRUCT for all output from API/DLLs, as it implies consistency and the code looks cleaner. I may never have known it to be an option had you not said, since char as a type doesn't seem to be mentioned anywhere in the LB 4.5 docs (I see that it's mentioned in LBB docs under STRUCT).
My only concern is that one seems unable to use a variable in the STRUCT definition for char members (eg. char[_MAX_PATH]), forcing the use of a constant instead (eg. char[260]). I receive a 'missing ] in struct' error unless I use a constant value. Is this avoidable? It's really the only reason I'm hesitant to use it instead of the more cumbersome string-buffer-with-added-null/left$-characters-before-the-null combo. Also, does the constant value include the null (259+null), or is the length actually 261 (260+null)?
...and as for the relative paths issue, I discovered that even though FILES gives no drive:\path info if none is provided (ie. if path$ is empty then x$(0,2) and x$(0,3) are empty), it will handle the relative stuff just fine if you provide it with a fully qualified path. So, I was able to correct the issue with the following 3 lines of Code:' resolve relative paths
IF path$ = "" THEN path$ = StartupDir$
IF INSTR(path$,"\") = 1 THEN path$ = LEFT$(StartupDir$,2); path$
IF INSTR(path$,":") <> 2 THEN path$ = StartupDir$; "\"; path$ Then when you feed path$ into FILES all relativity is automatically resolved. Seems to work like a charm.
|
|
Logged
|
LB Booster + LB Workshop + LB Builder = My Programs on Google Drive
|
|
|
Richard Russell
Administrator
member is offline


Posts: 1348
|
 |
Re: Windows disk volume name and serial number?
« Reply #13 on: Jul 14th, 2017, 1:30pm » |
|
on Jul 14th, 2017, 12:41am, CirothUngol wrote:| Is this avoidable? It's really the only reason I'm hesitant to use it |
|
It's understandable that the buffer size cannot be a variable (it's declaring a static buffer rather than a dynamic object such as a string) but it would have been desirable for a Windows Constant to be accepted as well as a literal number. For whatever reason - you'd have to ask Carl why - only the latter is accepted in practice.
So it's not currently avoidable (LBB could in principle be adapted to accept a Windows Constant, as a language extension, but it won't at present). However I don't share your hesitancy; a constant is a constant so having to enter the numeric value rather than its symbolic form doesn't concern me other than from a readability standpoint.
If you want to avoid a mistake being made you could always do this:
Code: struct temp, path as char[260]
if len(temp.struct) <> _MAX_PATH then print "Incorrect constant" : end Richard.
|
|
|
|
|