How to get the visible screen handle?

[SMcNeill]

So here's a question which I just can't seem to sort out at the moment:  How do we get the handle of the screen which is currently displaying on our monitor?

Code: [Select]

FOR I = 1 to 10
    Screen(i) = _NEWIMAGE(640,480,32)
NEXT
SCREEN Screen(RND*10+1)

Now, what command can I use to get the handle of the screen which is now visible in the cheesy code concept above?

I was working on a program where we make input boxes and such, and I want them to be visible *only if the screen they're anchored to is the active display screen*, and I just can't figure out how the heck I'd get the handle for the currently visible screen.

Any thoughts?  Am I overlooking something blazingly simple to get that handle?  Or do I need to do some digging and see if I can pull that information out of libqb.cpp somewhere for my needs?


EDIT: A quick test shows that we can get that info using _MEM commands.  Is there another keyword/combo which does the same for us, or is this another thing which can currently only be accomplished with _MEM:

Code: QB64: [Select]

1. FOR I = 1 TO 10
2.     S(I) = _NEWIMAGE(640, 480, 32)
3. NEXT
4. x = RND * 10 + 1
5. SCREEN S(x)
6. DIM m AS _MEM
7. m = _MEMIMAGE(0)
8. PRINT m.IMAGE, S(x)

[FellippeHeitor]

Print _DEST?

[SMcNeill]

Print _DEST?

_DEST May not be the visible screen. 

[FellippeHeitor]

? _Display

[Cobalt]

I'm pretty sure that _DISPLAY is supposed to return the current layer that is being output on the screen.

make a few image handles and a screen image, then check _display, change the _dest then check _display again.

_DISPLAY should return the current handle of the layer, or image, being used for screen output. thats why I tend to have LAYER(0) = _DISPLAY.

[SMcNeill]

? _Display

I’ll test it later.  I’m a little concerned about: “Returns 0 if in the default screen image.”

Some testing of when it returns that zero seems warranted.  Many thanks though; I’d forgotten we even had a _DISPLAY function.

[Petr]

In each case, the index number under which the screen is located is known. Isn't this a bit of a problem that doesn't exist? :) Next - you can reliably save the current screen number before leaving this screen with _DEST and _SOURCE, and then restore it with this variable.

But definitely thank you for the demonstration of the MEM solution. I had no idea that this could with MEM be  done. Thank you, Steve.

[SMcNeill]

In each case, the index number under which the screen is located is known. Isn't this a bit of a problem that doesn't exist?

Here's a very short demo for you of what I'm using this for:

Code: QB64: [Select]

1. TYPE Window_Type
2.     InUse AS INTEGER
3.     X AS INTEGER
4.     Y AS INTEGER
5.     Wide AS INTEGER
6.     High AS INTEGER
7.     Anchor AS INTEGER
8. END TYPE
9.  
10. DIM SHARED Windows(1 TO 100) AS Window_Type
11.  
12.  
13. DisplayScreen = _NEWIMAGE(800, 600, 32)
14. TestScreen = _NEWIMAGE(800, 600, 32)
15.  
16. SCREEN DisplayScreen
17.  
18. WinHandle = MakeWindow(100, 100, 300, 300, DisplayScreen) 'Make a window and anchor it to the display screen
19.  
20. where = DisplayScreen 'we want to put our workscreen on the display screen normally
21.  
22. DO
23.     CLS
24.     _LIMIT 30
25.     k = _KEYHIT
26.     SELECT CASE k
27.         CASE 32 'space to toggle between two visible screens
28.             IF where = DisplayScreen THEN where = TestScreen ELSE where = DisplayScreen
29.             SCREEN where
30.         CASE 27 'escape
31.             SYSTEM
32.     END SELECT
33.     DrawWindows
34.     _DISPLAY
35. LOOP
36.  
37. SUB DrawWindows
38.     FOR i = 1 TO UBOUND(Windows)
39.         IF Windows(i).InUse THEN
40.             IF Windows(i).Anchor = VisibleScreen THEN
41.                 LINE (Windows(i).X, Windows(i).Y)-STEP(Windows(i).Wide, Windows(i).High), &HFFFFFF00, BF 'draw a yellow box on the screen if the screen, just for this demo.
42.             END IF
43.         END IF
44.     NEXT
45. END SUB
46.  
47.  
48. FUNCTION MakeWindow (X, Y, Wide, High, Anchor)
49.     FOR i = 1 TO UBOUND(Windows)
50.         IF Windows(i).InUse = 0 THEN 'it's a free window handle
51.             Windows(i).InUse = -1
52.             Windows(i).X = X
53.             Windows(i).Y = Y
54.             Windows(i).Wide = Wide
55.             Windows(i).High = High
56.             Windows(i).Anchor = Anchor
57.             MakeWindow = i 'assign a value to this new window handle
58.             EXIT FUNCTION
59.         END IF
60.     NEXT
61. END FUNCTION
62.  
63.  
64. FUNCTION VisibleScreen
65.     STATIC M AS _MEM 'no need to allocate and free this mem block over and over.  Just save one and reuse it until the end of time...
66.     M = _MEMIMAGE(0)
67.     VisibleScreen = M.IMAGE
68. END FUNCTION

