Jump to content

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

AutoHotkey_L v1.0.95.00


  • Please log in to reply
12 replies to this topic
Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006
v1.0.95.00

All file I/O has been heavily optimized.

Added #Warn to assist with debugging; initial design by ac. (Note that since the beta, I have added #Warn UseEnv.)

By default, if name_var contains a function name, name_var.() calls the function. This can be overidden via the default base object, as before.

Run supports verbs with parameters, such as Run *RunAs %A_ScriptFullPath% /Param.

If an operator which can accept either one operand (&x) or two numeric operands (x & y) follows a quoted literal string, auto-concat occurs and the operator is applied only to the right-hand operand. This is because quoted literal strings are always considered non-numeric and are therefore not valid input for numeric operators. For example, expressions like "x" &y and "x" ++y now work.

Fixed:
[*:234pqoad] Wildcard hotkeys were not respecting modifiers such as ^!+ in specific cases.
[*:234pqoad] File.Pos returned garbage for non-seeking file types; now it returns -1.
[*:234pqoad] File.AtEOF was incorrectly true in some cases.
[*:234pqoad] COM wrapper objects left A_LastError unset in some cases.
[*:234pqoad] Gui submenu icons did not work on Windows 2000/XP/Server 2003.
[*:234pqoad] SplashImage clipped the image if height > width.
[*:234pqoad] ComObjConnect did not alert when the first parameter is invalid.
[*:234pqoad] SplashImage now uses GDI+ only when the other methods fail, for compatibility.
[*:234pqoad] Tilde in ~x:: now affects x & y:: in the same way that ~x & z:: would, instead of having no effect.
[*:234pqoad] A_PriorHotkey and A_TimeSincePriorHotkey now have the expected values when used with #If.
[*:234pqoad] RegExReplace did not advance through the string correctly after a match failure if the string contained non-ASCII characters.Downloads (etc.)(Note that the pre-v1.0.93 beta announcement thread has been moved.)

jethrow
  • Moderators
  • 2854 posts
  • Last active: May 17 2017 01:57 AM
  • Joined: 24 May 2009
Thank your for the bug fixes & updates sir :)

By default, if name_var contains a function name, name_var.() calls the function.

I understand what this does, but what is the significance? Was there a discussion about this functionality in the forums somewhere, or is this particularly useful for some reason?

ahklerner
  • Members
  • 1386 posts
  • Last active: Oct 08 2014 10:29 AM
  • Joined: 26 Jun 2006
Looking Good :)
Posted Image
ʞɔпɟ əɥʇ ʇɐɥʍ

HotKeyIt
  • Moderators
  • 7439 posts
  • Last active: Jun 22 2016 09:14 PM
  • Joined: 18 Jun 2008
Great, many thanks :D

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

I understand what this does, but what is the significance?

It can call either an object (which can carry extra context) or a function, without the script having to care which one.

sinkfaze
  • Moderators
  • 6367 posts
  • Last active: Nov 30 2018 08:50 PM
  • Joined: 18 Mar 2008
I think I may have found a problem in the latest release. On three different computers so far when I right-click the tray icon and selected to edit a script, the script eventually crashes with the standard "AutoHotkey.exe has encountered a problem and needs to close" dialog (in some cases the CPU goes under heavy load before crashing). This has occurred for me on Win 7 Home Premium and Win 7 Enterprise, both 64-bit.

Could some others test this to confirm?

EDIT: Continued tests on a couple of the computers I have handy has left me unable to reproduce this problem aside from its initial occurrence, which almost leads me to believe it may be UAC related, but I can't reason why it wouldn't cause a problem before the script has started and causes no problem at all until I choose to edit the script.

a4u
  • Guests
  • Last active:
  • Joined: --
Concerning what sinkfaze said: Tested on XP SP2 - Clicking Edit This Script causes the script to terminate, unless the script is already open in a text editor.

fragman
  • Members
  • 1591 posts
  • Last active: Nov 12 2012 08:51 PM
  • Joined: 13 Oct 2009
I may have found a bug:
<!-- m -->http://www.autohotke... ... 028#430028<!-- m -->

I'm not sure if it's really a bug or caused by a change in AHK_L, so I posted it in the help forum.

Frankie
  • Members
  • 2930 posts
  • Last active: Feb 05 2015 02:49 PM
  • Joined: 02 Nov 2008
Warn should notify you if you don't have an ExitApp line in an OnExit sub :evil:

Edit: FYI If you forget it, you have to taskmanager your script to get it to close usually. Not fun when you have 6 processes opened called AutoHotkey.exe *32 and its hit or miss.
aboutscriptappsscripts
Request Video Tutorials Here or View Current Tutorials on YouTube
Any code ⇈ above ⇈ requires AutoHotkey_L to run

MasterFocus
  • Moderators
  • 4323 posts
  • Last active: Jan 28 2016 01:38 AM
  • Joined: 08 Apr 2009

Warn should notify you if you don't have an ExitApp line in an OnExit sub :evil:

I'd say... +1

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Antonio França -- git.io -- github.com -- ahk4.net -- sites.google.com -- ahkscript.org

Member of the AHK community since 08/Apr/2009. Moderator since mid-2012.


Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006
I'm unable to reproduce the "Edit This Script" crash (edit: see below). I've tested briefly on Windows 7 (UAC disabled) and Vista (UAC enabled, limited user).

I may have found a bug:

Yes. See my reply in that thread.

Warn should notify you if you don't have an ExitApp line in an OnExit sub

Firstly, #Warn doesn't prevent the script from starting, so you'd still need to terminate it manually. Secondly, #Warn is intended to make common errors easily discoverable. Omitting ExitApp from OnExit subroutines isn't all that common, and it is already easily discoverable; rather, it's very difficult to miss. Thirdly, it wouldn't be entirely simple to detect (esp. without false-positives).

Not fun when you have 6 processes opened called AutoHotkey.exe *32 and its hit or miss.

Task Manager in Windows Vista and up shows "Command Line", which tells you which script it is. If not by default, go to View -> Select Columns... Furthermore, if you launch the script from SciTE, Ctrl+Break can be used to terminate it.

Edit (no pun intended): Although I still haven't reproduced a crash with the "Edit This Script" tray menu item, I believe I have found and fixed the cause. I expect to release a new version in the next day or so; there is at least one new feature to get excited about... ;)

ahk_alvin
  • Members
  • 12 posts
  • Last active: Dec 24 2011 09:44 AM
  • Joined: 19 Feb 2011
thanks for the update,

but I met a problem with the latest version of autohotkey. I don't know it is a bug or not. can you take a look?

<!-- m -->http://www.autohotke... ... 866#427866<!-- m -->

fragman
  • Members
  • 1591 posts
  • Last active: Nov 12 2012 08:51 PM
  • Joined: 13 Oct 2009

Not fun when you have 6 processes opened called AutoHotkey.exe *32 and its hit or miss.

Task Manager in Windows Vista and up shows "Command Line", which tells you which script it is. If not by default, go to View -> Select Columns... Furthermore, if you launch the script from SciTE, Ctrl+Break can be used to terminate it.

I wish task manager had a way to restart a program with its command line...