QB64 bug when using Inform

[bplus]

Text Fetch still works after all these years in QB64pe.exe v 3.6

[a740g]

Text Fetch still works after all these years in QB64pe.exe v 3.6

@bplus Here is the updated version of Text Fetch that works with QB64-PE 3.8 and InForm-PE. It also has an updated and simplified version of @SMcNeill 's direntry.h

So, basically Text Fetch is now completely cross-platform.

I've added this to the InForm-PE examples on GitHub. Hope that is ok.

InForm-PE/examples at master · a740g/InForm-PE (github.com)

[bplus]

Thumbs up! Good, nice to see this old classic updated

Selecting text may be a little clunky but so is shift + arrow speeds sometimes.

[SMcNeill]

Text Fetch still works after all these years in QB64pe.exe v 3.6

Here is the updated version of Text Fetch that works with QB64-PE 3.8 and InForm-PE. It also has an updated and simplified version of SMcNeill 's direntry.h

Simplified version of direntry?  Can you share it with me sometime, with a few comments about which/what you altered/expanded/simplified?

[a740g]

Text Fetch still works after all these years in QB64pe.exe v 3.6

Here is the updated version of Text Fetch that works with QB64-PE 3.8 and InForm-PE. It also has an updated and simplified version of SMcNeill 's direntry.h

Simplified version of direntry?  Can you share it with me sometime, with a few comments about which/what you altered/expanded/simplified?

I've included it on the zip I shared above.

Here's a link to it from my GitHub.
InForm-PE/examples/TextFetch/direntry.h at master · a740g/InForm-PE (github.com)

Code: (Select All)

' --- DIRENTRY STUFF ---



DECLARE LIBRARY "direntry"

    ' This opens a directly for reading it's contents

    ' IMPORTANT: Call the open_dir() wrapper instead of calling this directly. open_dir() properly null-terminates the directory string

    FUNCTION __open_dir%% (dirName AS STRING)



    ' This reads a single directory entry. You can call this repeatedly

    ' It will return an empty string once all entries have been read

    ' "flags" and "fileSize" are output parameters (i.e. use a variable)

    ' If "flag" is 1 then it is a directory and 2 if it is a file

    FUNCTION read_dir$ (flags AS LONG, fileSize AS LONG)



    ' Close the directory. This must be called before open_dir() or read_dir$() can be used again

    SUB close_dir

END DECLARE



' This properly null-terminates the directory name before passing it to __load_dir()

FUNCTION open_dir%% (dirName AS STRING)

    open_dir = __open_dir(dirName + CHR$(0))

END FUNCTION



' --- DIRENTRY STUFF ---

The biggest change here is that read_dir$() is now a FUNCTION and returns a string. Other than this, open_dir() returns a QB compatible bool if it fails. There is some protection for possible memory leaks if open_dir() is used without calling close_dir().

[bplus]

Wasn't I loading only .bas and .txt files in Text Fetch? I tried this new one and overwhelmed it by accidently loading an .exe.

Oh I was using old Shell Dir commands... for Windows only. Anyway the app was intended for bas and txt files only.

[GareBear]

I think Text Fetch like QB64pe likes text file only in ASCII. When I load any *.txt file some did not show up in middle box and some did. I don't think Text Fetch is at fault. Not all text files are saved the same all according to the word processor that is used. It worked well, thanks.

After I wrote this. I found out in Linux, if the text file is restrictive on who has the read/write privilege to the file then Text Fetch will not show the text in the box. I hope this helps.

[mnrvovrfc]

After I wrote this. I found out in Linux, if the text file is restrictive on who has the read/write privilege to the file then Text Fetch will not show the text in the box. I hope this helps.

Yes sometimes Linux is very annoying when one only wants to look at a text file and it comes back with "Permission denied." There are some files in "/etc" and "/var" that require being superuser only to use "cat" or "less" or such other utility, and otherwise the system refuses to allow a regular user to open them with any program. Anyway one has to be careful with using a GUI program like GEdit to open and modify a protected text file.

A few text files have "history" in them, such that there are scary warnings to use a particular brand of the famous "vi" editor to deal with them. Such as "visudo" to edit the file that controls what goes on with often-used "sudo" terminal command. That is something else that makes me shake my head about Unix and its descendants.

The major thing is the system being unable or unwilling to allow a regular user to change the system time even if it's flatly wrong. And a few systems also being lame about allowing NTP sync enabled or not. On Windows this is not even thought about.