How to remove title Bar from graphics screen?

[Richard]

Fullscreen does not show Title Bar - want the same feature when not in full screen graphics.  The wiki example only seems to work for text screens.

[FellippeHeitor]

This is the exact example from the wiki with added graphics screen (indicated by comments):

Code: QB64: [Select]

1. '============
2. 'NOBORDER.BAS
3. '============
4.  
5. DECLARE CUSTOMTYPE LIBRARY
6.     FUNCTION FindWindow& (BYVAL ClassName AS _OFFSET, WindowName$)
7. END DECLARE
8.  
9. DECLARE DYNAMIC LIBRARY "User32"
10.     FUNCTION GetWindowLongA& (BYVAL hwnd AS LONG, BYVAL nIndex AS LONG)
11.     FUNCTION SetWindowLongA& (BYVAL hwnd AS LONG, BYVAL nIndex AS LONG, BYVAL dwNewLong AS LONG)
12.     FUNCTION SetWindowPos& (BYVAL hwnd AS LONG, BYVAL hWndInsertAfter AS LONG, BYVAL x AS LONG, BYVAL y AS LONG, BYVAL cx AS LONG, BYVAL cy AS LONG, BYVAL wFlags AS LONG)
13. END DECLARE
14.  
15. GWL_STYLE = -16
16. WS_BORDER = &H800000
17.  
18. 'these are the only lines Fellippe added for this reply --------------------------------------------------------------------------
19. SCREEN _NEWIMAGE(800, 600, 32)
20. FOR i = 1 TO 100
21.     CIRCLE (RND * _WIDTH, RND * _HEIGHT), RND * 100, _RGB32(RND * 255, RND * 255, RND * 255)
22. NEXT
23. 'these were the only lines Fellippe added for this reply ------------------------------------------------------------------------
24.  
25. _TITLE "No Border"
26. hwnd& = _WINDOWHANDLE 'FindWindow(0, "No Border" + CHR$(0))
27.  
28. PRINT "Press any key for no border...": A$ = INPUT$(1)
29.  
30. winstyle& = GetWindowLongA&(hwnd&, GWL_STYLE)
31. a& = SetWindowLongA&(hwnd&, GWL_STYLE, winstyle& AND NOT WS_BORDER)
32. a& = SetWindowPos&(hwnd&, 0, 0, 0, 0, 0, 39)
33.  
34. PRINT "Press any key to get back border...": SLEEP
35.  
36. winstyle& = GetWindowLongA&(hwnd&, GWL_STYLE)
37. a& = SetWindowLongA&(hwnd&, GWL_STYLE, winstyle& OR WS_BORDER)
38. a& = SetWindowPos&(hwnd&, 0, 0, 0, 0, 0, 39)
39.  
40. PRINT "The end"
41.  

[SMcNeill]

You may need to add a small _DELAY in the program at startup, so the window handle is created and reported properly for you.

[Richard]

@FellippeHeitor @SMcNeill

Thanks for reply but...



  [ You are not allowed to view this attachment ]  




However - the title bar is still present (only BLACK and cannot write to same). I even have delays of 2 seconds and still no different.

In FULLSCREEN mode there is "no lost display real estate" for title bar.

[SMcNeill]

I can duplicate this effect perfectly on my machine.  The titlebar doesn't actually disappear; it simply goes black and inactive, with the window still taking up the same amount of space as previously.  I don't remember this being the usual behavior for Win 10, but my stuff is now on the new Win 11 builds and this is how it's working. 

It may simply be a change from windows itself, and not something which we can easily fix.

[FellippeHeitor]

The fact is: The API call does work. You may wanna check if it's triggering a _RESIZE event.

[Richard]

@FellippeHeitor @SMcNeill

Ran program with $RESIZE:ON to compare effect




  [ You are not allowed to view this attachment ]  


$RESIZE:ON  "adds a bit more" to the title bar area.





I am using Windows 10 build 21H1 Pro x64 (updated OCT 2021)   +   dev v2.1 c48bf67

[SMcNeill]

The fact is: The API call does work. You may wanna check if it's triggering a _RESIZE event.

It's not a Resize issue.  I can add $RESIZE to the program and manually resize it all I want, and that black space up top remains with the window.  It's some new interaction between Win 11 and QB64 with the window -- the command is only blacking out (hiding) the title area now, but it's not actually getting rid of it.

  [ You are not allowed to view this attachment ]  

