UI redraw bug

[ISAWHIM]

NOTE: This is on the 1.7.0.0 Beta (Latest release)

The UI does not redraw using the "Clipping" rules, when "%WM_SIZE" is triggered on the parent when triggered from a minimized state "%WM_SYSCOMMAND & %SC_RESTORE".

The UI also does not redraw using the "Clipping" rules, when a window is selected, before moving begins.

I am guessing that the order is... (WM_SYSCOMMAND-SC_RESTORE) triggers (WM_SIZE)... But there is no screen at the point of (WM_SYSCOMMAND-SC_RESTORE), since the window is NO-SIZE. However, even with a MANUAL REDRAW of all window handles at the (WM_SIZE), the window does not get resized.

Uncomment the BEEP's to confirm the event order.

Method to reproduce (Restore Parent non-redraw) situation:
- Run the program
- Maximize any CHILD
- Minimize the PARENT
- Restore the PARENT
- - Results show the PARENT button which is under the Maximized CHILD, is now drawn over the CHILD caption/menu/client-area.

To confirm the issue is specific only to the RESTORE from MINIMIZED PARENT. Maximize the PARENT, and the CHILD and PARENT are both redrawn. Now RESTORE the CHILD while the PARENT is MAXIMIZED, Followed by MAXIMIZE of the CHILD. (That brings the child back up to the size of the client.) Now RESTORE the PARENT, and all is redrawn correctly. (That localizes the issue to MINIMIZE RESTORE, and not MAXIMIZE RESTORE.)

Method to reproduce (Move Child non-redraw) situation:
- Run the program
- Move Child 1, partly over Child 2
- Move Child 2, and you notice that the selected window has not redrawn (To bring it to the top), prior to motion.

Attempted resolution to "Bring to top" prior to motion failed. (Window floats-under control of ThinBASIC, and ignores Z-Order commands until the window is released.)

Suggested possible fix... (In ThinBASIC) At the instance the mouse is clicked, prior to move, if the window is enabled (Valid to get focus), focus should fall to the window, followed by z-order of "TopMost", followed by mouse-move translation, and ending mouse-move translation with z-order of "Top" set to the window. (Bringing it to the "TopMost" should pull the parent through any windows it may be behind, followed by the child being the only container on top, where a "Topmost" dialog may hide the window being moved. Which would return to "Top" so that the "Topmost" dialog would be restored, such as a warning prompt.)


' Empty GUI script created on 10-23-2008 10:08:51 by (ThinAIR)

'#########################
' -- NOTE: All comment are NOT "The way", they are, "The way I have figured-out, through trial and error."
'#########################

USES "UI"

BEGIN CONST
%btnCOMMAND = 1
END CONST

GLOBAL hWnd, hWndChild1, hWndChild2 AS DWORD
GLOBAL ClickWatch AS STRING
GLOBAL MaxWinHandle AS DWORD
GLOBAL hWndWidth, hWndHeight AS DWORD
GLOBAL xTempDWORD, yTempDWORD AS DWORD

FUNCTION TBMAIN()
DIALOG NEW PIXELS, 0, "CWAD Control Center",-1,-1, 350, 150, _
%WS_CLIPCHILDREN OR %WS_CLIPSIBLINGS OR _
%WS_OVERLAPPEDWINDOW, _
0 TO hWnd
' -- Could not figure out how to use these... Had no effect on control or display...
' -- Causes some graphical glitches... Pulling graphics through the child clients...
'%WS_EX_CONTROLPARENT

DIALOG NEW PIXELS, hWnd, "Child 1", 10, 50, 150, 40, _
%WS_CHILD OR %WS_CLIPCHILDREN OR %WS_CLIPSIBLINGS OR _
%WS_OVERLAPPEDWINDOW, _
%WS_EX_CLIENTEDGE TO hWndChild1

DIALOG NEW PIXELS, hWnd, "Child 2", 180, 50, 150, 40, _
%WS_CHILD OR %WS_CLIPCHILDREN OR %WS_CLIPSIBLINGS OR _
%WS_OVERLAPPEDWINDOW, _
%WS_EX_CLIENTEDGE TO hWndChild2
' -- Not sure what this does... Had no effect on control or display...
'%WS_EX_MDICHILD OR

CONTROL ADD BUTTON, hWnd, %btnCOMMAND, "TEST BTN 0", 10, 10, 130, 22, CALL FC_btnCOMMAND()
CONTROL ADD BUTTON, hWndChild1, %btnCOMMAND, "TEST BTN 1", 10, 10, 130, 22, CALL FC_btnCOMMAND()
CONTROL ADD BUTTON, hWndChild2, %btnCOMMAND, "TEST BTN 2", 10, 10, 130, 22, CALL FC_btnCOMMAND()
' -- Show PARENT and CALL...
DIALOG SHOW MODAL hWnd, CALL dlgProc()
DIALOG GET SIZE hWnd TO hWndWidth, hWndHeight
END FUNCTION

