QB64 Phoenix Edition v3.4.0 Released!

[SMcNeill]

Hard to imagine _DesktopWidth and _DesktopHeight being broken, unless something in glut itself has broken.

Here's what they translate to for us: 

Code: (Select All)

int32 func_screenwidth() {
#ifdef QB64_WINDOWS
    return GetSystemMetrics(SM_CXSCREEN);
#else
#    ifdef QB64_GLUT
    return glutGet(GLUT_SCREEN_WIDTH);
#    else
    return 0;
#    endif
#endif
}

int32 func_screenheight() {
#ifdef QB64_WINDOWS
    return GetSystemMetrics(SM_CYSCREEN);
#else
#    ifdef QB64_GLUT
    return glutGet(GLUT_SCREEN_HEIGHT);
#    else
    return 0;
#    endif
#endif
}

Since we're not talking about how they perform on a Windows system, and since we're running them on a glut system, they both basically translate to a simple:

glutget(GLUT_SCREEN_HEIGHT);
glutget(GLUT_SCREEN_WIDTH);

There's not a whole lot of code in those two translations to say that QB64 broke something with them. 

Try running those under a DECLARE LIBRARY and see if it still segfaults or breaks for you.  I don't know of anything in the world that we've changed that would make v0.5 work, but v3.4 break.  I'll ask on our Dev channel and see if anyone has any ideas, but I personally don't see what the heck could be breaking here.

[mnrvovrfc]

On Windows the easy escape is to call something from Win API.

It's quite possible one of those functions is returning zero, despite the pre-processor arrangements. Now we know other functions within "freeglut" don't like taking in zero for any screen dimension.

Why do I have to "DECLARE LIBRARY" something so it works on Linux? Do it to what? My temporary fix is bad, it's just temporary. As far as "DECLARE LIBRARY" is concerned, I'm a beginner.

The seg-fault thing is always at the end of program run, while the program tries to clean up. It could just happen, destructors getting cranky in a desktop that gobbles up RAM. On another computer just updated Fedora 36 which included Wine, and it seg-faults after every single Windows program that exited. It makes them look bad they postponed release date three times of Fedora 37.

[Kernelpanic]

SMcNeill - 3 settings are from where you probably had multiple versions of QB64 up and running at the same time. The first running instance, you might configure for a blue background, while the second instance could have a black background to help easily distinguish the two running copies.

Looks like you're right. I already have two of each type again, although I had deleted all the 2nd and 3rd. -- Well, the main thing is that it works as it should.

[Coolman]

here is what is surprising, I saw in another post the suggestion to precede the _DesktopHeight command with the _Delay .5 command, example :

_Title "RoCoLoco - Working..."

tiles = grid * grid ' total number of tiles on board
_Delay .5
Screen _NewImage(_DesktopHeight * .80, _DesktopHeight * .80, 32)

tilesize = (_DesktopHeight * .80) / grid

Cls , _RGB(77, 77, 77)

It works. The program runs.

well seen @SMcNeill

the question remains why it works without this addition with version 0.50 of qb64pe...

[mnrvovrfc]

@Coolman good job!

This is my contribution:

Code: (Select All)

dim han AS LONG, wd AS INTEGER, ht AS INTEGER
_DELAY 0.5
han = _SCREENIMAGE
wd = FIX(_WIDTH(han) * 0.8)
ht = FIX(_HEIGHT(han) * 0.8)
SCREEN _NEWIMAGE(wd, ht, 32)
_DELAY 1
COLOR _RGB(255, 255, 255)
print "width  ="; wd
print "height ="; ht
end

The delay has to be done before calling "_SCREENIMAGE" in particular. Moreover, a delay has to be done just after "SCREEN _NEWIMAGE()" call to give the system time to draw the window, or it doesn't print anything as this program is written.

I wrote this mimicking what I saw in Terry's "QBZERK".

I noticed that before "_MESSAGEBOX" is called there is a delay of at least one second. Maybe it doesn't happen with other users.

[Coolman]

for this program, same problem :

https://staging.qb64phoenix.com/showthre...01#pid9001

inserting _DELAY 0.5 at the beginning of the code solves the problem...

there has been a regression between version 0.50 of qb64pe and the new versions. it will probably be necessary to compare the source codes to find the problem...

concerning _MESSAGEBOX, there is indeed an important latency time.

does this problem occur only under linux ?

[mpgcan]

Test1: Used the following code:

Code: (Select All)

_Title "MPG 1"
name$ = _InputBox$("MPG 2", "Enter your name:", "anonymous")
If name$ <> "" Then _MessageBox "MPG 3", "Hello " + name$, "info"

Expected results see image:
(Click to view full size)


Unexpected results! Titles incorrectly displayed see in the following image:
(Click to view full size)


Note: Results are intermittent, the first run is ok, the second and subsequent runs fail.

Test 2: Used the following code:

Code: (Select All)

_Title "MPG 1"
name$ = _InputBox$("MPG 2", "Enter your name:", "")
If name$ <> "" Then _MessageBox "MPG 3", "Hello " + name$, "info"

The result shown in the image below:
(Click to view full size)



It clearly shows something is wrong.

Note 1: In the above tests the _MessageBox is OK.
Note 2: I have included the status bar icons for reference, it looks as if a HTML Application is run?


Ref:
Windows 8.1 64-bit QB64 Phoenix Edition ver 3.4.0 Tests 3/11/2022

[SpriggsySpriggs]

@mpgcan
I think Samuel said this is due to a bug in tinyFileDialogs itself.

[James D Jarvis]

Just got a chance to fiddle with the new dialog control commands and I appreciate their inclusion. They are nice and simple and straight forward. Bravo!

[mnrvovrfc]

- Do not use " and ' as the dialogs will be display with a warning
instead of the title, message, etc...

From:

https://sourceforge.net/projects/tinyfiledialogs/files/

So don't waste time with CHR$(34) toward those fancy dialogs. To me this sucks.

LOL I knew this could employ "zenity" on Linux. There is a setting to use console-mode dialogs which are mouse-aware but those are ugly.

Might want to check extensibly this "tinyfiledialog" thing on Windows11 because that information guarantees support up to 10. Don't get irritated because that information was updated yesterday. :/