To get a file/directory list in AMOS one uses Dir First$ and Dir Next$, emulating the AmigaDOS functions _LVOExamine and _LVOExNext but not actually doing what they do - in AMOS Dir First$ reads the entire list holding it in memory, the Dir Next$ function just reads the memory list, the same is true for Dev First$/Dev Next$
It returns a formatted string with filename followed by space characters, then the size. but if the size is over 1 megabyte it does not show the correct size, and it is not compatible with later versions of AmigaDOS that allow filenames of 106 characters - FxBox uses a simple work around at this point, opens the file and checks the real file size then continues and has some error handling for "filename too long"
to call _LVOExamine and _LVOExNext is a simple process:
_DIR_FIRST_NEXT:
Dreg(1)=Varptr(_NULL$)
Dreg(2)=-2 : Rem SHARED_LOCK ACCESS_READ
L=Doscall(-84) : Rem _LVOLock
If L
Reserve As Work WBANK,260 : Rem STRUCTURE FileInfoBlock
S=Start(WBANK)
Dreg(1)=L
Dreg(2)=S
E=Doscall(-102) : Rem _LVOExamine
While E
TYPE=Leek(S+4)
F$=Peek$(S+8,108,_NULL$) : Rem NULL terminated
SZ=Leek(S+124)
If TYPE>0 : REM fib_DirEntryType
Print "(dir) ";F$
Else
Print F$;SZ
End If
Dreg(1)=L
Dreg(2)=S
E=Doscall(-108) : Rem _LVOExNext
Wend
Gosub _CLEARWORK
Dreg(1)=L
L=Doscall(-90) : Rem _LVOUnlock
End If
Return
but there are so many code updates (knock-on effects) to FxBox, i can see that it is not a "fun" exercise for me - I am putting this work off until a scenario arises where I need it, I have noted that AROS does not like the built-in AMOS routines and there is a double _LVOUnLock bug in AMOS. the only actual benefit FxBox would get is the ability to open files that have a space character at the end of their file-name (a Dir Next$ limitation) and the file requester could sort by date, which is not necessary for me. the benefit is too small to justify the work right now.
To get a file/directory list in AMOS one uses Dir First$ and Dir Next$, emulating the AmigaDOS functions _LVOExamine and _LVOExNext but not actually doing what they do - in AMOS Dir First$ reads the entire list holding it in memory, the Dir Next$ function just reads the memory list, the same is true for Dev First$/Dev Next$
It returns a formatted string with filename followed by space characters, then the size. but if the size is over 1 megabyte it does not show the correct size, and it is not compatible with later versions of AmigaDOS that allow filenames of 106 characters - FxBox uses a simple work around at this point, opens the file and checks the real file size then continues and has some error handling for "filename too long"
to call _LVOExamine and _LVOExNext is a simple process:
but there are so many code updates (knock-on effects) to FxBox, i can see that it is not a "fun" exercise for me - I am putting this work off until a scenario arises where I need it, I have noted that AROS does not like the built-in AMOS routines and there is a double _LVOUnLock bug in AMOS. the only actual benefit FxBox would get is the ability to open files that have a space character at the end of their file-name (a Dir Next$ limitation) and the file requester could sort by date, which is not necessary for me. the benefit is too small to justify the work right now.