Window doesnt update client area after being resized with _winapi_setwindowspos or winmove()

[Aktonius]

I v been trying to figure this java window for some time now which doesnt respond well to winapi resizing. But i think its beyond me to figure it out.

It seems that it doesnt respond well to winapi resizing and doesnt repaint client area well.

This is how it looks after using winapi resizing...

As you can see its missing pretty much half of the table

Trying it with simple code...

#include <winapi.au3>
#include <WindowsConstants.au3>

$hWindow = WinGetHandle("Abilene")

_WinAPI_MoveWindow($hWindow, 0, 0, 518, 395, True) ; Using true to force repaint doesnt help much

Also tried to use

#Include <WinAPI.au3>
#include <WindowsConstants.au3>
#include <Constants.au3>

$hWindow = WinGetHandle("Abilene")


_WinAPI_SetWindowPos($hWindow, 0, 0, 0, 518, 395, $SWP_FRAMECHANGED)

It seems its refusing setpos because of some internal java proc which is only way to handle this window resizing or perhaps something could be done about this?

Edited August 1, 2011 by Aktonius

[Valik]

Can you manually resize the window? If you can't then it's an application design decision you need to live with.

[Aktonius]

It is possible to resize it manually by click-dragging right corner(this is how client area gets updated perfectly). After that these are the messages sent/received

<00240> 00240646 S WM_WINDOWPOSCHANGING lpwp:0254F52C

<00241> 00240646 S WM_GETMINMAXINFO lpmmi:0254EE78

<00242> 00240646 R WM_GETMINMAXINFO lpmmi:0254EE78

<00243> 00240646 R WM_WINDOWPOSCHANGING

<00244> 00240646 S WM_NCCALCSIZE fCalcValidRects:True lpncsp:0254F500

<00245> 00240646 R WM_NCCALCSIZE fuValidRect:0000 lpncsp:0254F500

<00246> 00240646 S WM_NCPAINT hrgn:00000001

<00247> 00240646 R WM_NCPAINT

<00248> 00240646 S WM_ERASEBKGND hdc:D201105B

<00249> 00240646 R WM_ERASEBKGND fErased:True

<00250> 00240646 S WM_WINDOWPOSCHANGED lpwp:0254F52C

<00251> 00240646 S WM_SIZE fwSizeType:SIZE_RESTORED nWidth:525 nHeight:376

<00252> 00240646 S WM_IME_NOTIFY dwCommand:IMN_SETCOMPOSITIONWINDOW dwCommand:0000000B dwData:00000000

<00253> 00240646 S WM_IME_NOTIFY dwCommand:000F dwCommand:0000000F dwData:2414057B

<00254> 00240646 R WM_IME_NOTIFY

<00255> 00240646 R WM_IME_NOTIFY

<00256> 00240646 R WM_SIZE

<00257> 00240646 S WM_WINDOWPOSCHANGING lpwp:0254F154

<00258> 00240646 R WM_WINDOWPOSCHANGING

<00259> 00240646 S WM_NCCALCSIZE fCalcValidRects:True lpncsp:0254F128

<00260> 00240646 R WM_NCCALCSIZE fuValidRect:0000 lpncsp:0254F128

<00261> 00240646 S WM_NCPAINT hrgn:00000001

<00262> 00240646 R WM_NCPAINT

<00263> 00240646 S WM_ERASEBKGND hdc:A9010B83

<00264> 00240646 R WM_ERASEBKGND fErased:True

<00265> 00240646 S WM_WINDOWPOSCHANGED lpwp:0254F154

<00266> 00240646 R WM_WINDOWPOSCHANGED

<00267> 00240646 R WM_WINDOWPOSCHANGED

<00268> 00240646 S WM_IME_NOTIFY dwCommand:IMN_SETCOMPOSITIONWINDOW dwCommand:0000000B dwData:00000000

<00269> 00240646 S WM_IME_NOTIFY dwCommand:000F dwCommand:0000000F dwData:2414057B

<00270> 00240646 R WM_IME_NOTIFY

<00271> 00240646 R WM_IME_NOTIFY

Maybe this could be simulated by sending messages?

Edited August 1, 2011 by Aktonius

[Valik]

I'm curious why you aren't using WinMove(). Anyway, most of those messages are generally internally. You would be better serve comparing what happens when you use something like WinMove() with what happens when you do it manually and try to spot the missing message.

[jormatus]

Aktonius, did you ever solve this?