Version 1.04.0

[Drago]

fb_gfx_drawline is awaiting *int style

but revers_mask handels only 32-bit

so the easiest way is: style to be ulong... but I don't know if it will produce other hickups
same for color, but on that one revers_mask isn't used as far as I see

[dkl]

The Line pattern drawing should be fixed in Git now - looks like it was a problem on non-32bit-x86 systems only (64bit x86_64, ARM, etc.). https://github.com/freebasic/fbc/commit ... ecf3333f05

As far as I saw, this bug already existed since the 64bit port (FB 1.00.0), regardless of the more recent Line changes. So it's probably not a regression.

By the way, the problem with fbc and Unicode file reading should be fixed in Git by now too.

[MrSwiss]

@dkl,

thanks a ton, for fixing it ...
Tested again with Yesterday's St_W Build (WIN64), runs as expected (is OK again!).

Funny: when I tried to compile/run with the WIN32 Version I've got a false Positive
from AVIRA Virus Scanner ... seems I'll have to tell them!

[DOS386]

Funny: when I tried to compile/run with the WIN32 Version I've got a false Positive
from AVIRA Virus Scanner ... seems I'll have to

virii-virii

FreeBASIC-1.04.0-2-win32-mingworg.zip | .7z archive - alternative to the normal FB-win32 package, may work better for older Win32 systems

Code: Select all

"fbc.exe" 1'134'080 2015-10-01 12:09 | 1.04.0 MinGW/32
F742'02A6'FF63'BD63'70E7'02B3'421E'C98A