The picture here should show the white window borderline nicely to show what it's doing now.

[Pete]

I just checked and discovered while it works, as advertised in V1.3, it fails to remove the title bar in v 2.0.

Edit: Wow, worse problem then I originaly thought. V2.0 completely mangled even my most fundamental transparent window without border routine...

Code: QB64: [Select]

1. CONST HWND_TOPMOST%& = -1
2. CONST SWP_NOSIZE%& = &H1
3. CONST SWP_NOMOVE%& = &H2
4. CONST SWP_SHOWWINDOW%& = &H40
5.  
6. DECLARE DYNAMIC LIBRARY "User32"
7.     FUNCTION GetWindowLongA& (BYVAL hwnd AS LONG, BYVAL nIndex AS LONG)
8.     FUNCTION SetWindowPos& (BYVAL hWnd AS LONG, BYVAL hWndInsertAfter AS _OFFSET, BYVAL X AS INTEGER, BYVAL Y AS INTEGER, BYVAL cx AS INTEGER, BYVAL cy AS INTEGER, BYVAL uFlags AS _OFFSET)
9.     FUNCTION SetWindowLongA& (BYVAL hwnd AS LONG, BYVAL nIndex AS LONG, BYVAL dwNewLong AS LONG)
10.     FUNCTION GetForegroundWindow&
11.     FUNCTION SetLayeredWindowAttributes& (BYVAL hwnd AS LONG, BYVAL crKey AS LONG, BYVAL bAlpha AS _UNSIGNED _BYTE, BYVAL dwFlags AS LONG)
12. END DECLARE
13. SCREEN _NEWIMAGE(600, 480, 32)
14. GWL_STYLE = -16
15. ws_border = &H800000
16. WS_VISIBLE = &H10000000
17. _TITLE "Borderless Window"
18. DIM hwnd AS LONG
19. hwnd = _WINDOWHANDLE
20. _DELAY .1
21. Level = 175
22. SetWindowOpacity hwnd, Level
23.  
24. winstyle2& = GetWindowLongA&(hwnd, GWL_STYLE)
25. winstyle& = -12582913
26. a& = SetWindowLongA&(hwnd, GWL_STYLE, winstyle& AND WS_VISIBLE) ' AND NOT WS_VSCROLL) ' AND NOT ws_border)
27. a& = SetWindowPos&(hwnd, 0, 0, 0, 0, 0, 39)
28. msg$ = "Welcome to Translucent Windows Without Borders!"
29. i = 16
30. COLOR &HFFFFFFFF, &H0 ' white foreground, transparent background
31. DO
32.     _LIMIT 60
33.     FGwin& = GetForegroundWindow&
34.     IF hwnd <> FGwin& THEN ' QB64 no longer in focus.
35.         WHILE _MOUSEINPUT: WEND
36.         a& = SetWindowPos&(hwnd, HWND_TOPMOST, 0, 0, 0, 0, SWP_NOMOVE + SWP_NOSIZE + SWP_SHOWWINDOW)
37.         DO: _LIMIT 30: LOOP UNTIL hwnd = GetForegroundWindow&
38.     END IF
39.     IF INKEY$ = CHR$(27) THEN EXIT DO
40.     FOR y = 480 TO 0 STEP -1
41.         FOR x = 640 TO 0 STEP -1
42.             PSET (x, 480 - y), _RGB(y / 2 MOD 256, 100, 200) ' (x MOD 512 XOR y) MOD 256, y MOD 256)
43.         NEXT
44.     NEXT
45.     _PRINTSTRING (92, 1), msg$
46.     _PRINTSTRING (1, 464), "Press Esc to quit."
47.     _PRINTSTRING (250, i), "Hi Chez-Pete!"
48.     _DISPLAY
49.     i = i + 1
50.     IF i > 464 THEN i = 16
51. LOOP
52. SYSTEM
53.  
54. SUB SetWindowOpacity (hwnd AS LONG, Level)
55.     DIM Msg AS LONG
56.     CONST G = -20
57.     CONST LWA_ALPHA = &H2
58.     CONST WS_EX_LAYERED = &H80000
59.     Msg = GetWindowLongA&(hwnd, G)
60.     Msg = Msg OR WS_EX_LAYERED
61.     action = SetWindowLongA&(hwnd, G, Msg)
62.     action = SetLayeredWindowAttributes(hwnd, 0, Level, LWA_ALPHA)
63. END SUB
64.  

