![]() |
_File$ is not behaving as expected, cannot determine why - Printable Version +- QB64 Phoenix Edition (https://qb64phoenix.com/forum) +-- Forum: Chatting and Socializing (https://qb64phoenix.com/forum/forumdisplay.php?fid=11) +--- Forum: General Discussion (https://qb64phoenix.com/forum/forumdisplay.php?fid=2) +--- Thread: _File$ is not behaving as expected, cannot determine why (/showthread.php?tid=3112) |
_File$ is not behaving as expected, cannot determine why - hanness - 10-10-2024 I'm having some difficulties with _Files$ not behaving as expected. A detailed description of the issue can be found in the comments of the code sample below. To summarize briefly, _Files$ works fine by itself, but when I introduce a number of lines of code that I currently have commented out, those lines for some unknown reason cause _Files$ to no longer work. Again, see the full description in the comments. My test scenario: QB64PE 3.14.1 Windows 11 24H2, latest public release (build 26100.2033) Logged on as an Administrator If anyone can provide a clue why this is failing, I would really appreciate some insight. I've been at this for a few hours and cannot put my finger on the problem. Code: (Select All)
RE: _File$ is not behaving as expected, cannot determine why - SMcNeill - 10-10-2024 It's the use of the KILL statement. Code: (Select All)
This may be intentional to prevent you from trying to open and access files that could no longer exist any longer. Best solution would probably be to read all those files into an array first, then process them after. RE: _File$ is not behaving as expected, cannot determine why - hanness - 10-10-2024 Let me make sure that I understand... Even though the kill command is not removing any of the files that _Files$ is working with are we saying that the problem is simply that we altering the directory contents while we are working with that directory using _Files$? If I create and then kill that text file in a different location, would that solve the problem? Apologies, I would simply try this myself but I won't be in front of that system until morning. I had also thought that using an array would be a good workaround, but I wanted to understand why I was having this difficulty. Thanks for the help! RE: _File$ is not behaving as expected, cannot determine why - SMcNeill - 10-10-2024 From digging into a little more in our Dev channel on Discord: It looks like a bug/unintentional to me, KILL/FILES/_FILES$ all call into the same logic to do the file searching which has a static `DIR *`, so calling one of them resets the state of `_FILES$`. Presumably it should have it's own separate state. ************** So it's something likely to change and be fixed in a future release. Until then though, reading it into an array would let you work around the issue. RE: _File$ is not behaving as expected, cannot determine why - hanness - 10-10-2024 Perfect. I'll work around it for now, but I assume that a flag is being raised to hopefully get this looked at in depth at some time in the future as you noted. Again, thanks for the great help. At least now I know I wasn't doing something completely stupid :-) BTW, just a word of thanks for such an excellent product. I'm no professional programmer, but QB64PE allows me to automate a great number of tasks. I even have one program that is about 14,000 lines so far. It started off as a simple program to allow me to inject all the latest Windows updates directly into Windows ISO images but it's grown into a library of routines for performing just about every possible task one could imagine with Windows images. It's all a breeze to do with QB64PE and a ton of fun on top of it. RE: _File$ is not behaving as expected, cannot determine why - SpriggsySpriggs - 10-10-2024 That's a pretty crazy bug. I hope they can fix that. Sounds like there was some bad programming left in there. RE: _File$ is not behaving as expected, cannot determine why - a740g - 10-14-2024 Fixed: https://github.com/QB64-Phoenix-Edition/QB64pe/pull/557 Will be available in the next release. |