Issue with code?
#11
I wish I had kept some of my old examples or SHELL weirdness. I can recall way back when you could use command /c or cmd /c on some SHELL calls, but the results would be different. Also, in QB64, I swear I had a couple of times I had to remove the _HIDE statement to get the SHELL to work. I can't recall if including or excluding cmd /c ever made a difference in the results. I'm more of a get it working type than a documenting what doesn't work type, so too bad for me that my age has caught up with my editi.. eidet... mammer... my mind ain't what it used to be!

Pete
Reply
#12
Thank you all, I am learning QB64 history from you all. I will try the items you have suggested. This sounds like it was an issue that has been around since day one that the files command was added. Thanks for the insight and suggestions.
Reply
#13
As @Pete implied, FILES is a relic of the old Basic interpreters which allowed you to quickly see what's on disk without dropping back down to DOS.  Although FILES can be used in a program as a last resort, it is clumsy and limited, and QB64 provides a much more useful toolset for the programmer.
Reply
#14
(07-30-2022, 03:12 PM)bobkreid Wrote: Thank you all, I am learning QB64 history from you all.  I will try the items you have suggested.  This sounds like it was an issue that has been around since day one that the files command was added.  Thanks for the insight and suggestions.

If you need any help implementing anything, come back and post the code that is giving you problems. That's the easiest way to get help fixing issues.

I use various coding methods in my projects so they will run on Windows; API, DOS SHELL, powershell, and the like, but if you wanted to share a project, and wanted it to run on Linux, I'd consider the error trap method for drives. It should work on Linux, although I only use Windows and haven't personally tested it.

Pete
Reply




Users browsing this thread: 6 Guest(s)