How to ensure that label 2 is displayed above label 1

[Professor_Bernd]

Hello.

For PSPad4AutoIt3 I'm writing on a CallTipViewer, like in SciTE. Here is a screenshot.

Spoiler

The CallTip is the small floating window that displays the function syntax. The current parameter is shown in red.

I had worked out a solution all the time with 3 labels, Lbl_Left (black), Lbl_Mid (red) and Lbl_Right (black). These were displayed next to each other so that they did not overlap. (As in the tip from @Melba23 , who said in 2011 about this topic "DO NOT OVERLAP CONTROLS"! )

Unfortunately the labels flicker when the user runs with the caret/cursor quickly through the text. The flickering can be avoided if I use only 2 labels, 1 black and 1 red, and the red label is always in front of the black label. The code for this is too complex to post it here. But that's not the problem, I've already created the code, and it works great!

The code works in my tests, on my Windows. But what about other Windows and "do not overlap the controls"? I have read through many threads, and learned a lot. But the more I know, the more uncertain I get.

Spoiler

 

These are some of the threads I have studied.

 

 

 

Ticket #2287 GUICtrlSetState($controlID, $GUI_ONTOP) Doesn't set on top

 

 

 

 

I would like to use the solution with the 2 overlapping labels, because it almost doesn't flicker. What do you think? How can I make sure that the red label always appears above the black one? Is it enough if I keep the order when creating the labels: First the black label, then the red one?

 

Bernd.

[Professor_Bernd]

Push.

 

[Aelc]

Code?

[Professor_Bernd]

What code?

On 3/29/2020 at 12:45 AM, Professor_Bernd said:

The code for this is too complex to post it here. But that's not the problem, I've already created the code, and it works great!

 

[Aelc]

10 minutes ago, Professor_Bernd said:

What code?

 

I can't figure out your problem or testing something when i don't have any context... You can't take a snippet?  

 

Blind i would say why don't use GDI+ ? There you could workaround with buffers and wouldn't have any flicker

 

EDIT: GDI+ is the mostly solution for flicker and draw on top  

Edited May 12, 2020 by Aelc

[Professor_Bernd]

Here is a code snippet.

$g_hGui = GUICreate("Demo", 260, 100)
$g_MyLabel_1 = GUICtrlCreateLabel("This is a black label with a little bit text", 10, 10, 220)
$g_MyLabel_2 = GUICtrlCreateLabel("Red label", 60, 10, 50)
GUICtrlSetColor($g_MyLabel_2, 0xFF0000)

GUISetState(@SW_SHOW, $g_hGui)

Global $bIncrease = True

For $i = 1 to 10
  Sleep(2000)

  If $bIncrease Then
    GUICtrlSetPos($g_MyLabel_1, 10, 10, 240)
    GUICtrlSetPos($g_MyLabel_2, 80, 10, 45)
  Else
    GUICtrlSetPos($g_MyLabel_1, 10, 10, 220)
    GUICtrlSetPos($g_MyLabel_2, 60, 10, 50)
  EndIf
  $bIncrease = Not $bIncrease
Next

While 1
  If GUIGetMsg() = -3 Then ExitLoop
WEnd

 

GDI+ is not a solution for me, because my skills are not sufficient to position the font pixel-exactly. But my skills are sufficient to position two labels pixel-exactly and flicker-free every time they are filled with text.

Edited May 12, 2020 by Professor_Bernd

[Aelc]

#include <GUIConstants.au3>
#include <winapi.au3>
$g_hGui = GUICreate("Demo", 260, 100)
$g_MyLabel_2 = GUICtrlCreateLabel("Red label", 60, 10, 50)
$g_MyLabel_1 = GUICtrlCreateLabel("This is a black label with a little bit text", 10, 10, 220)
DllCall('user32.dll', 'bool', 'SetWindowPos', 'int',GUICtrlGetHandle($g_MyLabel_2), 'int',GUICtrlGetHandle($g_MyLabel_1), 'int', 0, 'int', 0,'int', 0, 'int', 0,'uint',3)


GUISetState(@SW_SHOW, $g_hGui)
GUICtrlSetColor($g_MyLabel_2, 0xFF0000)

