QB64 Phoenix Edition v3.5.0 Released!

[bert22306]

Is there any way to configure the IDE of v3.5.0 to open files by default to the last folder you used? That, and using File Explorer, were my favorite improvements in 3.4.1.

Was there a deliberate decision to always open inside the qb64pe folder instead? I never store my programs there. Does anyone use that folder for their .bas files? Seems messy.

[SMcNeill]

Is there any way to configure the IDE of v3.5.0 to open files by default to the last folder you used? That, and using File Explorer, were my favorite improvements in 3.4.1.

Was there a deliberate decision to always open inside the qb64pe folder instead? I never store my programs there. Does anyone use that folder for their .bas files? Seems messy.

Aye, we deliberately chose to have it start in the qb64 folder, to prevent any issues.

Imagine this scenario:  You pop in a USB drive.  Navigate to it.  Save a file.  Pop out the USB drive.  Power off the PC.  Later you come back, open QB64, and go to open a file...  and that directory doesn't exist anymore...  IDE Error!!

So, to keep that from happening, the open dialog starts in the same folder the IDE is located in, but then remembers wherever you navigate to after that.  You should have 1 navigate to your bas folder location when you first start Qb64 up, and then until you turn it back off, it'll remember that folder for you and start back from there automatically.

[bert22306]

Thanks, Steve. I moved this to the general discussions. I think there's a fatal error in the ide_methods.bas file of v3.5.0, and that's why this isn't working?

(And no, I didn't do nuffin to cause this.)

[SMcNeill]

No error in the ide_methods; it's simply an include file which isn't meant to stand alone on its own.  You just have to get used to working in it without any syntax checking or auto-formatting.  Make the change to the routine down at the end of the code, save it, open qb64pe.bas, and recompile it to run as you'd like for it to on your computer. 

[Fantomas]

Hi,

It seems that since this new version v3.5.0, _FULLSCREEN don't work ?
It works fine in v3.4.1, i just try with the source code of my game, and ... no fullscreen ?

thanks

update:

in my source code i put a "_ScreenMove _Middle" before "_fullscreen", if i delete "_ScreenMove _Middle", fullscreen works fine

[mnrvovrfc]

Hi Fantomas, welcome to the forums. You might have to put a "_DELAY 1" or so before "_FULLSCREEN". Despite the fixes, the system needs a bit more time to set a "huge" screen. Like 1024x768 is not a problem, but something on a 52-inch monitor would need more time to set up. It's a limitation of the underlying graphics library.

[SMcNeill]

Hi,

It seems that since this new version v3.5.0, _FULLSCREEN don't work ?
It works fine in v3.4.1, i just try with the source code of my game, and ... no fullscreen ?

thanks

update:

in my source code i put a "_ScreenMove _Middle" before "_fullscreen", if i delete "_ScreenMove _Middle", fullscreen works fine

Testing it, it appears that _SCREENMOVE takes a moment to process.  (Our GL Window handling in a separate thread than some of the other stuff.)  What's happening here is that you're going into _FULLSCREEN mode and *then* the screenmove is taking place and knocking it out of fullscreen.

Try this for an example:

Code: (Select All)

_SCREENMOVE _MIDDLE
SLEEP
_FULLSCREEN
SLEEP

As is, it works fine, and you have to press some key to swap to fullscreen and then to end the program.

Take that SLEEP out between the screenmove and the fullscreen, and you'll see it flicker very quickly into fullscreen mode, and then drop it to move back into the middle of the screen.

Simplest solution is to either not worry with screenmove, as it's not really necessary with fullscreen, or else add a small delay in between the two commands so that the screenmove will process and finish before the fullscreen triggers.

_SCREENMOVE _MIDDLE
_DELAY .25
_FULLSCREEN

Something similar to the above would probably be all you'd need for things to flow and work as you'd expect them to. 

[DSMan195276]

Hi Fantomas, welcome to the forums. You might have to put a "_DELAY 1" or so before "_FULLSCREEN". Despite the fixes, the system needs a bit more time to set a "huge" screen. Like 1024x768 is not a problem, but something on a 52-inch monitor would need more time to set up. It's a limitation of the underlying graphics library.

This is incorrect, it's a bug caused by some of the new logic in v3.5.0. Like Steve mentioned adding a delay or sleep will solve the problem for now, and I'll look at fixing it in another release so that the delay is unnecessary.

[bplus]

_Screenmove _Middle has always been slow, use actual numbers, then it's fine. Besides it doesn't know for Middle because it doesn't know where your task bar is.

[Fantomas]

Hi,

Thanks for your replies !

But as i use "_fullscreen", i don't need "_Screenmove _Middle" !

But as i said, it's works fine before with v3.4.1

Regards