Modify

Opened 10 years ago

Closed 9 years ago

#1282 closed Bug (Fixed)

WinMove results in unespected resizing behavior of controls

Reported by: anonymous Owned by: Jpm
Milestone: 3.3.7.0 Component: AutoIt
Version: 3.3.0.0 Severity: None
Keywords: Cc:

Description

Hi,
I believe I have encountered a problem:

First, I create a window (that is initially hidden),
I use GUICtrlSetResizing($GUI_DOCK{TOP+LEFT+RIGHT+HEIGHT}) for a few controls (mostly Labels),
I use GUICtrlSetResizing($GUI_DOCKBORDERS) for an Edit control,
then I use GUICtrlSetPos() to vertically adjust all controls,
WinMove() to resize the window,
before I @SW_SHOW it.

The problem is this: after I manually resize the window with my mouse, the Label-like controls do proper resizing, but the Edit control takes all bad sizes. Like it "obeyed" the GUICtrlSetPos() properly. But when I resize the window myself, it seems to shoot back to sizes before I used the WinMove, both horizontally and vertically.(!)

I attached the script, maybe you guys see the same thing and know where the problem is to begin with. Or how to solve it.

Thanks in advance.

Attachments (2)

for test.rar (10.2 KB) - added by jay_paans@… 10 years ago.
Main script + Include script (both Dutch)
test2.rar (3.6 KB) - added by jay_paans@… 10 years ago.
Stripped and cleaned up

Download all attachments as: .zip

Change History (14)

Changed 10 years ago by jay_paans@…

Main script + Include script (both Dutch)

comment:1 Changed 10 years ago by jay_paans@…

Crap I forgot: It happens when the "settings" are being hidden on startup. So:

(l.24) Global $instellingenweergeven = MyRegRead($HKCU, "instellingen", "True")
must equal "False"

Plus, the most relevant parts are line 125-140 (SetResizing) and 204-219 (WinMove - @SW_SHOW)

comment:2 Changed 10 years ago by Valik

Lines 204-219? Seriously? You want us to reproduce a bug in a 200+ line script? Yeah, that's not happening. Either post a smaller script that reproduces the issue or I'm closing the ticket.

comment:3 Changed 10 years ago by jay_paans@…

Ok, point made.
Stripped everything irrelevant in main script and include script. I still left all the relevant controls and their resizing settings. (entire main script is now 140 lines)
added 'test2.rar'
Greets.

Changed 10 years ago by jay_paans@…

Stripped and cleaned up

comment:4 Changed 10 years ago by Valik

Several comments.

First, next time I tell you to shrink a script I mean shrink the fucking script. It takes 27 lines (or less) to duplicate your issue (see below). I've wasted way too much time digging through your shitty to code to find the minimum amount required to reproduce the issue. That leads me to...

Second, your shitty code. I suggest you learn how to combine styles because you are doing it wrong. You cannot add (or subtract) styles together. Well, you can, but it's bad code that leads to subtle bugs. I thought everybody knew that by now SINCE IT'S CLEARLY DOCUMENTED.

Anyway, that's all for now. Obviously something is screwy here. This is the test script. I suggest you learn from it to 1) Learn how to write a fucking bug report; 2) Learn how to use GUI styles.

#include <WindowsConstants.au3>
#include <GUIConstantsEx.au3>
#include <GuiEdit.au3>

Global $aPos[4] = [ 20, 20, 400, 400 ]

Local $hWnd = GUICreate("Test", 800, 600, -1, -1, BitOR($GUI_SS_DEFAULT_GUI, $WS_MAXIMIZEBOX, $WS_SIZEBOX))
Local $idGroup = GUICtrlCreateGroup("", 10, 100, 780, 470)
Local $idEdit = GUICtrlCreateEdit("", 20, 120, 760, 440, BitAnd($GUI_SS_DEFAULT_EDIT, BitNOT($ES_AUTOHSCROLL), BitNOT($WS_HSCROLL)))

GUICtrlSetResizing($idGroup, $GUI_DOCKBORDERS)
GUICtrlSetResizing($idEdit, $GUI_DOCKBORDERS)

WinMove($hWnd, "", $aPos[0], $aPos[1], $aPos[2], $aPos[3])

Local $aTemp = WinGetClientSize($hWnd)
GUICtrlSetPos($idGroup, 10, 10, $aTemp[0]-20, $aTemp[1]-20)
GUICtrlSetPos($idEdit, 20, 30, $aTemp[0]-40, $aTemp[1]-50)

GUISetState(@SW_SHOW)

While True
	Switch GUIGetMsg()
		Case $GUI_EVENT_CLOSE
			ExitLoop
	EndSwitch
WEnd

comment:5 Changed 10 years ago by Valik

Posting private link in case this isn't fixed anytime soon.

comment:6 Changed 10 years ago by Zedna

Group is not neccessary too for reproducing:

#include <WindowsConstants.au3>
#include <GUIConstantsEx.au3>
#include <GuiEdit.au3>

Global $aPos[4] = [ 20, 20, 400, 400 ]