' -- Callback Function for dialog
CALLBACK FUNCTION dlgProc()
' -- Test for messages
SELECT CASE CBMSG
CASE %WM_INITDIALOG
' -- Put code to be executed after dialog creation here
' -- Once the parent is SHOWN, Show CHILDREN and CALL...
DIALOG SHOW MODELESS hWndChild1, CALL child1Proc()
DIALOG SHOW MODELESS hWndChild2, CALL child2Proc()
CASE %WM_SYSCOMMAND
SELECT CASE CBWPARAM
CASE %SC_MINIMIZE
CASE %SC_RESTORE
'BEEP
'DIALOG REDRAW hWnd
'DIALOG REDRAW hWndChild1
'DIALOG REDRAW hWndChild2
CASE %SC_MAXIMIZE
CASE %SC_CLOSE
CASE %SC_MOVE
'DIALOG SET TOPMOST hWnd, %HWND_TOP
END SELECT
CASE %WM_SIZING
' -- This event is "Border Resize" with MOUSE
'BEEP
CASE %WM_SIZE
' -- This is ANY resize... Button, Mouse, Minimize, Maximize, Restore
'BEEP
'DIALOG REDRAW hWnd
'DIALOG REDRAW hWndChild1
'DIALOG REDRAW hWndChild2
DIALOG GET SIZE hWnd TO hWndWidth, hWndHeight
IF MaxWinHandle <> hWnd THEN
DIALOG SET SIZE MaxWinHandle, hWndWidth, hWndHeight
DIALOG SET TEXT hWnd, "Parent Size: W=("+hWndWidth+"), H=("+hWndHeight+")"
END IF
CASE %WM_COMMAND
SELECT CASE CBCTL
CASE %btnCOMMAND
IF CBCTLMSG = %BN_CLICKED THEN
ClickWatch += "(BTN:Parent)"
DIALOG SET TEXT hWnd, ClickWatch
' -- Here is where I was "Attempting" to SHOW a CHILD, once it was closed...
' -- I removed all code, since it did nothing.
' -- Tried DIALOG SHOW MODELESS
' -- Tried DIALOG ENABLE
END IF
END SELECT
CASE %WM_CLOSE
DIALOG END CBHNDL
END SELECT
END FUNCTION

' -- Callback Function for child1
CALLBACK FUNCTION child1Proc()
' -- Test for messages
SELECT CASE CBMSG
CASE %WM_INITDIALOG
' -- Put code to be executed after dialog creation here
CASE %WM_SYSCOMMAND
SELECT CASE CBWPARAM
CASE %SC_MINIMIZE
IF MaxWinHandle = hWndChild1 THEN MaxWinHandle = hWnd
CASE %SC_RESTORE
IF MaxWinHandle = hWndChild1 THEN MaxWinHandle = hWnd
CASE %SC_MAXIMIZE
MaxWinHandle = hWndChild1
CASE %SC_CLOSE
CASE %SC_MOVE
DIALOG SET TOPMOST hWndChild1, %HWND_TOP
END SELECT
CASE %WM_SIZING
' -- This event is "Border Resize" with MOUSE
CASE %WM_SIZE
' -- This is ANY resize... Button, Mouse, Minimize, Maximize, Restore
CASE %WM_COMMAND
SELECT CASE CBCTL
CASE %btnCOMMAND
IF CBCTLMSG = %BN_CLICKED THEN
ClickWatch += "(BTN:Child 1)"
DIALOG SET TEXT hWnd, ClickWatch
END IF
END SELECT
CASE %WM_CLOSE
DIALOG SET TOPMOST hWnd, %HWND_TOP
END SELECT
END FUNCTION

' -- Callback Function for child2
CALLBACK FUNCTION child2Proc()
' -- Test for messages
SELECT CASE CBMSG
CASE %WM_INITDIALOG
' -- Put code to be executed after dialog creation here
CASE %WM_SYSCOMMAND
SELECT CASE CBWPARAM
CASE %SC_MINIMIZE
IF MaxWinHandle = hWndChild2 THEN MaxWinHandle = hWnd
CASE %SC_RESTORE
IF MaxWinHandle = hWndChild2 THEN MaxWinHandle = hWnd
CASE %SC_MAXIMIZE
MaxWinHandle = hWndChild2
CASE %SC_CLOSE
CASE %SC_MOVE
DIALOG SET TOPMOST hWndChild2, %HWND_TOP
END SELECT
CASE %WM_SIZING
' -- This event is "Border Resize" with MOUSE
CASE %WM_SIZE
' -- This is ANY resize... Button, Mouse, Minimize, Maximize, Restore
CASE %WM_COMMAND
SELECT CASE CBCTL
CASE %btnCOMMAND
IF CBCTLMSG = %BN_CLICKED THEN
ClickWatch += "(BTN:Child2)"
DIALOG SET TEXT hWnd, ClickWatch
END IF
END SELECT
CASE %WM_CLOSE
DIALOG SET TOPMOST hWnd, %HWND_TOP
END SELECT
END FUNCTION

