AutoHotkey Community

It is currently May 27th, 2012, 3:35 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 ... 40, 41, 42, 43, 44, 45, 46 ... 70  Next
Author Message
 Post subject:
PostPosted: June 27th, 2010, 7:59 am 
Sorry Lexikos, I just asked the question ... to know. I didn't seen the "Ancient history"? Appologies. Thanks for your answer.


Report this post
Top
  
Reply with quote  
 Post subject:
PostPosted: June 28th, 2010, 10:46 am 
Offline

Joined: May 24th, 2006, 2:49 pm
Posts: 4511
Location: Belgrade
Seeing the recent wish about #includes reminded me about environmental variables in paths ( #include %UTILS%\Scripts\script.ahk ) ? Would you consider it ? Its very useful for script portability.

_________________
Image


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: June 28th, 2010, 10:49 am 
Offline

Joined: October 13th, 2009, 10:09 pm
Posts: 1389
While we're at it, why not an #includefolder ?


Report this post
Top
 Profile  
Reply with quote  
 Post subject: #includefolder
PostPosted: June 28th, 2010, 2:57 pm 
Offline

Joined: August 3rd, 2007, 8:01 am
Posts: 555
Location: Houston, TX
fragman wrote:
While we're at it, why not an #includefolder ?

I recently posted a wish / implementation for wildcards in #include.
This allows including folders recursively as well.
I pretty much butchered a copy of the code from Line::PerformLoopFilePattern.
But i can clean it up, if there is a chance Lexikos would consider including this feature...


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: July 6th, 2010, 7:43 pm 
Offline
User avatar

Joined: April 4th, 2009, 8:19 pm
Posts: 1143
Location: Croatia
@Lexikos:
Do you plan to make an installer for AHK_L unicode? I would like to uninstall mainstream AHK and install your upgrade.
IMO, the time has come to abandon mainstream AHK and use AHK_L unicode.


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: July 6th, 2010, 10:46 pm 
Offline

Joined: October 17th, 2006, 4:15 pm
Posts: 7503
Location: Australia
Yes, but it's not a high priority and therefore probably won't get done soon.


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: July 6th, 2010, 11:00 pm 
Offline
User avatar

Joined: May 24th, 2009, 5:35 am
Posts: 2099
Location: Iowa, USA
Lexikos wrote:
Yes, but it's not a high priority...
It seems as though with the lack of updates to Standard AHK, your version is getting quite a bit of attention in the AHK community. Thank you for the continued efforts :D . Out of curiosity, do you keep a list of update priorities/planned updates? If so, do you have them posted anywhere, or would you?

_________________
Image
Recommended: AutoHotkey_L
Basic Webpage Controls


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: July 7th, 2010, 4:33 am 
Offline

Joined: October 17th, 2006, 4:15 pm
Posts: 7503
Location: Australia
I have some rough notes, nothing that I'd be willing to post. To be honest, anything that isn't an immediate priority has no firm priority and isn't likely to be done soon.


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: July 7th, 2010, 5:27 pm 
Offline

Joined: July 30th, 2007, 11:32 pm
Posts: 581
Hey Lexikos,

In the "How to compile.txt" text file, it says that you compile AHK_L with VC 2008, but I see that you also have a solution file in VC 2010. Is there a difference in the release build of AutoHotkeyx.sln compared to AutoHotkey.sln?


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: July 8th, 2010, 2:22 am 
Offline

Joined: October 17th, 2006, 4:15 pm
Posts: 7503
Location: Australia
There may be minor differences in the configuration. Merely compiling with 2010 vs 2008 gives different results. AutoHotkey.sln is provided only for those still using 2008, as I've moved to 2010. I'll probably remove it as it's a bit of a hassle maintaining two sets of solution/project files.


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: July 8th, 2010, 2:06 pm 
Offline

Joined: May 24th, 2006, 2:49 pm
Posts: 4511
Location: Belgrade
Lexikos wrote:
Yes, but it's not a high priority and therefore probably won't get done soon.

Why don't u just include my bat installer or something similar. IMO full installer for AHK isn't all that important. Batch script is enough.

People need only to extract archive to folder of choice and run it as admin (on any computer they copy the folder afterwards)

_________________
Image


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

Joined: June 12th, 2008, 1:48 am
Posts: 27
Hi, first of all thanks for AHK_L, a great masterpiece 8) !

Well since I started to update a few of my older scripts to work with Unicode, I stumbled upon a problem with encrypting unicode strings with characters above the ascii range. The solution was to encode the string into utf7 first and then to convert back into utf16 so ahk_l could use the string (see working example here)! That way the encryption function didnt need a rewrite. Now I expanded upon this idea and run into an odd bug (?) / behaviour:

Code:
s := "Hello World !!"
utf7 =
num := Utf7Enc(s, utf7)

