Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
QB64 Phoenix Edition 3.4.1 Released
#11
(11-17-2022, 05:35 PM)bplus Wrote: Thanks Spriggsy, I'll cross it off my list of things to do with a new version update.

Is there a way to automate resetting Windows registry to open .bas files with newest QB64pe.exe?
That's the one most tricky and Windows is making it harder with each new version of itself.

@bplus
Here is a post on Superuser that shows how you can associate multiple file types with a program using a batch file: https://superuser.com/a/1311168
Tread on those who tread on you

Reply
#12
(11-17-2022, 05:09 PM)bplus Wrote: Looks like the Open Dialog always starts where you last opened a file.

Is there a way to start in a set Folder? My Shortcut Properties Startup Folder no longer works.
I don't know, but you could create a "blank" file in the folder that you want, that is never going to be changed nor moved from its location, say "aaablank.bas", and open it when you open the QB64PE IDE. Create a shortcut to set the command to start: "QB64PE.EXE drive:\path\to\file\aaablank.bas".

Then after the IDE is opened, try to open another source code file. It's clunky but if the starting path is really long it could save time.

At least it works at my end on Linux, but with the old dialog. The OS open file dialog comes up with "Recent List" for me but it should be different on Windows.
Reply
#13
Afraid I don't care for the new open file stuff, Just doesn't fit the QB feel and as such seems very out of place.
Reply
#14
the new file opening system does not match the look of the qb64pe editor. under linux there is a latency of about 1 second before the window appears. apparently the problems found under linux have not been corrected. i think i'll use version 0.50 again.
Reply
#15
I hope everyone realizes that there is a toggle for this dialog and that this isn't the only option.
Tread on those who tread on you

Reply
#16
Thumbs Up 
Thanks Spriggsy,

I did not know. Found it real quick under Options > GUI Dialogs got my shortcut folder starter back!

That dialog was leaving me in no mans land if I used another Basic with same kind of Dialog.

Like Cobalt I am not a big fan of change BUT if QB64 wasn't any different than QB4.5 I would NAHT like it nearly as much!
b = b + ...
Reply
#17
(11-17-2022, 06:35 PM)Cobalt Wrote: Afraid I don't care for the new open file stuff, Just doesn't fit the QB feel and as such seems very out of place.
Agreed, especially on Linux where M$ products weren't very popular until Wine did something about it. But Steve sounded really excited about it a few weeks ago and a few other people agreed, apparently all on Windows.

To me, this OS open-file dialog is convenient but it sucks on the OS side because the "Recent Files" gag cannot be adjusted. This goes for other apps on Linux that have this mechanism. Why can't it always open in "Documents" or in the last place visited, after the app is started?

I don't mind the delay before a dialog opens, that's better than screwing it up royally or not making it available such that one is tempted to install Wine and run the Windows version just to get more functionality.
Reply
#18
Now, I will say it only looks out of place to me because the save button still brings up the old dialog rather than a save file dialog box.
Tread on those who tread on you

Reply
#19
(11-17-2022, 09:01 PM)Spriggsy Wrote: Now, I will say it only looks out of place to me because the save button still brings up the old dialog rather than a save file dialog box.
The problem with that one is that it's harder, or maybe not possible, to force a file type, like what kind of text file. The "MIME" database on some Linux distros is really skewed up. Especially after Wine is installed it becomes happy setting file associations that it really shouldn't such as "INI" to fire up the Wine Notepad or "HTML" to try to open the Internet Explorer emulation that doesn't work most of the time. If I'm not mistaken the function call for save-file dialog out of "tinyfiledialogs" illustrates this problem. It supports one "suggestion" for a file type which the user of the compiled program doesn't have to follow because "All Files" is always available.

On WindowsXP the programmer was allowed to give a long text entry delimited with pipes or ASCII0 for each file suffix he/she wished filtered into the displayed file list, to increase the chance a file was saved with the expected suffix. Now at least on Linux with one of the text editors ("xed" at this moment on EndeavourOS), it's either "Text files" or "All files". And through the "MIME" the system really doesn't care what is a text file, with suffix "TXT", "BAS", "C", "LUA", if it's "readme.md" or much more.

What is irritating about all of this on Linux is that some file managers attempt to guess what kind of text file, eg. they detect "#" as the very first character of the file. If "include" follows then they surmise it's a C/C++ source code file. This is possible with Freebasic source code too. If "!/bin/bash" follows or maybe just the exclamation point then that file is decorated as "bash" script even if that "executable" text file could fire up "gawk" or Lua instead. An EXE file could be mistaken for a self-extractable archive even with Wine installed but that's another point entirely.
Reply
#20
I don't know. I'm glad I'm not a user of Linux, I guess.
Even the QB64 dialog doesn't force you to save as a particular extension, so nothing would be different there.
Tread on those who tread on you

Reply




Users browsing this thread: 2 Guest(s)