 |
AutoHotkey Community Let's help each other out
|
AutoHotkey_L: Arrays, Debugger, x64, COM, #If expression ...
Goto page Previous 1, 2, 3 ... 46, 47, 48 ... 68, 69, 70 Next
|
| View previous topic :: View next topic |
| Author |
Message |
jackieku
Joined: 30 Nov 2008 Posts: 73
|
|
| Back to top |
|
 |
ddk
Joined: 28 Dec 2009 Posts: 43
|
Posted: Fri Jul 30, 2010 10:11 pm Post subject: |
|
|
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:
And I guess that's not right 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.] |
|
| Back to top |
|
 |
HotKeyIt
Joined: 18 Jun 2008 Posts: 4653 Location: AHK Forum
|
|
| Back to top |
|
 |
coaster3000
Joined: 03 Aug 2010 Posts: 1 Location: NJ
|
Posted: Tue Aug 03, 2010 10:47 pm Post subject: Recent bug |
|
|
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 Thu Aug 05, 2010 8:13 pm; edited 1 time in total |
|
| Back to top |
|
 |
Klaus
Joined: 12 May 2005 Posts: 325 Location: Münster, Germany
|
Posted: Thu Aug 05, 2010 11:35 am Post subject: Autohotkey_L doesn't display ä, Ä, ü, Ü, ö, Ö and ß |
|
|
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 |
|
| Back to top |
|
 |
HotKeyIt
Joined: 18 Jun 2008 Posts: 4653 Location: AHK Forum
|
|
| Back to top |
|
 |
fincs
Joined: 05 May 2007 Posts: 1163 Location: Seville, Spain
|
|
| Back to top |
|
 |
Lexikos
Joined: 17 Oct 2006 Posts: 7299 Location: Australia
|
Posted: Thu Aug 05, 2010 9:48 pm Post subject: |
|
|
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. |
|
| Back to top |
|
 |
Lexikos
Joined: 17 Oct 2006 Posts: 7299 Location: Australia
|
Posted: Sun Aug 08, 2010 9:40 am Post subject: |
|
|
| 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.  |
|
| Back to top |
|
 |
fragman
Joined: 13 Oct 2009 Posts: 1199
|
Posted: Sun Aug 08, 2010 9:44 am Post subject: |
|
|
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 Sun Aug 08, 2010 10:06 am; edited 1 time in total |
|
| Back to top |
|
 |
fincs
Joined: 05 May 2007 Posts: 1163 Location: Seville, Spain
|
|
| Back to top |
|
 |
Lexikos
Joined: 17 Oct 2006 Posts: 7299 Location: Australia
|
Posted: Sun Aug 08, 2010 11:22 am Post subject: |
|
|
| 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. |
|
| Back to top |
|
 |
fragman
Joined: 13 Oct 2009 Posts: 1199
|
Posted: Sun Aug 08, 2010 11:30 am Post subject: |
|
|
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. |
|
| Back to top |
|
 |
Lexikos
Joined: 17 Oct 2006 Posts: 7299 Location: Australia
|
Posted: Sun Aug 08, 2010 11:58 am Post subject: |
|
|
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 |
|
|
| Back to top |
|
 |
fragman
Joined: 13 Oct 2009 Posts: 1199
|
Posted: Sun Aug 08, 2010 2:22 pm Post subject: |
|
|
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. |
|
| Back to top |
|
 |
|
|
You can post new topics in this forum You can reply to topics in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|