Try it in V1.3 or 1.5. It works fine. It does absolutely nothing in V2.0. So does the code need a rewrite, or is this a V2.0 bug?
 
Pete

[Dav]

Hi @Pete.  I get the same running that code as is - works in v1.5, but not in v2.0.  I've found that in QB64 v2 I now *have* to add more _DELAY after the SCREEN call to get windowhandle working.  Maybe v2 sets the screen faster than previous versions?  Anywho, after putting in _DELAY 1 your code works in QB64 v2 now. At least for me in 32-bit Win7.

- Dav

[Pete]

@Dav Hi Dav,

I just tried your _DELAY suggestion. Got it working with...

_DELAY .2
SCREEN _NEWIMAGE(600, 480, 32)

A .1 delay failed. Weirdly, too. Two blank consoles opened. Doubling to .2 corrected everything.

I agree, there seems to be some slower response from this later version. I experienced delay issues with using hardware imaging as well. Windows API calls often need delays as well. I mean the greatest thing ever would be some checking function like _FILEEXISTS() does for files so the next statement in the program flow would not be executed until the API function was returned. I've made a few of those.

I am wondering if this delay needed before rendering the SCREEN image could be tweaked. I don't do graphics, but I didn't think delays to render a screen image would ever be necessary.

Thanks for the solution!

Pete

[SMcNeill]

Another thing I've noticed recently is that QB64 can't decide if programs are aware of hidh resolution scaling or not.  V2.0 didn't upscale screens on my monitor, so QB64 ran under a massive 3840x2160 desktop, with 0 scaling.  V2.0.1 now uses the 100% scaling so it effectively reports my desktop as being 1920x1080 resolution and automatically doubles the size of everything.  Every few upgrades, this behavior seems to toggle back and forth in our versions, with the user having no control over it.  Is this autoscaling an issue messing with things?  Is there some way we can make the option a meta-command to toggle if auto-scale is on, or off, by default in our programs?

From the way it sounds, these things work in older versions, but not newer ones, so it doesn't appear to be any sort of windows system change that's causing the issue.

[Dav]

I forgot to mention, one thing I did notice that can eliminate the need for a small delay, is if you do an _ICON call at the beginning.  I sometimes put _ICON -11 at the top of my test programs, and when doing that I never need to add a _DELAY to prevent issues.

- Dav

[SMcNeill]

@Dav Hi Dav,

I just tried your _DELAY suggestion. Got it working with...

_DELAY .2
SCREEN _NEWIMAGE(600, 480, 32)

A .1 delay failed. Weirdly, too. Two blank consoles opened. Doubling to .2 corrected everything.

I agree, there seems to be some slower response from this later version. I experienced delay issues with using hardware imaging as well. Windows API calls often need delays as well. I mean the greatest thing ever would be some checking function like _FILEEXISTS() does for files so the next statement in the program flow would not be executed until the API function was returned. I've made a few of those.

I am wondering if this delay needed before rendering the SCREEN image could be tweaked. I don't do graphics, but I didn't think delays to render a screen image would ever be necessary.

Thanks for the solution!

Pete

@Pete What you're seeing here has been happening forever and ever in QB64.  It's part of our startup behavior.  If you watch closely, all QB64 programs start out in SCREEN 0. 

_DELAY .2
SCREEN _NEWIMAGE(600, 480, 32)

Even with your little 2-line snippet above, what SCREEN mode was your program in before that _DELAY statement was issued?

Yep!  Your favorite!  SCREEN 0!

So QB64 makes a screen...  Windows gives it a handle...
QB64 frees that screen...  Without a delay, you might get that handle...
Windows frees the handle, Makes a new screen... Without a delay, you might get the blank handle...
Windows gives the new screen its handle...

There's several race conditions at work here, which can result in your _WINDOWHANDLE returning garbage for you. 

My suggestion is to get into the habit of placing a delay of *at least* 0.2 seconds after each SCREEN or _NEWIMAGE statement, before you go referencing it via _WINDOWHANDLE or other means. 

[Pete]

You guys are so lucky I'm not a "developer" on this project because you'd all get this popup at start up...

                    Are you sure you want to leave SCREEN 0? N/N

Pete