' -- Callback Function for btnCOMMAND
CALLBACK FUNCTION FC_btnCOMMAND()
IF CBMSG = %WM_COMMAND THEN
SELECT CASE CBCTL
CASE %btnCOMMAND
IF CBCTLMSG = %BN_CLICKED THEN
If LEN(ClickWatch) > 0 THEN ClickWatch =""
ClickWatch += "(BTN:ALL)"
DIALOG SET TEXT hWnd, ClickWatch
END IF
END SELECT
END IF
END FUNCTION

Add one more bug to the UI...

Button on PARENT floats above CHILDREN when MOUSE-OVER. (Pulls through child.)

Steps to reproduce issue...
- Move Child 1 half-way over the button on PARENT
- Move mouse over button. (Button pulls through child.)
- Move mouse over Child 1 Minimize, Maximize, Close buttons on menu. (If they cover the button, those buttons will pull through the button on the parent, which pulled through the child.)

[ISAWHIM]

Fixed issue with the button redraw...





CONTROL ADD BUTTON, hWnd, %btnCOMMAND, "TEST BTN 0", 10, 10, 130, 22, _
%WS_CLIPCHILDREN OR %WS_CLIPSIBLINGS, _
CALL FC_btnCOMMAND()



Added ClipChildren and ClipSiblings... (I didn't realize they were an option.)

Still looking into the window z-order issue, and why I can't make one of the children "Non-greyed" or Active. (Which might be the underlying issue to the layering.)

[ErosOlmi]

Jason,

you are the first veturing into this direction (before than me) in thinBasic.
I have to study it, so I need a little time.

Regarding %WS_CLIPCHILDREN OR %WS_CLIPSIBLINGS in BUTTON, even if seems to do the job, they were not supposed to work with BUTTONs but with DIALOGs. So again I will have to study MS docs.

Eros

[ISAWHIM]

Jason,

you are the first venturing into this direction (before than me) in thinBasic.
I have to study it, so I need a little time.

Regarding %WS_CLIPCHILDREN OR %WS_CLIPSIBLINGS in BUTTON, even if seems to do the job, they were not supposed to work with BUTTONs but with DIALOGs. So again I will have to study MS docs.

Eros



That fixed all the button issues... even drawing them on other forms, which normally drew a big ugly outline around them. (Which I suspect was a redraw issue also.)

I am looking into the issue with the "Not Activated" title-bars. (They work fine, because WIN_FLASH will turn them dark, then turn them greyed-out again. They were not like that when I had them as children, where they were floating, just once I threw them into the window as MODELESS.)

I am thinking that I might just turn them back into normal windows, and confine them to an area... that will simulate what I want, and give me full control.

Found mention of the scroll-bars issue also... the scrollbars have to be set, but a CSC_ command triggers when it should turn on. These just stay on constantly if you turn them on.

This may have something to do with it...
http://msdn.microsoft.com/en-us/library/ms644911(VS.85).aspx

We can create MDI windows, but I don't see an MDI controller. (Though, it has the same issue with non-MDI parent/children.)


As the client window processes this message, it sends WM_MDIACTIVATE to the child window being deactivated and to the child window being activated. The message parameters received by an MDI child window are as follows:

wParam
Handle to the MDI child window being deactivated.

lParam
Handle to the MDI child window being activated.

An MDI child window is activated independently of the MDI frame window. When the frame window becomes active, the child window last activated by using the WM_MDIACTIVATE message receives the WM_NCACTIVATE message to draw an active window frame and title bar; the child window does not receive another WM_MDIACTIVATE message.

[ErosOlmi]

Ok, I got the BUTTON problem cleared in my kind.


All %BS_... button styles change only 2 bytes (least significant part) of the 4 (LONG) bytes available for BUTTON control Style.
This left other 2 bytes free for additional options. All %WS_... equates (WS stands for Windows Styles) change 2 bytes (most significant part) of the style.
More: all controls are in reality Windows. So it seems %BS_... and %WS_... can be specified at the same time


That said, what does the trick is %WS_CLIPSIBLINGS:

Clips child windows relative to each other; that is, when a particular child window receives a %WM_PAINT message, the %WS_CLIPSIBLINGS style clips all other overlapping child windows out of the region of the child window to be updated. If %WS_CLIPSIBLINGS is not specified and child windows overlap, it is possible, when drawing within the client area of a child window, to draw within the client area of a neighboring child window.


I'm checking the rest.