Not much to this demo, but it highlights the uses for me quite well. 

First, we make a window, and we ANCHOR it to an existing object on the screen -- in this case, we anchor it to our DisplayScreen.  Now, only when the DisplayScreen is the active, visible screen, do we draw this window. (In this case, just a yellow square on the screen.)

The concept here is that we should be able to anchor one object in relation to another....

A window anchors to the display screen.  Only when the display is active and showing, do we draw that window.
After this, we can anchor buttons to the window...  Only when the window is active and showing, do we draw these buttons.

It's the backbones of a quick and easy way to create some very fast forms which we can minimize or move across the screen, which all builds upon the concept, "Which is my currently visible screen?  I only want to draw these forms/objects if the visible screen is the one which the base window they're built upon is the current display."  ;)

[Petr]

Oh, thank you for the demonstration. You seem to want 100 screens that will have different Windows array index numbers, regardless of the order in which they were called. This explains the construction of the MakeWindow function.

Obviously you want to have the dialogs drawn in memory so that they do not draw but display directly when needed. You will also direct mouse and keyboard control to that dialog. Good. Wouldn't _PUTIMAGE serve the same goal? Well, I'll be surprised, I don't know exactly where you're going.

[SMcNeill]

Oh, thank you for the demonstration. You seem to want 100 screens that will have different Windows array index numbers, regardless of the order in which they were called. This explains the construction of the MakeWindow function.

Obviously you want to have the dialogs drawn in memory so that they do not draw but display directly when needed. You will also direct mouse and keyboard control to that dialog. Good. Wouldn't _PUTIMAGE serve the same goal? Well, I'll be surprised, I don't know exactly where you're going.

The idea is to take this basic concept and then expand upon it.   For starters, we can anchor windows to any of our main screens, which we can then swap between as we want.  Then let's create an ImageArea, Button, and TextArea and anchor it to that one window...

Now, if the screen is visible (and the window is visible), we draw that window and all its associated objects to the screen...

What it'll end up giving me, when I'm finished with it, is a simple little window system where I can create quick little forms and pop them up and free them, as needed and on call, really quickly.   



And I don't really foresee having 100 screens, even though I might have 100 windows which work across half a dozen screens.  If I was to import the QB64 IDE into this concept, the main screen would be where your text and all is located.  Another screen might be an Option screen, which had 5 or 6 windows anchored to it, completely independent to the main screen, which we make visible/invisible according to which option we selected and wanted to alter.  Another screen might be the help screen, which would work the same way...

Just a few screens with various distinct windows anchored to them, which we can then hide/show on demand.
Then with those windows, when they're visible, we anchor objects to them, such as buttons, labels, radial options, image frames, ect...

Mouse and keyboard would respond to which window/options are visible and take precedence.  ESCAPE might close the COLOR DIALOG window, or it might try and close the whole IDE itself, if nothing is visible...

Each window would have its own little mouse/keyboard handling routine associated with it, and the window loaded last would take precedence.  (Say I have 2 windows which can make use of the ESCAPE key to close them, the one loaded last -- highest Z-Order -- would take precedence over the other.)

I'm just working off the concept that objects anchor off other objects, and only if those other objects are visible, can we draw/interact with them.

Hide a screen, you hide all the objects linked to that screen.
Hide a window, you hide all the objects linked to that window...

In the end, it's just me playing around with a window/layering system for inserting quick forms and popups into one of my projects.  ;)

[Petr]

Ok. Then, I know you will do better it than I do, but there is a finished solution for assigning a number to a window (determining whether it is active or not): In this program, number 1 means the window is on top.
The windows are then drawn so that the index number one is drawn last - and therefore is draw always on top. It is a program from the development of my Object Editor. Maybe it is useful for you:  https://www.qb64.org/forum/index.php?topic=1511.msg107668#msg107668