Local $hWnd = GUICreate("Test", 800, 600, -1, -1, BitOR($GUI_SS_DEFAULT_GUI, $WS_MAXIMIZEBOX, $WS_SIZEBOX))
Local $idEdit = GUICtrlCreateEdit("", 20, 120, 760, 440)

GUICtrlSetResizing($idEdit, $GUI_DOCKBORDERS)

WinMove($hWnd, "", $aPos[0], $aPos[1], $aPos[2], $aPos[3])

Local $aTemp = WinGetClientSize($hWnd)
GUICtrlSetPos($idEdit, 20, 30, $aTemp[0]-40, $aTemp[1]-50)

GUISetState(@SW_SHOW)

While True
	Switch GUIGetMsg()
		Case $GUI_EVENT_CLOSE
			ExitLoop
	EndSwitch
WEnd

comment:7 Changed 10 years ago by Zedna

And BitNOT() styles for edit too.

comment:8 Changed 10 years ago by jay_paans@…

@VALIK
dude, you really think you're the man now, don't you??
well SHUT the F*CK up!
I do NOT take this language from you.

Second an most important, you better learn to FIX bugs when you say that's what you doing! see, YOUR shitty script --just copying your language and way of thinking here-- has the exact same flaw. !!!

Have you even TRIED was I mentioned about resizing the window with your mouse?
When you try to fix something, then fix it, you immature .....

comment:9 Changed 10 years ago by anonymous

And for your information, it's not necessarily bad to add up styles, because they are all decimal numbers and powers of 2. Which means they all have exactly ONE "non-zero binary digit". Example: (dec)256 equals (bin)1.0000.0000; 64 equals 0100.0000. If you add 256+64 you get 320. And if you BitOR(256, 64) you get 1.0100.0000 witch equals 320 in decimal just as well.

You can think of it like this:

  • using BitAnd is like multiplying every bit in line (0*0=0, 0*1=0, 1*1=1)
  • using BitOr is like adding every bit in line (0+0=0, 1+0=1, 1+1=1)
BitOr
1.0000.0000 (256)
0.0100.0000 (64) +
1.0100.0000 ==> 320

and

BitAnd
1.0000.0000 (256)
0.0100.0000 (64) x
0.0000.0000 ==> 0

Take it from me, its has worked for me so far, and the fault is not in the styles.
Maybe you should learn your math/science lessons again?

comment:10 Changed 10 years ago by Valik

First, of all, you're pretty damn stupid. Congratulations on that.

Second, you don't say my script has the same flaw? Do you know why it does? BECAUSE IT'S SUPPOSED TO. It reproduces your problem in a fraction of the code. See, your script is unacceptable. It's stupid and it's rude of you to post it.

Third, I don't recall stating that the mis-use of styles had anything to do with the problem. In fact I don't recall explaining to you what the problem is in the first place. I do know, I debugged it and I know how to fix it as well and it's none of your business what the problem is. The point being, I said nothing about styles being the problem, I simply said they were bad code. Also, I never claimed I fixed it. I claimed I posted a script that reproduced the problem without needing to wade through all the bullshit you seem to think is necessary. In fact your comments above are just completely asinine and show you're living in some sort of fantasy world because you're responding to things that simply did not happen.

Fourth, you're making a critical assumption that is not true. You are assuming every single style is a unique binary op. That is WRONG. Some styles are composites of other styles. Styles like $GUI_SS_DEFAULT_GUI are composite styles. Do you know what that means? It means if you add (binary +) a style that's already part of the composite style you create a new number completely. Compare that with bitwise-oring the composite style and stand-alone style and you'll produce a value that has the correct style bit set. Fundamentally huge difference and very easily a source of subtle bugs.

So yes, it is bad to add styles. There's a reason it's documented styles should be bitwise-or'd together. But what do I know, it's not like I have years of Windows programming experience or anything.

Lastly, I'll talk to you any damn way I please. You gave up your rights to civility when you posted an obscenely long script. You were told to cut it down but you didn't cut it down nearly enough. I then broke policy by looking at your stupidly long script and wasted far too much time cleaning it up and eliminating irrelevant pieces of code just to confirm there was a bug in AutoIt. And what do I get from you? Nothing but a bunch of ignorance and stupidity in response to my trying to teach you how to not fail at programming.

You're a real winner, champ. A word of advice and a warning all rolled into one: Before you ever post on this issue tracker again you better be damn sure you aren't going to waste my time because if you do you will be blocked. I've wasted far too much time on you due entirely to your stupidity and I'm not wasting anymore unless it be the precious few seconds it takes to ensure I don't have to deal with you again.

comment:11 Changed 9 years ago by anonymous (IP logged)

No soup for you!

comment:12 Changed 9 years ago by Jpm

  • Milestone set to 3.3.7.0
  • Owner set to Jpm
  • Resolution set to Fixed
  • Status changed from new to closed

Fixed by revision [5805] in version: 3.3.7.0

Guidelines for posting comments:

  • You cannot re-open a ticket but you may still leave a comment if you have additional information to add.
  • In-depth discussions should take place on the forum.

For more information see the full version of the ticket guidelines here.

Add Comment

Modify Ticket

Action
as closed The owner will remain Jpm.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.