Jump to content
Sign in to follow this  
vonc

GUICtrlSetResizing policy after ControlMove

Recommended Posts

Hi,

The following test script points out a weird resize behaviour (with latest beta up to 3.1.1.21)

The context is a control whose width should follow the width of the windows, respecting its initial position (that is 10 pixels from left and right borders)

1/ ControlMove (click on first button)

If I ControlMove (resize) the control (now the control is positionned i.e. 50 pixels from left and right borders), and reset (or try to) the GUICtrlSetResizing policy, the control resume its former position (10 pixels from left and right borders) at the next window resize. :(

UPDATE:

with GUICtrlSetPos instead of ControlMove, it works... if the window has not be resized first

Actually, what you get is the scenario I describe in step 2

2/ ControlDelete

The idea that comes in mind to avoid that defect is to delete the control, recreate it with the new desire position, set the GUICtrlSetResizing policy on it.

And it works!

Only if you have not increase the width of the window first.

Because if you have, the control suddenly increases its lenght (breaking the new 50 pixels from right border policy) because it seems to want to retrieve its original lenght when the user *decrease* the width of the window to its original and minimal window width. :

Practical illustration:

For a initial 400 pixels width window,

2.1/ first increase the width of the window by 100 pixels

2.2/ then the control is deleted and recreated (50 pixels from each borders => width 400)

2.3/ then the window is again increased from 100 => ERROR: the control has not a width of 500 but of 600, because that way, when the user restore the initial and minmal width of the window (400), the control will retrieve its initial second width of 400 (when it was recreated)

If you didnt go through step 2.1, then step 2.3 works

Is there a way to enforce the GUICtrlSetResizing policy ? :(

#include "GUIConstants.au3"
Opt ("GUIOnEventMode", 1); Allow for OnEvent mode notification
$title = "test ControlMove & Resize"
$gui = GUICreate($title, 400, 100, -1, -1, $WS_SIZEBOX)
$pos = WinGetPos($gui)
GUISetOnEvent($GUI_EVENT_CLOSE,"_Exit",$gui)
GUISetOnEvent($GUI_EVENT_RESIZED,"_onresize",$gui)

$button_move = GUICtrlCreateButton("MoveResize",10,10,100,20)
GUICtrlSetOnEvent($button_move,"_actiononmove")
GUICtrlSetResizing($button_move,BitOR($GUI_DOCKMENUBAR,$GUI_DOCKLEFT,$GUI_DOCKWIDTH))

$button_delete = GUICtrlCreateButton("MoveDelete",290,10,100,20)
GUICtrlSetOnEvent($button_delete,"_actionOnDelete")
GUICtrlSetResizing($button_delete,BitOR($GUI_DOCKMENUBAR,$GUI_DOCKRIGHT,$GUI_DOCKWIDTH))

$label_width = GUICtrlCreateLabel("", 120,10,160,20)
GUICtrlSetResizing($label_width,BitOR($GUI_DOCKMENUBAR,$GUI_DOCKLEFT,$GUI_DOCKRIGHT))
GUICtrlSetBkColor($label_width,0xFFFF00)

$label = GUICtrlCreateLabel("Test", 10,40,$pos[2]-25,20)
GUICtrlSetBkColor($label,0xFF00FF)
;GUICtrlSetResizing($label,BitOR($GUI_DOCKLEFT,$GUI_DOCKHEIGHT,$GUI_DOCKTOP,$GUI_DOCKRIGHT))
GUICtrlSetResizing($label,BitOR($GUI_DOCKMENUBAR,$GUI_DOCKLEFT,$GUI_DOCKRIGHT))


GUISetState(@SW_SHOW, $gui)

$state = -1
while 1
    Sleep(10)
WEnd

Func _actiononmove()
    GUISwitch($gui)
;ControlDisable($title,"",$label)
    $pos = WinGetPos($title)
    GUICtrlSetPos($label,50,40,$pos[2]-100,20)
    ;ControlMove($title,"",$label,50,40,$pos[2]-100,20)
    GUICtrlSetData($label,"Test MOVED and RESIZED")
;GUICtrlSetResizing($label,BitOR($GUI_DOCKLEFT,$GUI_DOCKHEIGHT,$GUI_DOCKTOP,$GUI_DOCKRIGHT))
    GUICtrlSetResizing($label,BitOR($GUI_DOCKMENUBAR,$GUI_DOCKLEFT,$GUI_DOCKRIGHT))
    $ctrlpos = ControlGetPos($title,"",$label)
    GUICtrlSetData($label_width,"width after ctrl move & resize: "&$ctrlpos[2])
;ControlEnable($title,"",$label)
EndFunc

Func _actionOnDelete()
    GUISwitch($gui)
;ControlDisable($title,"",$label)
    GUICtrlDelete($label)
    $pos = WinGetPos($title)
    $label= GUICtrlCreateLabel("Test RECREATED NEW POS, RESIZED",50,40,$pos[2]-100,20)
    GUICtrlSetBkColor($label,0xFF00FF)
    GUICtrlSetResizing($label,BitOR($GUI_DOCKLEFT,$GUI_DOCKHEIGHT,$GUI_DOCKTOP,$GUI_DOCKRIGHT))
    GUICtrlSetResizing($label,BitOR($GUI_DOCKMENUBAR,$GUI_DOCKLEFT,$GUI_DOCKRIGHT))
    $ctrlpos = ControlGetPos($title,"",$label)
    GUICtrlSetData($label_width,"width after ctrl delete & resize: "&$ctrlpos[2])
;ControlEnable($title,"",$label)
EndFunc

Func _onresize()
    $ctrlpos = ControlGetPos($title,"",$label)
    GUICtrlSetData($label_width,"width after window resize: "&$ctrlpos[2])
EndFunc

Func _Exit()
    Exit
EndFunc
Edited by vonc

-- VonCMinefield

Share this post


Link to post
Share on other sites

I should have stated in the doc that Control... can interfere with GUI functions.

It is always best to use the GUI functions when they exist in your case GUICtrlSetPos or GUICtrlDelete.

Perhaps there are bugs specifically with the resizing stuff but at least I can manage them.

Remember GUICtrlSetResizing function is design to do the job without having to do it by the script.

If basic GUI resizing functions does not fit your need the best is to stop AutoIT doing it and do it your self.

I hope you can manage to do what you want. :(

Share this post


Link to post
Share on other sites

Argh... :(

GUICtrlSetPos()

Right...

It seems to work perfectly :(

Sorry, I only know Autoit since last week, so... Anyway, thank you Jpm for pointing that out for me

I do believe that the second scenario (involving GuiCtrlDelete) does underline a bug, though...


-- VonCMinefield

Share this post


Link to post
Share on other sites

I have update the script by using GUICtrlSetPos

I have still the bug described in scenario 2 (cf. fist post of this thread) :(

I am more than willing to do the job of the GUICtrlSetResizing myself, but what stops me is:

"How track the resizing in progress of a window ?"

The function set with a

GUISetOnEvent($GUI_EVENT_RESIZED,"_onresize",$gui) is only called at the end of a resize, not *during* a resize...

Any idea on that ?


-- VonCMinefield

Share this post


Link to post
Share on other sites

I have update the script by using GUICtrlSetPos

I have still the bug described in scenario 2 (cf. fist post of this thread)  :(

I am more than willing to do the job of the GUICtrlSetResizing myself, but what stops me is:

"How track the resizing in progress of a window ?"

The function set with a

GUISetOnEvent($GUI_EVENT_RESIZED,"_onresize",$gui) is only called at the end of a resize, not *during* a resize...

Any idea on that ?

<{POST_SNAPBACK}>

I agree i can have action only when the resize is done. I think it was too much overhead to do it during the resizing.

For the Bug that's will be very difficult to correct because the resizing process is done with the info memorize at the first apparition of the window.

So if you change the size the original information are used. Now if you delete after resizing I have almost no way to recalculate what can be the resizing information regarding the original window size because the new created control obviously will be sized acording to the new size.

I prefer to stay with the current implementation putting a warning in the doc, leaving the resizing to simpler case as today i.e. the controls that's were defined before the first show.

I hope you agree :(

Share this post


Link to post
Share on other sites

I  agree i can have action only when the resize is done. I think it was too much overhead to do it during the resizing

Aaaargh.... :(

That means the only dynamic resizing is defined with the (unperfect imho) GUICtrlSetResizing and not by a user function ?

That is sad...

For the Bug  that's will be very difficult to correct because the resizing process is done with the info memorize at the first apparition of the window.

Re-aaargh.... I suppose it is a Microsoft limitation, not a limitation of your implementation, right ? :(

In the scenario I described, I do not care about "the resizing information regarding the *original* window size": since there is no DOCKWIDTH, I just want the control to resize itself according to the *current* width of the window

I prefer to stay with the current implementation putting a warning in the doc, leaving the resizing to simpler case as today i.e. the controls that's were defined before the first show.

I hope you agree ;)

Mmmm... let me think :

<{POST_SNAPBACK}>

NO :P I do not agree, but may be fixing my particular scenario may break other more general resizing situation, so...

Anyway, Autoit rocks, your work rocks :) , so I will figure a way.

Thank you for your answers


-- VonCMinefield

Share this post


Link to post
Share on other sites

Aaaargh.... :(

That means the only dynamic resizing is defined with the (unperfect imho) GUICtrlSetResizing and not by a user function ?

That is sad...

Re-aaargh.... I suppose it is a Microsoft limitation, not a limitation of your implementation, right ?  :(

In the scenario I described, I do not care about "the resizing information regarding the *original* window size": since there is no DOCKWIDTH, I just want the control to resize itself according to the *current* width of the window

Mmmm... let me think :

<{POST_SNAPBACK}>

NO ;) I do not agree, but may be fixing my particular scenario may break other more general resizing situation, so...

Anyway, Autoit rocks, your work rocks :) , so I will figure a way.

Thank you for your answers

<{POST_SNAPBACK}>

JUst a small precision it is not a Microsoft limitation but resizing its completely mine. So why I say I want to stay with the current implementation ... :P

Share this post


Link to post
Share on other sites

JUst a small precision it is not a Microsoft limitation but resizing its completely mine. So why I say I want to stay with the current implementation ... :(

<{POST_SNAPBACK}>

Okok... soooo:

Any hope we might have the opportunity to be notified *during* a window resize, and not just when the window has been resized ? :(

That way, any sorry soul discontent with the current resizing policy might completly deactivate it (that is already possible through GUIEventCompatibilityMode I believe), and take over with their own function... :

Mmmm this thread is shifting towards "Idea lab" :)


-- VonCMinefield

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...