While 1
  If GUIGetMsg() = -3 Then ExitLoop
WEnd

That does the trick   You can read it in MSDN.  Window = Handle = GUICTRLGetHandle. I didn't tried how it is with more than 2 Labels but i guess should going like this  too... 

Edit: So it won't matter when they are drawn. Normally it should work if you draw the "background" label first.

 

Edited May 12, 2020 by Aelc

[Professor_Bernd]

I think we are talking past each other.  I know the function you proposed and also the corresponding UDF.

#include <WinAPISysWin.au3>
_WinAPI_SetWindowPos ( $hWnd, $hAfter, $iX, $iY, $iCX, $iCY, $iFlags )

The Z-Order is already defined when creating the labels. So no extra Z-ordering is necessary. Or does it? 

What I really want to know is whether the Z-Order will be retained. So answers like: "No problem, I've done this a thousand times, the two labels don't change the Z-Order on their own" or "Oh yes, that's a problem. On Windows XX the Z-Order of 2 labels stays the same, on Windows YY it is sometimes like this, sometimes like this, on Win ZZ it is the other way round. You have to reset the Z-order every time an X event occurs."

Because my CallTip window is a special window that must never get the focus, I have to be very careful with commands that change the Z-Order of controls. Hence my question if any problems are to be expected. It works for me on my PC and a few test PCs, but that doesn't mean that it works on all other PCs.

Thanks for your effort! I'm glad that you answered me!

[Aelc]

Well then 

On 3/29/2020 at 12:45 AM, Professor_Bernd said:

How can I make sure that the red label always appears above the black one? Is it enough if I keep the order when creating the labels: First the black label, then the red one?

That's what i talked about.  You can be sure if this is called i would claim ... (i mean somewhere on this planet there is definitly an exception and i can't talk for all devices/windows versions)

At least i don't know how your program works or where it's based on (multiple GUIs/instances or something), but i wouldn't have any idea what exactly could change that order... (exceptions prove the rule)

But at least for giving you a single feedback  :

I just can say i never had problems with z ordering called one after one. Mostly used Win7 ( like all versions  Pro and above ) Also on my Win 10 laptop. And your example script worked pretty fine  

PS: Next time we talk in german or some other language maybe we understand us then   

Greetings  ✌️

Edited May 12, 2020 by Aelc

[Professor_Bernd]

These are exactly the answers I was hoping for, based on your experience! Now we understand each other.  Thanks for your answer!

15 minutes ago, Aelc said:

PS: Next time we talk in german or some other language maybe we understand us then   

German is very pleasant for me (it is my mother tongue)!

Was ist die Welt doch so klein!

 

Edited May 12, 2020 by Professor_Bernd

[Aelc]

hehe jaa das ist sie  

[iAmNewbe]

I use often a label behind another as a background border for the top label's.  I do this because using GDI+  you have to redraw the lines, rectangles when you move the GUI window or part of it off the screen or restore from minimize state.  Don't have to do that with labels.

Two things to note with keeping labels on top in correct order, they pretty much stay as created so if you create the background label first and each "layer" of label in the correct order they pretty much stay there.  Other thing is to use the on top flag for the control state, use this at the time of needing to force a control on top of z-order. Using it at create time does nothing. 

GUICtrlSetState(-1, $GUI_ONTOP)   I think is it.  You have to keep calling this each time you need to force a control to the top of the GUI window, it is not a one and done thing.

Edited July 19, 2020 by iAmNewbe

[iAmNewbe]

I didn't look at the post dates of this thread before posting..  Sorry for bringing old thread back to top...

[Professor_Bernd]

8 hours ago, iAmNewbe said:

Sorry for bringing old thread back to top...

This is really no problem!  I was looking for answers that reflect the experiences of users. Aelc wrote about 1 experience, the second one is now yours. Great! 👍

I already knew technical solutions to force the Z-Order after creating the labels, but that wasn't the point. It was primarily about finding out if it was enough to set the labels in the desired Z-Order when creating them. That's why I'm happy about your answer, because this is the kind of answer I was hoping for. Now I have 3 experiences, with my own, and I've been using it this way for over 4 months without any problems.

Thank you very much for the info about your experience values!

Bernd.