FreeBASIC 1.07 Release Discussion
Re: FreeBASIC 1.07 Release Discussion
thank you for the new release :-)
Re: FreeBASIC 1.07 Release Discussion
Is the ABI constructor/destructor issue already fixed in the new release?
Re: FreeBASIC 1.07 Release Discussion
heh, I guess no sense in dwelling on any feeling of accomplishment .. back to slapping the keyboard ;)
ABI is not changed yet in 1.08.0. I'll do my best, but no promises on what get's done in the next month -- the list of requests is *very* long. :)
I'd like to get 1.08.0 released in Jan 2021 as we are coming up on 1.5 years for a new release now...
Discussion for 1.08.0 development is at FreeBASIC 1.08 Development
That's literally it. 1.07.2 is intended to be very compatible with 1.07.1. I needed to release 1.07.2 to have new base packages to build a 1.08.0 release. I had hoped to also do FreeBSD packages, but there's still a lot of work to do there.news wrote: Highlights:If you don't need official packages for arm, aarch64, or gas64, then you probably OK to stick with 1.07.1 release until 1.08.0.
- updates to makefile and build scripts
- gas64 win/lin x86_64 emitter can build the fbc compiler and pass all tests in the test-suite making this the first self hosting release for gas64 (SARG)
- improvements for linux-arm and linux-aarch64 targets with official download packages for Raspbian9-arm & Ubuntu-20.10-aarch64
- bootstrap now includes linux-arm and linux-aarch64 targets
- several minor bug fixes
ABI is not changed yet in 1.08.0. I'll do my best, but no promises on what get's done in the next month -- the list of requests is *very* long. :)
I'd like to get 1.08.0 released in Jan 2021 as we are coming up on 1.5 years for a new release now...
Discussion for 1.08.0 development is at FreeBASIC 1.08 Development
Re: FreeBASIC 1.07 Release Discussion
Thank you very much for all your efforts!
Re: FreeBASIC 1.07 Release Discussion
Code: Select all
.▀█▀.█▄█.█▀█.█▄.█.█▄▀ █▄█.█▀█.█─█
─.█.─█▀█.█▀█.█.▀█.█▀▄ ─█.─█▄█.█▄█
Also, GAS is great!
Re: FreeBASIC 1.07 Release Discussion
When I use this code in x64 mode then the window is not top most after start - it is behind the code editor. Further, when it is topmost and I click another window it moves behind the activated window. With x86 it works as expected.
Code: Select all
#Include "fbgfx.bi"
Using FB
Screenres 800, 600, 32, , GFX_ALWAYS_ON_TOP Or GFX_ALPHA_PRIMITIVES Or GFX_NO_SWITCH
Sleep
-
- Posts: 54
- Joined: Jun 29, 2014 17:15
Re: FreeBASIC 1.07 Release Discussion
Hello,
Thanks for the release, small issue is that on Raspbian OS (latest version) the keyboard does not process input (Multikey) when the flag GFX_FULLSCREEN is set. It works fine in windowed mode.
OS: Raspberry Pi OS (32-bit) / 2020-08-20
Again, thanks for this release,
Greets,
Pim
Thanks for the release, small issue is that on Raspbian OS (latest version) the keyboard does not process input (Multikey) when the flag GFX_FULLSCREEN is set. It works fine in windowed mode.
OS: Raspberry Pi OS (32-bit) / 2020-08-20
Again, thanks for this release,
Greets,
Pim
Re: FreeBASIC 1.07 Release Discussion
@UEZ, top window not in front -- is this a new bug in this release, or was always a problem? Is it only when the app is run from the IDE?UEZ wrote:When I use this code in x64 mode then the window is not top most after start - it is behind the code editor
@Pim Scheffers, just this release? Like does it work OK in some other user contributed package?Pim Scheffers wrote:on Raspbian OS (latest version) the keyboard does not process input (Multikey) when the flag GFX_FULLSCREEN is set
Related?:
https://github.com/freebasic/fbc/issues/123
https://sourceforge.net/p/fbc/bugs/493/
Unfortunately, the gfxlib needs some real attention. Feels like we've had little quirks and troubles like this for years. Kind of funny, kind of not (because could be a design problem) is https://github.com/freebasic/fbc/pull/273
I don't plan on making anymore 1.07.x releases -- it's too time consuming to maintain 2 branches. So any changes or fixes will need to be in 1.08+ now.
Re: FreeBASIC 1.07 Release Discussion
It doesn't matter which editor I use. When I select "compile and run" the opened window is always in the background behind the visible IDE window.coderJeff wrote:@UEZ, top window not in front -- is this a new bug in this release, or was always a problem? Is it only when the app is run from the IDE?UEZ wrote:When I use this code in x64 mode then the window is not top most after start - it is behind the code editor
Compile option is "-s gui" whereas with "-s console" it works properly. I didn't have this behavior before the update.
When I start the compiled exe from the CMD box then the window will start just behind the CMD box.
-
- Posts: 139
- Joined: May 28, 2009 20:07
Re: FreeBASIC 1.07 Release Discussion
https://1drv.ms/u/s!AsTPhVzcfzRriKsoTCS ... Q?e=ZtvOpR
even if starting the executable from an explorer window, the program is behind it.
ps: screen centered but always behind explorer
Mutton
even if starting the executable from an explorer window, the program is behind it.
ps: screen centered but always behind explorer
Mutton
Re: FreeBASIC 1.07 Release Discussion
For me it happens only with DirectX driver, only with 1.07.2, and only on Win10.
My guess is that this new bug may have appeared trying to fix this other windows gfx bug: Graphics screens are not displayed in Windows 10 Japanese environment
Can you try this work-around?
Set the driver for GDI before SCREEN or SCREENRES:
This should be fixed in 1.08.0 already, as I could not reproduce the problem on Win7 or Win10 with any of the fbgfx drivers.
My guess is that this new bug may have appeared trying to fix this other windows gfx bug: Graphics screens are not displayed in Windows 10 Japanese environment
Can you try this work-around?
Set the driver for GDI before SCREEN or SCREENRES:
Code: Select all
#include "fbgfx.bi"
#ifdef __FB_WIN32__
'' set graphics driver to GDI (Win32 only), before calling ScreenRes
ScreenControl FB.SET_DRIVER_NAME, "GDI"
#endif
Re: FreeBASIC 1.07 Release Discussion
Yes, this "fixes" the issue when setting the gfx driver to GDI. Btw, I'm on Win10.coderJeff wrote:For me it happens only with DirectX driver, only with 1.07.2, and only on Win10.
My guess is that this new bug may have appeared trying to fix this other windows gfx bug: Graphics screens are not displayed in Windows 10 Japanese environment
Can you try this work-around?
Set the driver for GDI before SCREEN or SCREENRES:This should be fixed in 1.08.0 already, as I could not reproduce the problem on Win7 or Win10 with any of the fbgfx drivers.Code: Select all
#include "fbgfx.bi" #ifdef __FB_WIN32__ '' set graphics driver to GDI (Win32 only), before calling ScreenRes ScreenControl FB.SET_DRIVER_NAME, "GDI" #endif
Re: FreeBASIC 1.07 Release Discussion
IMHO, we've had troubles with the DirectX driver on Win10. adeyblue wrote a new Direct2D driver that will be the default selected in fbc 1.08.0.UEZ wrote:Yes, this "fixes" the issue when setting the gfx driver to GDI. Btw, I'm on Win10.
Re: FreeBASIC 1.07 Release Discussion
GDI and DirectDraw (DirectX) now initialize the window in the same way:
Create (but not show) the window
Do the FB related drawing initialisation
Show the window
so it's weird that one works and one doesn't. Setting topmost for a hidden window succeeds but monitoring WM_WINDOWPOSCHANGING, it sets topmost and then sends a second message before SetWindowPos returns where it unsets it again, but still returns success.
I think DirectInput creates its own window to handle the input (which doesn't happen in the GDI driver) so I guess that messes with some things? That or the DirectDraw initialisation does something different when the window is hidden, but that doesn't cause it to fail
Create (but not show) the window
Do the FB related drawing initialisation
Show the window
so it's weird that one works and one doesn't. Setting topmost for a hidden window succeeds but monitoring WM_WINDOWPOSCHANGING, it sets topmost and then sends a second message before SetWindowPos returns where it unsets it again, but still returns success.
I think DirectInput creates its own window to handle the input (which doesn't happen in the GDI driver) so I guess that messes with some things? That or the DirectDraw initialisation does something different when the window is hidden, but that doesn't cause it to fail
Re: FreeBASIC 1.07 Release Discussion
@adeyblue, I think the 1.08.0 gfx changes are just fine. Thanks for checking it out.
I found a new way to shoot myself in the foot ...
Anyway, if apply this change then the window appears on top even with the old directx driver.
I found a new way to shoot myself in the foot ...
And I forgot to cherry pick on to 1.07.2, duh. I have such a mess to clean-up :(1.08.0 wrote: sf.net #898: fbc win gfxlib DirectX driver failed to initialize on 64-bit, due to incorrect construction of DIDATAFORMAT for keyboard device (macko17)
Anyway, if apply this change then the window appears on top even with the old directx driver.