MsgBox, %s%`n%num%`n%utf7%`n--
return

Utf7Enc(s, ByRef sout){
  utf7Size := DllCall("WideCharToMultiByte", "UInt", 65000, "UInt", 0, "UInt", &s, "Int", -1, "Int", 0, "Int", 0, "Int", 0, "Int", 0)
  VarSetCapacity(utf7String, utf7Size)
  DllCall("WideCharToMultiByte", "UInt", 65000, "UInt", 0, "UInt", &s, "Int", -1, "Str", utf7String, "Int", utf7Size, "Int", 0, "Int", 0)
DllCall("MessageBoxA", "UInt", 0, "UInt", &utf7String, "UInt", 0, "UInt", 0x00000000L)
DllCall("MessageBoxW", "UInt", 0, "UInt", &utf7String, "UInt", 0, "UInt", 0x00000000L)
  UniSize := DllCall("MultiByteToWideChar", "UInt", 0, "UInt", 0, "UInt", &utf7String, "Int", -1, "Int", 0, "Int", 0)
  VarSetCapacity(UniBuf, UniSize * 2)
  DllCall("MultiByteToWideChar", "UInt", 0, "UInt", 0, "UInt", &utf7String, "Int", -1, "UInt", &UniBuf, "Int", UniSize)
DllCall("MessageBoxA", "UInt", 0, "UInt", &UniBuf, "UInt", 0, "UInt", 0x00000000L)
DllCall("MessageBoxW", "UInt", 0, "UInt", &UniBuf, "UInt", 0, "UInt", 0x00000000L)
MsgBox, %UniBuf%
;  sout := 111
;  return UniBuf
  sout := UniBuf
  return 111
}


Small description of sample code and problem:
It takes a string and encodes it with winapi calls into utf7 (and since this is an ansi string, and therefore not useable with ahk_l it has to be converted back into utf16!). The first 2 msg boxes show that the conversion into utf7 worked and that it is in fact an ansi string now, not an unicode encoded string. Then this ansi string is converted into its utf16 equivalent. The 3rd msgbox is a bit odd since I expected an empty one since the first character should be a zero-terminator (since "H" is 0x0048 in utf16), so i have no clue why it shows the "H" at all! But the 4th msgbox shows that the utf7 string was "transformed" into utf16, and the 5th msgbox is unexpectly empty (it should show the same contents as msgbox #4). The final msgbox shows as expected "111" for the second line (well since this is part of a larger piece of code, the "111" is just an example of some number calculations resultion from the string that are neede later!), but an empty 3rd line (kind of expected since msgbox #5 was empty as well)!
Here is now the oddest part: If I uncomment the 2 lines
Code:
;  sout := 111
;  return UniBuf
the final msgbox shows the "111" for the 3rd line (expected) but the 2nd line shows the correct utf16 string for the utf7-encoded string ??????

So how can a return statement make a variable "useable", that a previus MsgBox command could not display ??? Is it something I'm missing, or do I have some kind of missconception of how Unicode is handled ??

And Yes I do know of StrPut / StrGet, but as said it is part of a larger code, which is aimed to work on both vanilla ahk and ahk_l (meaning I'm resticted to winapi for these conversions), and the part for vanilla ahk works flawless.

As shown i can work around this by using the return method and store the calculation result in the byref variable, but this kinda defeats the purpose!

I hope someone can shed some light into this!


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: July 10th, 2010, 6:43 am 
Offline

Joined: October 17th, 2006, 4:15 pm
Posts: 7503
Location: Australia
dadepp wrote:
The solution was to encode the string into utf7 first and then to convert back into utf16 so ahk_l could use the string
Your conversion is flawed to begin with - you are converting a UTF-16 string into UTF-7, then reinterpreting the data as ANSI and converting the "ANSI" string to UTF-16.
Quote:
(and since this is an ansi string, and therefore not useable with ahk_l it has to be converted back into utf16!)
What would you use it for? There should be no issue passing a UTF-7 string around as long as it is terminated with a Unicode NULL character (for instance, "abcd\0\0" or "abc\0\0\0"; it must be aligned correctly).
Quote:
The first 2 msg boxes show that the conversion into utf7 worked and that it is in fact an ansi string now,
"8-bit" and "ANSI" are two different things. It is not an ANSI string.
Quote:
The 3rd msgbox is a bit odd since I expected an empty one since the first character should be a zero-terminator (since "H" is 0x0048 in utf16), so i have no clue why it shows the "H" at all!
Windows uses little-endian byte order, so 0x0048 becomes 0x48,0x00.
Quote:
the 5th msgbox is unexpectly empty (it should show the same contents as msgbox #4)
When you write to a variable using "UInt",&Var, the variable's internal length field is not updated. Use "Str",Var or VarSetCapacity(Var,-1).
Quote:
So how can a return statement make a variable "useable",
'Return' causes the variable's internal length field to be ignored, instead using the null-terminator.
Quote:
And Yes I do know of StrPut / StrGet,
I guess you didn't know of StrPut / StrGet for vanilla AHK. I've just fixed non-UTF-16 encoding... :oops: Also, I've updated the AutoHotkey_L downloads a few times since L52. See recent commits. It includes a fix for codepages which don't support the WC_NO_BEST_FIT_CHARS flag, such as UTF-7.


Report this post
Top
 Profile  
Reply with quote  
PostPosted: July 11th, 2010, 5:40 am 
Is it appropriate to use GetAddress as a way to check for the existence of a key in an object? Alternatively or in addition, is there a better / recommended way to check for key existence?

(Sorry if this has been covered before -- I didn't succeed in turning up any relevant-looking forum results.)


Report this post
Top
  
Reply with quote  
 Post subject:
PostPosted: July 11th, 2010, 6:21 am 
Offline

Joined: October 17th, 2006, 4:15 pm
Posts: 7503
Location: Australia
Quote:
[GetAddress] Returns the current address of the field's string buffer, if it has one.
Source: Object Methods - GetAddress

If there is no string value associated with the key, GetAddress will fail (return ""). Enumerating keys is currently the most reliable way to determine whether an object contains a particular key.


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 ... 40, 41, 42, 43, 44, 45, 46 ... 70  Next

All times are UTC [ DST ]


Who is online

Users browsing this forum: No registered users and 6 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