Version 1.04.0

[Tourist Trap]

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

Minimized windows are not taken in charge in FB?

[fxm]

Yes, but the bug seems occur on the minimized fbgfx windows only if the handle is changed.

[Muttonhead]

I'm not sure where the fault is to be found:
This small program, compiled with version 1.04 32bit crashes. Compiled with the 64 bit version I have no problems. Compiling with the previous version (32 bit) seems to work without problems.
The error seems to occur only in the Windows version:
-s console -> the consoles window does not disappear (THREADWAIT ???)
-s gui -> program terminates apparently normal, but to end only via the taskmanager

https://www.freebasic-portal.de/porticu ... -1816.html

The odd thing is, a greatly reduced version, practically nothing is happening there, is working properly

Mutton

[dkl]

Seems like the code is waiting for a thread to exit in a global destructor - apparently, that's not safe on Windows, because global destructors are run under the "loader lock", which however is also needed for a thread to exit - hence there is a race condition and possible dead lock. See Preventing Hangs in Windows Applications, especially the "Do"/"Do not" sections under "Use Locks Wisely".

FB's gfxlib was affected by this issue too, because it uses a background and waited for it to exit in a global destructor. So I changed it in FB 1.04 - the Screen is now destroyed at End (or at the end of the implicit main), so graphics functions no longer work in global destructors.
http://www.freebasic.net/forum/viewtopi ... =6&t=23043

However, I can't explain why the issue with FB's gfxlib2 itself never showed up before, or why your code works with the old version. But it could be just luck...

[fxm]

Yes, one cannot stop a thread by a module destructor when working in graphic mode.
Try the following change in Win32 and Win64:

Code: Select all

'******************************************************************************
'******************************************************************************
'allg. Destruktor**************************************************************

'sub Maindestructor destructor
'  if sGUI.SysEvents then delete sGUI.SysEvents
'end sub

'******************************************************************************
'******************************************************************************
'Hauptprogramm*****************************************************************
using sGUI

screen 19,32
SysEvents=new SystemEvents

dim as string key
do
  sleep 1
  print ".";
  key=GetInkey
  if key<>"" then print key;
loop until key=chr(27)

delete SysEvents

[DOS386]

> 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

Oddly, the "standard" version brewed with MinGW/64 DOES work on ME ... but the "more compatible" MinGW/32org version does not. Both are full of CMOVNTQ's.

[MrSwiss]

Print Statement with semicolon at the End is NOT suppressing CR/LF anymore on Lines >= 25 ???
Tested with: FBC_WIN_64_Ver_1.04.0 (WINDOWS 8.1 Pro 64), TestCode:

Code: Select all

' WIN Console Program, aka FBC -s console ...
Width 80, 220    ' it doesn't matter with or without Width Statement 

For i As Long = 0 To 50
	Locate i+1, 1
	Print "Step Value: " & i;	' <--- here is the Problem !!!
	'Print "Step Value: " + Str(i); ' <--- here is the Problem also !!!
	'Print "Step Value: "; Str(i); ' <--- here is the Problem also !!!
Next

Print : Print "Any Keypress EXIT's Program ..."

Sleep : End 0

Step Value: 0
Step Value: 1
Step Value: 2
Step Value: 3
Step Value: 4
Step Value: 5
Step Value: 6
Step Value: 7
Step Value: 8
Step Value: 9
Step Value: 10
Step Value: 11
Step Value: 12
Step Value: 13
Step Value: 14
Step Value: 15
Step Value: 16
Step Value: 17
Step Value: 18
Step Value: 19
Step Value: 20
Step Value: 21
Step Value: 22
Step Value: 23
Step Value: 24Step Value: 25Step Value: 26Step Value: 27Step Value: 28Step Value
: 29Step Value: 30Step Value: 31Step Value: 32Step Value: 33Step Value: 34Step V
alue: 35Step Value: 36Step Value: 37Step Value: 38Step Value: 39Step Value: 40St
ep Value: 41Step Value: 42Step Value: 43Step Value: 44Step Value: 45Step Value:
46Step Value: 47Step Value: 48Step Value: 49Step Value: 50
Any Keypress EXIT's Program ...