I tried it a bit ... DOS version works on P3, but MinGW/32 version does NOT work on ME due to
"_localtime64" import ... also the binary is full of CMOVNTQ's so it wouldn't work on P2 and even less on 80386 if it succeeded to load :-( How "old" may a system be to run FBC and executables generated by it? CompilerRequirements ... would be nice if the alternative package for old systems also worked on old systems (both old CPU and old Windows or alternatives to it).

[DOS386]

binary is full of CMOVNTQ's

I did a disassembly (many CMOVxx instructions) ... seems that I can't edit my posts here anymore :-(

[fxm]

Weird small graphic bug in FreeBASIC!
No problem for other graphic windows (not FB)

On my mobile PC, when the sector is disconnected (or reconnected), the display is automatically switched off then switched on.
At the same time, the handle values of graphic windows (FB) are modified (I discovered this during the below analysis)!

All is right for a non minimized graphic window (it recovers its initial position).

But for a minimized graphic window (only from FB), the window is not recovered when clicking on its icon!
After analysis, I have found that the window position becomes out of the desktop.
I can recover the window if I reset the window position when detecting a change of handle value.

This problem seems to be old and not linked with a recent FB version.

Code: Select all

#Include "fbgfx.bi"

Screen 12
Print "ok"

Dim As Any Ptr handle
Screencontrol(FB.GET_WINDOW_HANDLE, Cast(Integer, handle))
Dim As Integer x, y
Screencontrol(FB.GET_WINDOW_POS, x, y)

Do
  Dim As Any Ptr n
  Screencontrol(FB.GET_WINDOW_HANDLE, Cast(Integer, n))
  If n <> handle Then
    handle = n
    Screencontrol(FB.SET_WINDOW_POS, x, y)
  End If
  Sleep 100
Loop Until Inkey <> ""

If line 'Screencontrol(FB.SET_WINDOW_POS, x, y)' is put in comment, the bad behavior occurs!
(the window is not recovered when clicking on its icon)

[fxm]

The analysis continues:
When a window is minimized, 'Screencontrol(FB.GET_WINDOW_POS, x, y)' returns an invalid position (the values are very negative: -32000)
Therefore, when the window is minimized, the returned position is not usable to refresh the window parameters for the new handle.

Small code to monitor the handle and the position of a graphic window:

Code: Select all

#Include "fbgfx.bi"

Screen 12
Print "ok"

Do
  Dim As Any Ptr n
  Screencontrol(FB.GET_WINDOW_HANDLE, Cast(Integer, n))
  Dim As Integer x0, y0
  Screencontrol(FB.GET_WINDOW_POS, x0, y0)
  Shell "echo." & Str(n) & ": " & Str(x0) & ", " & Str(y0)
  Sleep 1000
Loop Until Inkey <> ""

[fxm]

One can get the restoring's position of a minimized window, not by calling 'GetWindowRect()', but by calling 'GetWindowPlacement()':

Code: Select all

#Include "windows.bi"
#Include "fbgfx.bi"

Screen 12
Print "ok"

Do
  Dim As Any Ptr handle
  Screencontrol(FB.GET_WINDOW_HANDLE, Cast(Integer, handle))
  Dim As RECT r
  GetWindowRect(handle, @r)
  Dim As WINDOWPLACEMENT wp
  GetWindowPlacement(handle, @wp)
  Shell "echo." & Str(handle) & ": " & Str(r.left) & ", " & Str(r.top) & space(3) & Str(wp.rcNormalPosition.left) & ", " & Str(wp.rcNormalPosition.top)
  Sleep 1000
Loop Until Inkey <> ""

Code: Select all

394832: 363, 144   363, 144
394832: 363, 144   363, 144
394832: 363, 144   363, 144
394832: 363, 144   363, 144
394832: -32000, -32000   363, 144
394832: -32000, -32000   363, 144
394832: -32000, -32000   363, 144
394832: -32000, -32000   363, 144
394832: -32000, -32000   363, 144
394832: 363, 144   363, 144
394832: 363, 144   363, 144
394832: 363, 144   363, 144
394832: 363, 144   363, 144

[fxm]

Weird small graphic bug in FreeBASIC!
No problem for other graphic windows (not FB)

On my mobile PC, when the sector is disconnected (or reconnected), the display is automatically switched off then switched on.
At the same time, the handle values of graphic windows (FB) are modified (I discovered this during the below analysis)!

All is right for a non minimized graphic window (it recovers its initial position).

But for a minimized graphic window (only from FB), the window is not recovered when clicking on its icon!
After analysis, I have found that the window position becomes out of the desktop.
I can recover the window if I reset the window position when detecting a change of handle value.

This problem seems to be old and not linked with a recent FB version.

Monitoring of the problem for my mobile PC (by using the above code):

Code: Select all

   handle
   !        GetWindowRect()
   !        !          GetWindowPlacement()
   !        !          !
   1179922: 363, 144   363, 144
   1179922: 363, 144   363, 144
>  1114380: 363, 144   363, 144              < after sector disconnecting
   1114380: 363, 144   363, 144
   1114380: 363, 144   363, 144
>  1376532: 363, 144   363, 144              < after sector reconnecting
   1376532: 363, 144   363, 144
   1376532: 363, 144   363, 144
>  1376532: -32000, -32000   363, 144        < after window minimizing
   1376532: -32000, -32000   363, 144
   1376532: -32000, -32000   363, 144
>  1508820: -32000, -32000   -32000, -32000  < after sector disconnecting
   1508820: -32000, -32000   -32000, -32000
   1508820: -32000, -32000   -32000, -32000
>  1507604: -32000, -32000   -32000, -32000  < after sector reconnecting
   1507604: -32000, -32000   -32000, -32000
   1507604: -32000, -32000   -32000, -32000

[MrSwiss]

@fxm,

interesting Find.

Is "Sector disconnect/reconnect" in plain words: the Action of the Lid-Switch?
If so, have you tested with assigning a different Behavior, e.g.:

• Sleep
  Hibernate
  Shut down etc.

since this might have an Influence on the Result.

[fxm]

I have discovered this behavior by disconnecting then by reconnecting the charger cable on my laptop (Lenovo T420).
I have not tested other behavior as sleep, ...

I think this is a bug in fbgfx because it does not happen with another compiler like Visual Basic.
(I think the cause is the handle which changes on a minimized graphic window)

My concern is not for that marginal case (disconnection or reconnection of the charger), but perhaps there are other cases more operational where occur window handle changes.

[DOS386]

FB how has a Boolean type and True/False constants

there seems ^^^ to be a typo

And could you please look into the compatibility (CPU, Win32 version) of the "win32-mingworg" packages.

[fxm]

@fxm,

interesting Find.

Is "Sector disconnect/reconnect" in plain words: the Action of the Lid-Switch?
If so, have you tested with assigning a different Behavior, e.g.:

• Sleep
  Hibernate
  Shut down etc.

since this might have an Influence on the Result.

This works well, even after a deep sleep (the Windows session saved, PC shut down, then the Windows session restored):
- In that case, the handler of the minimized window remains unchanged.

The problem only occurs while I disconnect or I reconnect the charger of my laptop (but the windows of other programs even minimized are correctly recovered).

[Tourist Trap]

The problem only occurs while I disconnect or I reconnect the charger of my laptop.

What is true is that the system can detect battery removal and send message to energy manager which also can switch some flag about the screen state. Maybe when doing so an important flag regarding fbgfx is disturbed?

[fxm]

I think the only cause of this bug in fbgfx is the handle change on a minimized graphic window.