Bug #511
closed
Dir$ not working properly with AOZ Resource drive (or any other assigned drive in the application's resources/filesystem folder). (only works partially)
Added by Brian Flanagan about 4 years ago.
Updated over 3 years ago.
Description
Example 1:
Dir$ = "AMOSPro_Examples:"
Dir
Result:
Music
What I should see:
Col.Abk
Examples
iff
Music
Objects
Pacpic.abk
Samples
Example 2:
Dir$ = "AMOSPro_Tutorial:"
Dir
Result:
Drive not found at line...
What I should see:
Extensions
Extra_Configs
iff
Iff_Anim
Objects
ReTokenise.AMOS
Tutorials
- Estimated time set to 8:00 h
Adding Nick Morrison's information from Bug#138.
His example still fails on both Dir and Dir$.
#manifest:"amiga"
#speed:"safe"
#fullScreen:true
#splashScreen:false
//dir "AMOSPro_Examples:" // drive not found error
//dir$="AMOSPro_Examples:"// drive not found error
Load Iff "AMOSPro_Examples:iff/Logo.iff", 0 // obviously works fine
wait key
- Status changed from New to Rejected
This is not a bug. To make the automatic insersion of fiels from the AOZ Resource drive, I scan for a STRING containing the full pathname of the file to include in every Load instruction.
Here, if you set the directory before with "Dir$", I cannot! As the path is detected at compilation time only.
If you wanted that to work, I would have each time to include the WHOLE content of the AOZ Resource folder, and that would be impossible.
Is there no way to get this real time?
This was working in a previous version!
I used to at least be able to list local files. Why can't I now? (See 2nd example with DF0 in the filesystem folder.)
//
// This works. Files saved by ALL applications go here (in the web browser cache).
// Is there a way to separate this by application?
//
Dir$ = "application:"
Dir
Wait Key
//
// This used to work, but it doesn't any more. (No error is produced, but neither is a file list.)
//
Dir$ = "DF0:"
Dir
Wait Key
- Subject changed from Dir$ not working properly with AOZ Resource drive. (only works partially) to Dir$ not working properly with AOZ Resource drive (or any other assigned drive in the application's resources/filesystem folder). (only works partially)
Re-tested this in 1.0.0 B7. Apparently it has been fixed!
A local assign in the application's resources\filesystem folder is working again.
DF0: works again!
Also available in: Atom
PDF