[fxm]

This is not a problem of 'PRINT' (with semicolon), this is just the behavior of 'LOCATE' which does not induce a scrolling up of screen (when requesting a positioning below the last line) as does a CR/LF.

[MrSwiss]

'LOCATE' which does not induce a scrolling up of screen (when requesting a positioning below the last line) as does a CR/LF.

Can't find anything like that in DOC (current online or 1.04.0 CHM) ???
It seems illogical if the Console has been resized larger. The Buffer to write to is there anyway!
Inducing Scrolling isn't called for ... (can be done manually by User).

[marcov]

> 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

Windows ME supports 80386? The wikipedia says that P-I with 32MB is minimum

[fxm]

'LOCATE' positions the text cursor on the screen window and not into the text buffer.
For your example, the screen size is 25 lines (although the buffer contains 220 lines).
So a valid line parameter for 'LOCATE' must be inside of [1 to 25].

[MrSwiss]

Thanks fxm, Problem solved ...

[fxm]

Bug or not bug?

The built-in type 'Object' cannot be used in a conditional '#If' expression, both as symbol/parameter value or string literal:

Code: Select all

#define typename1 byte
#if typename1 = integer
#endif

#define typename2 short
#if typename2 = object
#endif

#define typename3 object
#if typename3 = integer
#endif

Compiler output:
....\FBIde0.4.6r4_fbc1.05.0\FBIDETEMP.bas(6) error 20: Type mismatch in '#if typename2 = object'
.....\FBIde0.4.6r4_fbc1.05.0\FBIDETEMP.bas(10) error 20: Type mismatch in '#if typename3 = integer'

This behavior appears with fbc version 0.90.0?
(with the new keywords 'Virtual', 'Abstract', and 'Override')

[fxm]

Bug or not bug?

The built-in type 'Object' cannot be used in a conditional '#If' expression, both as symbol/parameter value or string literal:

Code: Select all

#define typename1 byte
#if typename1 = integer
#endif

#define typename2 short
#if typename2 = object
#endif

#define typename3 object
#if typename3 = integer
#endif

Compiler output:
....\FBIde0.4.6r4_fbc1.05.0\FBIDETEMP.bas(6) error 20: Type mismatch in '#if typename2 = object'
.....\FBIde0.4.6r4_fbc1.05.0\FBIDETEMP.bas(10) error 20: Type mismatch in '#if typename3 = integer'

This behavior appears with fbc version 0.90.0?
(with the new keywords 'Virtual', 'Abstract', and 'Override')

Same bug for a macro:

Code: Select all

#macro test(typename)
  #if typename = OBJECT
    Print "OK"
  #else
    Print "NOK"
  #endif
#endmacro

test(integer)
test(object)

Compiler output:
.....\FBIde0.4.6r4_fbc1.05.0\FBIDETEMP.bas(9) error 20: Type mismatch in 'test(integer)'
.....\FBIde0.4.6r4_fbc1.05.0\FBIDETEMP.bas(10) error 20: Type mismatch in 'test(object)'

But there is a workaround:

Code: Select all

#macro test(typename)
  #if x##typename = XOBJECT
    Print "OK"
  #else
    Print "NOK"
  #endif
#endmacro

test(integer)
test(object)

Code: Select all

NOK
OK

[dkl]

It's quirky, but I'm fine with that not working... looks like it's the same as with any class (UDT with methods etc.) name.

Code: Select all

type mystruct
	dummy as integer
	declare constructor()
end type

#if mystruct = undeclaredid  '' error: type mismatch
	#print "equal"
#else
	#print "not equal"
#endif

#if allows using most keywords as text, so they can be compared with other text, but especially with namespaces (class UDTs also are namespaces) it currently fails. It's understandable, afterall #if also supports constants now, and those can be in a namespace too...

Using typeof() is better for this:

Code: Select all

#if typeof(integer) = typeof(object)
	#print "equal"
#else
	#print "not equal"
#endif