AutoHotkey Community

It is currently May 27th, 2012, 3:46 am

All times are UTC [ DST ]




Post new topic This topic is locked, you cannot edit posts or make further replies.  [ 1036 posts ]  Go to page Previous  1 ... 44, 45, 46, 47, 48, 49, 50 ... 70  Next
Author Message
 Post subject:
PostPosted: July 30th, 2010, 10:42 am 
Offline

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


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: July 30th, 2010, 11:11 pm 
Offline

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.]


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: July 30th, 2010, 11:18 pm 
Offline

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:


Report this post
Top
 Profile  
Reply with quote  
 Post subject: Recent bug
PostPosted: August 3rd, 2010, 11:47 pm 
Offline

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.

Report this post
Top
 Profile  
Reply with quote  
PostPosted: August 5th, 2010, 12:35 pm 
Offline

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


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: August 5th, 2010, 12:48 pm 
Offline

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:


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: August 5th, 2010, 2:14 pm 
Offline
User avatar

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]


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: August 5th, 2010, 10:48 pm 
Offline

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.


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: August 8th, 2010, 10:40 am 
Offline

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:


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: August 8th, 2010, 10:44 am 
Offline

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.

Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: August 8th, 2010, 11:03 am 
Offline
User avatar

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.

_________________
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]


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: August 8th, 2010, 12:22 pm 
Offline

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.


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: August 8th, 2010, 12:30 pm 
Offline

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.


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: August 8th, 2010, 12:58 pm 
Offline

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


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: August 8th, 2010, 3:22 pm 
Offline

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.


Report this post
Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic This topic is locked, you cannot edit posts or make further replies.  [ 1036 posts ]  Go to page Previous  1 ... 44, 45, 46, 47, 48, 49, 50 ... 70  Next

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

Search for:
Powered by phpBB® Forum Software © phpBB Group