Jump to content

Sky Slate Blueberry Blackcurrant Watermelon Strawberry Orange Banana Apple Emerald Chocolate
Photo

AutoHotkey_L v1.1.04


  • Please log in to reply
47 replies to this topic
jethrow
  • Moderators
  • 2854 posts
  • Last active: May 17 2017 01:57 AM
  • Joined: 24 May 2009

...why does adding a name need to make it not set default?

Why should it? Personally, I don't think that creating an unnamed GUI should make it default - other than the fact that there may be no other way to reference it (outside of finding the hwnd).

After more throught, I realize I'm wrong. For a new script, the Defualt GUI is GUI #1. Therefore, you wouldn't lose reference to it. As far as if creating a New GUI should make it default, I think it should be consistent whether it has a Name/Number or not. In either case, I don't think it matters too much since you can set the Default GUI, but I do think it should be consistent.

[concerning Gui, New] if this is the sole reason for it ...

It's not.

atnbueno
  • Members
  • 91 posts
  • Last active: Feb 16 2016 07:04 PM
  • Joined: 24 Mar 2007
Hello, everyone.

Do the changes affect ErrorLevel?

I ask because the following script stopped working properly:
Loop, D:\Downloads\*, 2 ; only folders
{
	; Tries to delete every folder (fails if not empty)
	FileRemoveDir, %A_LoopFileLongPath%
	IfEqual, ErrorLevel, 0
		MsgBox, DELETED: "%A_LoopFileLongPath%"
}
(it worked with 1.1.03.00)

I fixed it easily but I think something broke with 1.1.04.00:
Loop, D:\Downloads\*, 2 ; only folders
{
	; Tries to delete every folder (fails if not empty)
	FileRemoveDir, %A_LoopFileLongPath%
	IfNotExist, %A_LoopFileLongPath%
		MsgBox, DELETED: "%A_LoopFileLongPath%"
}

Regards,
Antonio

Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006

2) Owner was never supported after creating the GUI.

It actually could, as I showed in the demo code.

No, it really couldn't.

//else mHwnd!=NULL. Since OS provides no way to change an existing window's owner, do nothing as documented.

Do the changes affect ErrorLevel?

The behaviour should be the same, but as changes were made to most commands to support try/catch, something may have been broken.

I ask because the following script stopped working properly:

Something was broken...

Edit: Fixed with v1.1.04.01.

it's.easily possible to support it later on though by calling SetWindowLong(Ptr).

Not according to the documentation.

fragman
  • Members
  • 1591 posts
  • Last active: Nov 12 2012 08:51 PM
  • Joined: 13 Oct 2009
Try this:
if(A_PtrSize = 4)

			DllCall("SetWindowLong", "Ptr", hGui, "int", -8, "PTR", hParent) ;This line actually sets the owner behavior

		else

			DllCall("SetWindowLongPtr", "Ptr", hGui, "int", -8, "PTR", hParent) ;This line actually sets the owner behavio
It's really more of an undocumented feature afaik.

Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006

It's really more of an undocumented feature afaik.

My point exactly.

fincs
  • Moderators
  • 1662 posts
  • Last active:
  • Joined: 05 May 2007
What about using SetParent, which is the proper way to do it, if I am reading correctly?

Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006
In theory, a parent window is not an owner window. The following implies that SetParent should not or cannot be used to set the owner of a window:

For compatibility reasons, SetParent does not modify the WS_CHILD or WS_POPUP window styles of the window whose parent is being changed. Therefore, if hWndNewParent is NULL, you should also clear the WS_CHILD bit and set the WS_POPUP style after calling SetParent. Conversely, if hWndNewParent is not NULL and the window was previously a child of the desktop, you should clear the WS_POPUP style and set the WS_CHILD style before calling SetParent.
Source: SetParent function



jballi
  • Members
  • 1029 posts
  • Last active:
  • Joined: 01 Oct 2005
rbrtryn reports that "||" characters are no longer supported as continuation characters in v1.1.04.00 (worked fine in v1.1.03.00).

<!-- m -->http://www.autohotke... ... 940#474940<!-- m -->

Is this a bug or is it a new feature of v1.1.04.00?

jaco0646
  • Moderators
  • 3165 posts
  • Last active: Apr 01 2014 01:46 AM
  • Joined: 07 Oct 2006

Improved error detection:
[*:2p1dc7wn]If an unrecognized option is used with Gui, Gui Show, Gui New or GuiControl, an error message is shown and the thread exits...

Note that || is not a continuation character, but rather an expression operator. A continuation character would be omitted from the merged code. Lines beginning with expression operators are concatenated, with the operators remaining, generally to retain their expression operations. The Gui, Add, commands now produce errors due to meaningless pipe characters, which used to be ignored. Now those errors are detected. It's actually a very nice feature, because these bugs were hard to track down when they were silently ignored.

jballi
  • Members
  • 1029 posts
  • Last active:
  • Joined: 01 Oct 2005

Note that || is not a continuation character, but rather an expression operator. A continuation character would be omitted from the merged code. Lines beginning with expression operators are concatenated, with the operators remaining, generally to retain their expression operations. The Gui, Add, commands now produce errors due to meaningless pipe characters, which used to be ignored. Now those errors are detected. It's actually a very nice feature, because these bugs were hard to track down when they were silently ignored.

OK. I guess I'll have to find something else to break up very large GUI statements. Thanks.

/* Deleted long rant about why I used "||" as a continuation character in dozens of scripts *because* it was ignored by AHK when used in GUI statements */

jaco0646
  • Moderators
  • 3165 posts
  • Last active: Apr 01 2014 01:46 AM
  • Joined: 07 Oct 2006

something else to break up very large GUI statements.

Of course you can break any statement at the commas, and pipes do work well for separating the choices of a ListBox, DDL, etc. where the merged code should contain pipes. In this case, you may have to resort to an actual continuation section using parentheses.

nimda
  • Members
  • 4368 posts
  • Last active: Aug 09 2015 02:36 AM
  • Joined: 26 Dec 2010
"Oh no, now I have to use continuation sections for continuation, instead of undocumented behaviors! The horror!" :roll:

nigelle
  • Members
  • 129 posts
  • Last active: Dec 28 2013 04:31 PM
  • Joined: 26 Sep 2008
Is this the last version to be stable ?
What is the stability status of V2 ?
Is it sensible to switch my scripts in AHK basic to this or to wait for V2 ?

engunneer
  • Moderators
  • 9162 posts
  • Last active: Sep 12 2014 10:36 PM
  • Joined: 30 Aug 2005
most Basic scripts will just run in aHK_L with no changes. See Script Compatibility in the AHK_L help file.

I made the switch to _L a few weeks ago, and I haven't run into anything yet, and some of the newer features are pretty nice.

V2 is probably still a bit in the distance, so it is worthwhile to go to _L now.

fragman
  • Members
  • 1591 posts
  • Last active: Nov 12 2012 08:51 PM
  • Joined: 13 Oct 2009
I would recommend switching, atleast for every new script that you write.
The conversion isn't that much of a problem most of the time.