_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 - RhoSigma - 10-10-2024 (10-10-2024, 09:54 AM)hanness Wrote: Let me make sure that I understand... Although I'm with Steve, that a seperate state should be used here, it wouldn't solve the problem of bad programming you do here. You never should change the floor while you walking on it. Climbing a stairway always becomes dangerous when another guy is randomly removing steps at the same time. As Steve said, rather read the whole directory into an array and after that's done use the array to modifiy the directory entries as needed. 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 - hanness - 10-10-2024 (10-10-2024, 01:09 PM)RhoSigma Wrote:I apologize, but that is flat out wrong.(10-10-2024, 09:54 AM)hanness Wrote: Let me make sure that I understand... Bear in mind that this happens even if the file I am working with is not in the same directory. Put another way, I can retrieve the names of files one by one using _Files$ and never ever modify a single file in that folder. Even if I perform a kill on a file ON ANOTHER DRIVE it causes the failure of _Files$. Sorry if my response sounded harsh. I just wanted to make 100% clear that the issue still exists without modifying a single file in the folder on which _Files$ is operating on. 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. |