QB64.org Forum
Active Forums => QB64 Discussion => Topic started by: Richard on July 30, 2021, 06:59:00 am
-
@FellippeHeitor
f5d70bf dev build
Sad to say that the PATH issue has returned for both installation on C:\ main drive and A:\ RAM drive
This time a different "error situation" - refer screenshot - when trying to load a file from the C:\QB64\ v1.5 stable version folder
[ This attachment cannot be displayed inline in 'Print Page' view ]
-
@Richard please describe the steps to reproduce your PATH issue with the latest dev build. Let's keep this thread for the path issue so it doesn't get confused with the current work being done on $Debug.
-
@FellippeHeitor
f5d70bf dev build Windows 10 x64 2H21 build (updated to about 1 week ago)
qb64_2021-07-29-21-50-42_f5d70bf_win-x64.7z
extracted to C:\qb64_2021-07-29-f5d70bf\ folder (with some extra files added)
[ This attachment cannot be displayed inline in 'Print Page' view ]
Double-clicked on qb64.exe to launch
[ This attachment cannot be displayed inline in 'Print Page' view ]
<No> [Enter]
[ This attachment cannot be displayed inline in 'Print Page' view ]
File > Open [Enter]
[ This attachment cannot be displayed inline in 'Print Page' view ]
Left-click @ C: (in Paths window) NOT Enter yet
[ This attachment cannot be displayed inline in 'Print Page' view ]
Left-click for above to proceed ALSO same effect/result when [enter] pressed
[ This attachment cannot be displayed inline in 'Print Page' view ]
Wanted to load a file from C:\qb64\ which is the folder where v15 stable build is (and all my program files for qb64 all builds)
and that's it!
-
Alright, thank you. I'll get back to you soon.
-
I don't mean to butt into your thread, but I have the same issue. In the Open dialog box, if I click on a file or folder within the current directory it navigates without error seemingly.
If I select a drive, whether that be C: or one of my external USB drives, I get the same error as Richard. If I then click 'No' to continue, it exits QB64, or gives another error if I click 'Yes' to continue.
-
Hi vince. Please let me know which version you have (I know Richard is in the latest dev build). If you aren't in the latest dev build, please get it and let me know if it still happens.
-
There's a new dev build (755bc2f) available right now, if you guys can please try it @Richard @vince https://www.qb64.org/portal/development-build/
-
No promises there - it may just yield a different error, but it may point me in the right direction.
-
Ok, you can refrain from testing - I managed to reproduce the issue locally even with the latest patches. Please wait a little longer and I'll keep you posted here.
-
Hi Fellippe
I am assuming I have an old build. My build is From Git f5d70bf.
-
It's old now, but wait for an even newer one. I'll let you know.
-
New dev build uploaded, from git 96c7c08, should be again in a working state.
-
@FellippeHeitor
96c7c08 dev build Windows 10 x64 build 2H21 (updated to about a week ago)
PROBLEM - not working - however did "proceed" further into navigation.
Installed qb64_2021-07-31-06-21-12_96c7c08_win-x64.7z into C:\qb64-2021-07-31-96c7c08\ folder (as well as sub-folder ....\qb64\)
From C:\qb64-2021-07-31-96c7c08\ doubled click qb64.exe and all the sequence of steps to attempt to load a file from C:\qb64\ (stable v1.5 folder) are as follows...
[ This attachment cannot be displayed inline in 'Print Page' view ]
[ This attachment cannot be displayed inline in 'Print Page' view ]
[ This attachment cannot be displayed inline in 'Print Page' view ]
[ This attachment cannot be displayed inline in 'Print Page' view ]
[ This attachment cannot be displayed inline in 'Print Page' view ]
[ This attachment cannot be displayed inline in 'Print Page' view ]
[ This attachment cannot be displayed inline in 'Print Page' view ]
[ This attachment cannot be displayed inline in 'Print Page' view ]
[ This attachment cannot be displayed inline in 'Print Page' view ]
[ This attachment cannot be displayed inline in 'Print Page' view ]
[ This attachment cannot be displayed inline in 'Print Page' view ]
[ This attachment cannot be displayed inline in 'Print Page' view ]
Hope the pictures explain clearly enough ALL the steps to the error condition.
ALSO of special interest - look at 10'th attachment (3rd from end) - the File name displayed does not precisely match the highlighted one.
-
That helps - narrows it down to files starting with numbers. I'll get back to you on that.
-
@FellippeHeitor
Also DOES NOT WORK with file names starting with a letter either.
-
All bases covered then.
The "files starting with numbers" issue is reproducible. Other than that all is working on my end and I have no idea where to look. Let me know if you can narrow it down to some other reason - maybe something specific to your setup is going on.
-
@FellippeHeitor
Will try various things to try to narrow it down.
99.999% of the time I always only load files from my C:\QB64\ folder which always contains files beginning with numbers.
As you mention "files beginning with numbers" is reproducible - could you, on your computer, make a new folder having files beginning with numbers AND files beginning with letters - AND THEN try loading files beginning with letters. This would "simulate" my working environment. I am hoping it is a "directory" issue which gets "tricked" by files beginning with numbers, and confuses things for all other files in the folder.
Meanwhile, I will also try navigating to other folders to see if the issue persists.
-
@FellippeHeitor
At first it seemed that the "bug packed up and left house" as maybe for a hundred or so various tries (for filenames starting with a letter) all loaded successfully...
BUT
testing further the problem returned (for filenames starting with a letter).
HOWEVER, I noticed the problem ONLY occurs when, however I managed to get this, when
Path C:\\qb64 (Note the double slash after C: a problem reported before by me on much earlier dev builds and which you always managed to fix up)
occurs in the navigation panel (of QB64 IDE). At this point SOMETIMES the file will not load as per already mentioned earlier (this topic).
The hard part became reproducing the steps to achieve this situation, but the screenshots below is the exact sequence on how I managed to get C:\\qb64
When viewing the screenshots I did not actually run DPI_aware...bas, at any stage at all, so its appearance may not have any bearing on the issue.
Your attention is drawn to the 12th screenshot (6th from the end)
[ This attachment cannot be displayed inline in 'Print Page' view ]
[ This attachment cannot be displayed inline in 'Print Page' view ]
[ This attachment cannot be displayed inline in 'Print Page' view ]
[ This attachment cannot be displayed inline in 'Print Page' view ]
[ This attachment cannot be displayed inline in 'Print Page' view ]
[ This attachment cannot be displayed inline in 'Print Page' view ]
[ This attachment cannot be displayed inline in 'Print Page' view ]
[ This attachment cannot be displayed inline in 'Print Page' view ]
[ This attachment cannot be displayed inline in 'Print Page' view ]
[ This attachment cannot be displayed inline in 'Print Page' view ]
[ This attachment cannot be displayed inline in 'Print Page' view ]
[ This attachment cannot be displayed inline in 'Print Page' view ]
[ This attachment cannot be displayed inline in 'Print Page' view ]
[ This attachment cannot be displayed inline in 'Print Page' view ]
[ This attachment cannot be displayed inline in 'Print Page' view ]
[ This attachment cannot be displayed inline in 'Print Page' view ]
[ This attachment cannot be displayed inline in 'Print Page' view ]
Reminder - your attention is drawn to the 12th (6th from end) screenshot regarding C:\\qb64 (double \\)
Carrying on the sequence from above, in this case, behaved correctly - despite C:\\qb64 (double slash) popping up.
Also, it may be a coincidence, but it seems the issue (filenames starting with a letter) not loading occurs when the qb64.exe is "freshly" launched - rather than after a number of file loads.
As you already can reproduce the other issue (filenames starting with a number) - you may already be aware of the problem (in the QB64 IDE) navigation (by pressing the first character of a filename)...
Navigating to X.......bas incorrectly hits on 16x16.bas
Also, to avoid confusion at this stage of debugging, I did not try to use A:\ RAM drive for installation of $DEBUG dev (on initial recommendation by @SpriggsySpriggs to help in the debug process) - however interestingly, when from C:\QB64-2021-07-31-96c7c08\ launch of qb64.exe and accessing and successfully loading a file (starting with a letter) from the RAM drive - file loading (with a letter) from then on was almost 100% successful, irrespective of the drive/folder.
Any suggestions I could try - I am trying to narrow it down to anything specific to my computer. I am wondering if even if there is a timing/race problem as sometimes the computer "stalls" (for up to about 6 or so seconds) which I think that there might be "provisioning" (or something) going on - when the SSD C:\ (have being completely many times filled up, the SSD microcontroller (on board the SSD) has to sort out how to manage the "empty bytes" to "spread out wear and tear" (this is all part of the TBW terra bytes written process) since NAND storage technology can only be written a known finite number of times. So if the SSD (microcontroller) is "busy" as above, I have noticed (even with windows OS) that files may not be found or even copied correctly (often resulting in zero or even small length files created from very long files).
Does anyone else find it extremely hard at times to track down a bug?
-
@FellippeHeitor
Further to the previous reply - is OPTION _EXPLICIT (as per DPI_aware...bas even though it has not been run at any stage in the debug process here and now) - be a candidate for trouble?
-
Several attempts to fix the issue - although I didn't get to actually reproduce it locally.
There have been improvements to several dialog box elements, some path mangling avoidance routines added. Hopefully this will get it going well this time.
Latest version available tonight comes from git f527d90. Please let me know how it goes. Thanks for your patience and thorough reports.
-
@FellippeHeitor
f527d90 dev build Windows 10 x64 build 2H21 (updated to about a week ago)
SUCCESS (so far - limited testing)
Just read your reply about 15 minutes ago and spent all time since testing.
Installed on
C:\qb64-1-aug-pm\
C:\qb64-1-aug-pm\qb64\
A:\qb64-1-aug-pm\
A:\qb64-1-aug-pm\qb64\
In ALL 4 cases above, successfully loaded ...
files starting with letter
files starting with number
files containing OPTION _EXPLICIT (dpi-aware....bas and actually ran this one too)
WITHOUT any issues (and it seemed to actually respond quicker by way of the loading of files)
Note C:\ main drive (SSD) A:\ RAM drive (10 Gbyte)
Above is limited testing - I will still TRY to break same - which I really do not want to do, but I suppose I should try for everyone's long-term benefit.
SUMMARY - no FILEPATH issues at all (will still try to break)
Thankyou @FellippeHeitor
Note - the files loaded were from C:\QB64\ folder
-
🥰
-
@FellippeHeitor
dev e1c148a Win 10 x64 Pro 21H1 build (aug updated)
This may not be a bug - rather how to interpret the path.
Setup on my machine.....
Dev build on RAM drive (A:\QB64\)
v1.5 stable build on C:\QB64\ - and this is where all .bas, include, .h etc files are located that I am playing around with for my programming . These .h files are nothing to do with the ones that QB64 has when the QB64 zip file is unzipped. My .h files are located in C:\QB64\ root directory.
When I use the dev build (on A:\QB64\) and I am experimenting with my experimental .h files (which now are located on A:\QB64\ root directory) apparently the dev build does not look for the included .h file on A:\QB64\ - rather it attempts to look for same on C:\QB64\ and when it cannot find the .h file on C:\QB64\ the IDE status message is
LIBRARY not found on line 5 (this line number is in my experimental program) (click here ....) Caused by (or after): DECLARE CUSTOM LIBRARY ".\\cinclude...",20
I am using the framework of
DECLARE CUSTOMTYPE LIBRARY ".\cinclude...."
...
END DECLARE
Note that only one "\" is in my program DECLARE CUSTOMTYPE LIBRARY where as the IDE status message has two ".\\"
I would have thought that my QB64 dev running from A:\QB64\ would only be searching in A:\QB64\ for my experimental .h file as referred to by DECLARE CUSTOMTYPE LIBRARY ".\cinclude..."
-
@FellippeHeitor
dev e29e122 Win 10 x64 Pro build 21H1 (AUG update)
It has been a while (dev build wise) since I got this error .....
[ This attachment cannot be displayed inline in 'Print Page' view ]
This particular IDE instance was created just on the previous dev build (yesterday) and was used in a program edit and saved OK - on this current build NO files from anywhere can be loaded.
Config.ini identifies this IDE instance as IDE COLOR SETTINGS / WINDOW 6
All other IDE instances (0-5 and 7,8 ) appear to work perfectly irrespective of the paths or filenames (so far).
I can certainly get around from not using #6 - just to let you know (it may be a few hours before I can fully try to investigate)