[dev build] Path issue

[FellippeHeitor]

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.

[Richard]

@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.

[Richard]

@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)







  [ You are not allowed to view this attachment ]


  [ You are not allowed to view this attachment ]


  [ You are not allowed to view this attachment ]


  [ You are not allowed to view this attachment ]


  [ You are not allowed to view this attachment ]


  [ You are not allowed to view this attachment ]


  [ You are not allowed to view this attachment ]


  [ You are not allowed to view this attachment ]


  [ You are not allowed to view this attachment ]


  [ You are not allowed to view this attachment ]


  [ You are not allowed to view this attachment ]


  [ You are not allowed to view this attachment ]


  [ You are not allowed to view this attachment ]


  [ You are not allowed to view this attachment ]


  [ You are not allowed to view this attachment ]


  [ You are not allowed to view this attachment ]


  [ You are not allowed to view this attachment ]  




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?

[Richard]

@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?

[FellippeHeitor]

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.

[Richard]

@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]

🥰

[Richard]

@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..."

[Richard]

@FellippeHeitor

dev e29e122  Win 10 x64 Pro  build 21H1 (AUG update)


It has been a while (dev build wise) since I got this error .....




  [ You are not allowed to view this attachment ]  







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)