SubRollout Issue (doesn't clip its content)

#1

check this snippet:

try(destroydialog rsub) catch()
rollout sub "RO:3954402D" width:180
(
	imgtag img_bt "" width:160 height:400 bitmap:(bitmap 1 1 color:orange) align:#center
	
	on img_bt lbuttondown pos flags do
	(
		format "press .. \t%\n" pos
	)
	on img_bt lbuttonup pos flags do
	(
		format "release .. \t%\n" pos
	)
	
	on sub open do
	(
	)
)
rollout rsub "RO:3954402E" width:191
(
	subrollout rol_sb width:180 height:200 pos:[4,10]
	
	on rsub open do
	(
		AddSubRollout rol_sb sub
	)
)
createdialog rsub
  1. run
  2. scroll orange subrollout down
  3. click main rollout title bar

…

First, you will see that imgtag catches mouse click of its “invisible” part (!!!)
Second, the main rollout loses focus and can’t be moved by dragging titlebar

WTF?
I met this for the first time and honestly can’t find any pure MXS solutions against this behavior. Disabling imgtag is not a solution. I need to keep all controls alive.

Any thoughts, ideas…?

#2

And you should understand that ImgTag is not the problem. Same behavior for other controls. The subrollout container, as I understand it, should clip the working area for the rollouts (controls) contained in it.

#3

As soon as the ImgTag “fully covers” the main rollout title the problem appears.
On max2020 when the rollout appear for the first time and I try to move it - nothing happens.
Second time when I try to move the rollout - it is moved.

EDIT:
Make the main rollout higher - click below the subrollout, without moving it - the click over the ImgTag is detected.

rollout rsub "RO:3954402E" width:191 height:250

EDIT 2:
This problem exist only after the subrollout is scrolled(got focus). What I described in EDIT 1 does not happen when the rollout is shown and I click below the subRol, but if I click inside the subRol or scroll it - clicking inside the main rollout, below the subRoll is detected by the imgTag.

#4

this problem is in 2020 and 2023. I don’t have earlier versions anymore, so I can’t check it.

but I found what it causes. It is specific to the ImgTag control because it captures focus when the mouse button is pressed or scrolled over. In my custom UI controls, I also sometimes capture focus, but this is an optional, and I always release the capture after releasing the mouse button (default behavior). So it’s definitely a bug. The only way to get around this is to release capture if the control captured it. This can be done using the SDK (WIN32 API).

#5

NO :face_with_raised_eyebrow:

Unfortunately this does not work… I force releasing capture, but the problem continues to occur. So it needs something else.

#6

A fix from Autodesk.

#7

here is the test snippet again:

try(destroydialog main_rol) catch()
rollout sub_rol "RO:3954402D" width:120
(
	local dialog = dialog
	
	imgtag img width:100 height:600 bitmap:(bitmap 1 1 color:orange) pos:[10,0]	
	on img lbuttondown pos flags do
	(
		format "down >> %\n" pos
	)
	on img lbuttonup pos flags do
	(
		format "up >> %\n" pos
		--setfocus dialog.panel
	)
	on sub_rol open do
	(
	)
)
rollout main_rol "RO:3954402E" width:140 height:500
(
	subrollout panel width:132 height:300 pos:[4,20]
	on main_rol open do
	(
		addsubrollout panel sub_rol
		sub_rol.dialog = main_rol
	)
)
createdialog main_rol

if you scroll the whole subrollout down you can see that the imgtag continues catching press mouse button events including outside the dialog.

#8

If I add a button below the subRol - I can’t press the button. The subRol must be scrolled, so no part of the imgTag to occupy the area behind the button, then I can press it. :slight_smile:

#9

Confirmed the same behavior on Max 2016.

To me, the problem seems to be related to the control’s mouseout event. In this case, when you move the cursor outside of the imgtag control “real” rect (regardless if it is visible or not), everything works as it should. No need to click or change the control focus.

#10

Not a solution, but a test.

try(destroydialog main_rol) catch()
rollout sub_rol "RO:3954402D" width:120
(
	imgtag img width:100 height:600 pos:[10,0]
	
	on img lbuttondown pos flags do format "down >> %\n" pos
	on img lbuttonup pos flags do format "up >> %\n" pos
)

rollout main_rol "RO:3954402E" width:140 height:500
(
	subrollout panel width:132 height:300 pos:[4,20]
	timer clock interval:0 active:true
	
	local bmp1 = bitmap 1 1 color:green
	local bmp2 = bitmap 1 1 color:orange
	
	on clock tick do
	(
		dlgPos  = getdialogpos  main_rol
		dlgSize = getdialogsize main_rol
		dlgRect = box2 (dlgPos.x+28) (dlgPos.y+54) (dlgSize.x-40) (dlgSize.y-200)
		
		if (contains dlgRect mouse.screenpos) then
		(
			if not sub_rol.img.enabled do
			(
				sub_rol.img.bitmap = bmp1
				sub_rol.img.enabled = true
			)
		)else(
			if sub_rol.img.enabled do
			(
				sub_rol.img.bitmap = bmp2
				sub_rol.img.enabled = false
			)
		)
	)
	
	on main_rol open do addsubrollout panel sub_rol
)
createdialog main_rol
#11

I finally found the exact reason for the misbehavior. I was right, this is the wrong window capture handling. Unfortunately, I can’t solve this problem without fixing the bug in the code. Fortunately, we have the source for the ImgTag control, so I fixed it and recompiled.
At least in my environment it works correct now :stuck_out_tongue_winking_eye: