View topic - AutoHotkey_L: Arrays, Debugger, x64, COM, #If expression ... • AutoHotkey Community

View unanswered posts | View active topics

Board index » AutoHotkey » Scripts » Custom

All times are UTC [ DST ]

AutoHotkey_L: Arrays, Debugger, x64, COM, #If expression ...

Page 47 of 70

[ 1036 posts ]

Go to page Previous 1 ... 44, 45, 46, 47, 48, 49, 50 ... 70 Next

Print view | E-mail friend

Previous topic | Next topic

Author

Message

jackieku

Post subject:

Posted: July 30th, 2010, 10:42 am

Joined: November 30th, 2008, 1:51 pm
Posts: 73

I just found a bug produced by me. :oops:

http://ku.myftp.org/~jackie/git/autohot ... 2dbc92d3af

Top

ddk

Post subject:

Posted: July 30th, 2010, 11:11 pm

Joined: December 29th, 2009, 12:48 am
Posts: 43

Oh, hello. I have problems with machine code functions with AHK_L, I asked my question there but Lazslo turned me here. Here is the question:

ddk wrote:

I changed my OS to my nlited XP and since then I've had problems with bin2hex function:

Code:

MCode(Bin2Hex,"8B4C2404578B7C241085FF7E2F568B7424108A06C0E8042C0A8AD0C0"
            . "EA052AC2044188018A06240F2C0A8AD0C0EA052AC241044146880141"
            . "4F75D75EC601005FC3")

bin := "abc", VarSetCapacity(hex,9)
dllcall(&Bin2Hex, "uint",&hex, "uint",&bin, "uint",4, "cdecl")
VarSetCapacity(hex,-1) ; update StrLen
MsgBox %hex%           ; 31323300

That example returns me 4 boxes:

Code:

ㄶ〰㈶〰

And I guess that's not right :roll:

I've also tried standalone version of bin2hex and not working, also tried the BinToHex.dll. My AHK version is 1.0.48.05.L52H20.

I use unicode AHK_L and I am using Scite editor.

[Moderator's note: Edited MCode line so it wraps.]

Top

HotKeyIt

Post subject:

Posted: July 30th, 2010, 11:18 pm

Joined: June 18th, 2008, 8:36 am
Posts: 4923
Location: AHK Forum

You need to use StrGet(), see here

_________________
AHK_H (2alpha) AHF TT _Struct WatchDir Yaml _Input ObjTree RapidHotkey DynaRun :wink:

Top

coaster3000

Post subject: Recent bug

Posted: August 3rd, 2010, 11:47 pm

Joined: August 3rd, 2010, 7:42 pm
Posts: 1
Location: NJ

I got the recent version of this auto key

and this code no longer works when it works with regular version

ifwinexist("")
or
IfWinExist

That function says it does not exist. when it indeed does. And it crashes the script. this is the ASCII version

can you please fix it thanks
i would have thought it was the custom modded version of scite but its not
EDIT:
I found a way to get around this bug if anyone needed this function fixed.

if you know the language well. you can make your on function

Code:

checkwin(var_window)
{
    IfWinActive, var_window
      return true ; This means that it is true that this window is active}
}


#if (checkwin("some odd window here")) && (var_playing = 1) ; This just ;happened to be my situation. for this problem..  i was making an auto ;launch script that launched a browser and then started the game when ;you wanted to by click. 
Lbutton::
your code here

return

sorry if code is not perfect im in a rush because i need to do something

EDIT AGAIN:
It seems i made a error in coding the original making me think it was a bug infact that function really does not exist the real function i was thinking is Winactive sorry for bothering you

_________________
My Basic Auto Hot Key site-- autohotkey.net site

Last edited by coaster3000 on August 5th, 2010, 9:13 pm, edited 1 time in total.

Top

Klaus

Post subject: Autohotkey_L doesn't display ä, Ä, ü, Ü, ö, Ö and ß

Posted: August 5th, 2010, 12:35 pm

Joined: May 12th, 2005, 8:20 am
Posts: 331
Location: Münster, Germany

Hi, Community,
after some years of working with AHK I decided these days to have a look at Autohotkey_L which seems to be promising, in my opinion the implementation of objects is the point.
Now I played around with AHK_L and saw my lovely hometown's name Münster displayed as M?nster.
In the "normal" Autohotkey everything's alright.
And the same occurs for all german diacritial characters.Even though there are several posts dealing with these characters I didn't find a solution for my problem.
Have I read something over?
Can anyone help?
Thank in advance,
Klaus

Top

HotKeyIt

Post subject:

Posted: August 5th, 2010, 12:48 pm

Joined: June 18th, 2008, 8:36 am
Posts: 4923
Location: AHK Forum

Hi Klaus, this is due to unicode, you have to save your file as unicode or UTF-8.
I had a look in source code why this happens but unfortunately could not fix yet.
Possibly Lexikos can find a solution

_________________
AHK_H (2alpha) AHF TT _Struct WatchDir Yaml _Input ObjTree RapidHotkey DynaRun :wink:

Top

fincs

Post subject:

Posted: August 5th, 2010, 2:14 pm

Joined: May 5th, 2007, 7:24 pm
Posts: 1240
Location: Seville, Spain

There is no fix. The default encoding for BOMless files is UTF-8 in both AHK_L versions (perhaps it could be changed to system codepage in the ANSI version for maximum compatibility?)

_________________
fincs
Highly recommended: AutoHotkey_L (see why) (all my code snippets require it)
Formal request to polyethene - I support the unity of the AutoHotkey community
Get SciTE4AutoHotkey v3.0.00 (Release Candidate)
[My project list]

Top

Lexikos

Post subject:

Posted: August 5th, 2010, 10:48 pm

Joined: October 17th, 2006, 4:15 pm
Posts: 7503
Location: Australia

Perhaps an option can be added to the installer for the default codepage. I'll change the default for the ANSI build back to ANSI. Thanks for the suggestion.

For now, the following script can be used to change it for all scripts (assuming you've installed AutoHotkey_L):

Code:

default_cp = 0  ; System default ANSI codepage=0.

root=HKCR
key=AutoHotkeyScript\Shell\Open\Command
cmd="%A_AhkPath%"
if default_cp !=
    cmd=%cmd% /CP%default_cp%
cmd=%cmd% "`%1" `%*
RegWrite, REG_SZ, %root%, %key%,, %cmd%

If you launch scripts other ways on the command-line (e.g. via Run with %A_AhkPath% specified explicitly or via SciTE4AutoHotkey), you'll need to add the /CP0 option to the appropriate command lines.

Top

Lexikos

Post subject:

Posted: August 8th, 2010, 10:40 am

Joined: October 17th, 2006, 4:15 pm
Posts: 7503
Location: Australia

Quote:

Revision 53 - August 8, 2010

Merged AutoHotkey64 - COM support and x64 compatibility.
Added: Object.HasKey(key).
Added: Object(obj) increments obj's reference count and returns its address.
Added: ObjAddRef() and ObjRelease().
Fixed: A_ThisHotkey now has the expected value when used with #If.
Fixed: RunAs in Unicode build (fixed by jackieku).
Changed: Default script codepage for ANSI builds is now CP0 (ANSI).
Changed: x.y[] is now equivalent to (x.y)[] rather than x["y"].
Changed: Built-in methods can now be called with or without the underscore prefix (e.g. obj.MaxIndex() or obj._MaxIndex()).

July 10, 2010 (and earlier)

Added support for built-in and environment variables in double-derefs.
Improved support for multi-byte characters in certain codepages (previously only 932, 936, 949, 950 and 1361 were supported).
Fixed: StrPut failed for codepages which don't support WC_NO_BEST_FIT_CHARS, such as UTF-7.
Fixed: Double-deref as object - literal%var%.literal.
Fixed: StrPut("", Encoding) null-terminated an invalid address.

For more details about the merge, see Changes & New Features.

In addition to the new features, I've spent some time better integrating AHKL documentation, documenting some previously undocumented features (such as the local function library) and expanding on some areas (such as Script File Codepage). There are still a couple pages I'd like to revise -- like the AutoHotkey.chm starting page, Acknowledgements, and Objects/Object -- but that can wait.

I've conveniently forgotten to document Object.HasKey(key), but I'm sure you can figure out what it does. :lol:

Top

fragman

Post subject:

Posted: August 8th, 2010, 10:44 am

Joined: October 13th, 2009, 10:09 pm
Posts: 1389

Great work, I will try the A_ThisHotkey fix as soon as possible!
Many thanks for this

Edit: Seems to work fine.

Last edited by fragman on August 8th, 2010, 11:06 am, edited 1 time in total.

Top

fincs

Post subject:

Posted: August 8th, 2010, 11:03 am

Joined: May 5th, 2007, 7:24 pm
Posts: 1240
Location: Seville, Spain

Just two things:

Why is the Ptr type signed? It makes no sense to have a signed pointer type.
What happened to the ANSI x64 build?

Great work, I'll update my thread.

Top

Lexikos

Post subject:

Posted: August 8th, 2010, 12:22 pm

Joined: October 17th, 2006, 4:15 pm
Posts: 7503
Location: Australia

fincs wrote:

Why is the Ptr type signed?

Quote:

Make "Ptr" type signed again for maximum flexibility and consistency.
Note it can't be unsigned in 64-bit builds since we don't support
unsigned 64-bit integers. Leave the default for NumPut/Get unsigned
in 32-bit builds for backward-compatibility. Seems best to make the
default in 64-bit builds "Ptr", even though it can't be unsigned and
therefore might seem inconsistent.

Source: Commit ea860df6... - GitHub

About flexibility: If Ptr is unsigned, there is no way to specify a signed pointer-sized integer.
About consistency: There is no such thing as an unsigned 64-bit integer in AutoHotkey.

If it helps, think of it as its predecessor "IntPtr" or the Win32 type "INT_PTR".

Quote:

It makes no sense to have a signed pointer type.

IMO, your point of view is what makes no sense. Pointers are essentially abstract values - signed vs unsigned makes little to no difference. Display format is a minor concern; making it unsigned won't help the display format much anyway, since it'll generally be decimal (and still signed on x64). Both problems can be solved with a simple function:

Code:

MsgBox % FormatPtr(-1) ; 0xFFFFFFFF (x86) or 0xFFFFFFFFFFFFFFFF (x64)
FormatPtr(ptr) {
    VarSetCapacity(buf, 50)  ; Genereous estimate.
    DllCall(A_IsUnicode ? "msvcrt\swprintf" : "msvcrt\sprintf"
        , "str", buf, "str", "0x%p", "ptr", ptr, "cdecl")
    return buf
}

Quote:

What happened to the ANSI x64 build?

I don't see any benefit in providing an ANSI x64 build. I've maintained an ANSI x86 build only because it is necessary for compatibility with some scripts, but those same scripts that aren't Unicode-compatible probably won't be x64-compatible either.

Top

fragman

Post subject:

Posted: August 8th, 2010, 12:30 pm

Joined: October 13th, 2009, 10:09 pm
Posts: 1389

I think I might have found a bug, or atleast irrgeular behavior:

Code:

Hotkey, If, A_ThisHotkey = "MButton"
Hotkey, MButton, test
return

#if A_ThisHotkey = "MButton"
test:
msgbox execute
return
#if

#if false
~MButton::
msgbox should not trigger
return
#if

If you leave out the last hotkey it behaves differently, even though that hotkey should never trigger.
The label only sees ~MButton hotkey for testing.

Top

Lexikos

Post subject:

Posted: August 8th, 2010, 12:58 pm

Joined: October 17th, 2006, 4:15 pm
Posts: 7503
Location: Australia

Not a bug. If you use ListHotkeys or call a function from #if to display the value of A_ThisHotkey, you'll see there's only one hotkey and its name is "~MButton".

Quote:

When a hotkey is first created -- either by the Hotkey command or a double-colon label in the script -- its key name and the ordering of its modifier symbols becomes the permanent name of that hotkey. See also: A_ThisLabel
Source: Variables and Expressions

Top

fragman

Post subject:

Posted: August 8th, 2010, 3:22 pm

Joined: October 13th, 2009, 10:09 pm
Posts: 1389

Thanks for clarification. I'll work around it then.
Does it mean that the key will still be visible to other programs if the #if evaluates to true there?

Edit: Nevermind, the key blocking works correctly.

Top

Page 47 of 70

[ 1036 posts ]

Go to page Previous 1 ... 44, 45, 46, 47, 48, 49, 50 ... 70 Next

Board index » AutoHotkey » Scripts » Custom

All times are UTC [ DST ]

Who is online

Users browsing this forum: No registered users and 4 guests

You can post new topics in this forum
You can reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum