Version 1.04.0

For other topics related to the FreeBASIC project or its community.
Tourist Trap
Posts: 2958
Joined: Jun 02, 2015 16:24

Re: Version 1.04.0

Postby Tourist Trap » Dec 19, 2015 9:27

fxm wrote: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
Posts: 10211
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Version 1.04.0

Postby fxm » Dec 19, 2015 9:49

Yes, but the bug seems occur on the minimized fbgfx windows only if the handle is changed.
Muttonhead
Posts: 131
Joined: May 28, 2009 20:07

Re: Version 1.04.0

Postby Muttonhead » Dec 20, 2015 17:55

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/porticula/threaddestructorproblem-mit-fb1-0432bit-1816.html

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

Mutton
dkl
Site Admin
Posts: 3221
Joined: Jul 28, 2005 14:45
Location: Germany

Re: Version 1.04.0

Postby dkl » Dec 20, 2015 19:06

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.
viewtopic.php?f=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
Posts: 10211
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Version 1.04.0

Postby fxm » Dec 20, 2015 19:49

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
Posts: 798
Joined: Jul 02, 2005 20:55

Re: Version 1.04.0

Postby DOS386 » Dec 21, 2015 10:59

> 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
Posts: 3725
Joined: Jun 02, 2013 9:27
Location: Switzerland

Re: Version 1.04.0

Postby MrSwiss » Dec 23, 2015 15:10

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

Output: wrote: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
Posts: 10211
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Version 1.04.0

Postby fxm » Dec 23, 2015 16:05

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
Posts: 3725
Joined: Jun 02, 2013 9:27
Location: Switzerland

Re: Version 1.04.0

Postby MrSwiss » Dec 23, 2015 18:12

fxm wrote:'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
Posts: 3074
Joined: Jun 16, 2005 9:45
Location: Eindhoven, NL
Contact:

Re: Version 1.04.0

Postby marcov » Dec 23, 2015 18:52

DOS386 wrote:> 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
Posts: 10211
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Version 1.04.0

Postby fxm » Dec 23, 2015 19:59

'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
Posts: 3725
Joined: Jun 02, 2013 9:27
Location: Switzerland

Re: Version 1.04.0

Postby MrSwiss » Dec 23, 2015 20:41

Thanks fxm, Problem solved ...
fxm
Posts: 10211
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Version 1.04.0

Postby fxm » Jan 02, 2016 10:03

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
Posts: 10211
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Version 1.04.0

Postby fxm » Jan 02, 2016 13:46

fxm wrote: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
Site Admin
Posts: 3221
Joined: Jul 28, 2005 14:45
Location: Germany

Re: Version 1.04.0

Postby dkl » Jan 02, 2016 17:31

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

Return to “Community Discussion”

Who is online

Users browsing this forum: No registered users and 10 guests