AutoHotkey Community
It is currently May 26th, 2012, 11:48 pm

View unanswered posts | View active topics


Board index » AutoHotkey » Scripts

All times are UTC [ DST ]



Post new topic This topic is locked, you cannot edit posts or make further replies.  Page 7 of 16
  [ 237 posts ]  Go to page Previous  1 ... 4, 5, 6, 7, 8, 9, 10 ... 16  Next
  Print view | E-mail friend Previous topic | Next topic 
Author Message
fincs
 Post subject:
PostPosted: November 9th, 2009, 4:20 pm 
Online
User avatar

Joined: May 5th, 2007, 7:24 pm
Posts: 1240
Location: Seville, Spain
This is important because of a simple reason: single-byte codepages.
Each has its own set of extended ASCII characters and having a text representation of problematic characters ("™" = ™ for example) helps in most cases.

_________________
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  
jackieku
 Post subject:
PostPosted: November 9th, 2009, 4:48 pm 
Offline

Joined: November 30th, 2008, 1:51 pm
Posts: 73
fincs wrote:
This is important because of a simple reason: single-byte codepages.
Each has its own set of extended ASCII characters and having a text representation of problematic characters ("™" = ™ for example) helps in most cases.

However, I think those &#NNN;s shouldn't be here. Otherwise, we should convert all characters >= U+0080 to &#NNN; as well, not only <= U+00FF.


Report this post
Top
 Profile  
Reply with quote  
fincs
 Post subject:
PostPosted: November 9th, 2009, 4:54 pm 
Online
User avatar

Joined: May 5th, 2007, 7:24 pm
Posts: 1240
Location: Seville, Spain
They map to U+NNN, so no problem.

EDIT: Now to fix RegEx callouts and possibly merge Lexikos' latest changes.

_________________
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  
Petru
 Post subject:
PostPosted: November 9th, 2009, 5:47 pm 
Offline

Joined: December 17th, 2007, 6:39 pm
Posts: 235
Location: Galati, Romania
We still need AutohotkeySC.bin. Please, somebody...


Report this post
Top
 Profile  
Reply with quote  
Petru
 Post subject:
PostPosted: November 11th, 2009, 4:08 pm 
Offline

Joined: December 17th, 2007, 6:39 pm
Posts: 235
Location: Galati, Romania
Any news?


Report this post
Top
 Profile  
Reply with quote  
rousni
 Post subject:
PostPosted: November 11th, 2009, 4:15 pm 
Offline

Joined: March 23rd, 2006, 2:20 pm
Posts: 128
I'm sensing a calm before the storm… hopefully a good storm.


Report this post
Top
 Profile  
Reply with quote  
fincs
 Post subject:
PostPosted: November 11th, 2009, 9:55 pm 
Online
User avatar

Joined: May 5th, 2007, 7:24 pm
Posts: 1240
Location: Seville, Spain
Yes, a good storm ;)
Mainly about bugfixes but oh well...

_________________
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  
jackieku
 Post subject:
PostPosted: November 13th, 2009, 5:08 pm 
Offline

Joined: November 30th, 2008, 1:51 pm
Posts: 73
bump (bug fixes)


Report this post
Top
 Profile  
Reply with quote  
Micha
 Post subject:
PostPosted: November 13th, 2009, 8:16 pm 
Offline

Joined: November 15th, 2005, 11:15 am
Posts: 537
Location: Germany
Hi jackieku,
I've just seen your posts. I'm developing AHK for Wince devices which are working just with unicode. I began to convert every variable for an API call to unicode and back. The ahk-code internally is still working with ansi. The next step will be to completely change to unicode.

If your code will be stable (mine still isn't) we could join our code to one code base to support WIN and CE devices with unicode.
The bad thing is that a lot of things aren't supported on CE devices and the code contains a lot of #ifdefs.
Please tell me what you think about it.
If you do not want to clutter your code with ifdefs I'll be still looking forward to join your code with mine.
Thanks for working on an unicode version
Ciao
Micha


Report this post
Top
 Profile  
Reply with quote  
jackieku
 Post subject:
PostPosted: November 14th, 2009, 3:46 am 
Offline

Joined: November 30th, 2008, 1:51 pm
Posts: 73
@Micha
Hello, I can't help on CE version, since I don't have such devices. However, to share the same code base might a good idea.

About the stability, I believe there are some bugs in AutoHotkeyU, though it works fine for my daily usage.


Report this post
Top
 Profile  
Reply with quote  
Sean
 Post subject:
PostPosted: November 14th, 2009, 7:07 am 
Offline

Joined: February 12th, 2007, 7:54 am
Posts: 2462
jackieku wrote:
The default code page (for the files without BOM) to load script files is determined by program file name. If it is beginning with AutoHotkeyU (e.g. AutoHotkeyU.exe, case-insensitive), the default is UTF-8. Otherwise, system code page would be used.
Have you tried what I suggested before? If you don't like to go through all the procedure, you can test only UTF-8 and ANSI. As UTF-8 is more consistent against error code points, it may better be checked first.
Code:
If   cch := DllCall("kernel32\MultiByteToWideChar", "Uint", 65001, "Uint", 8, "Uint", pv, "int", -1, "Uint", 0, "int", 0)
   nCP := 65001
Else If   cch := DllCall("kernel32\MultiByteToWideChar", "Uint", 0, "Uint", 0, "Uint", pv, "int", -1, "Uint", 0, "int", 0)
   nCP := 0
VarSetCapacity(wstr,2*cch)
DllCall("kernel32\MultiByteToWideChar", "Uint", nCP, "Uint", 0, "Uint", pv, "int", -1, "Uint", &wstr, "int", cch)


Report this post
Top
 Profile  
Reply with quote  
jackieku
 Post subject:
PostPosted: November 14th, 2009, 7:40 am 
Offline

Joined: November 30th, 2008, 1:51 pm
Posts: 73
Sean wrote:
Code:
If   cch := DllCall("kernel32\MultiByteToWideChar", "Uint", 65001, "Uint", 8, "Uint", pv, "int", -1, "Uint", 0, "int", 0)
   nCP := 65001
Else If   cch := DllCall("kernel32\MultiByteToWideChar", "Uint", 0, "Uint", 0, "Uint", pv, "int", -1, "Uint", 0, "int", 0)
   nCP := 0
VarSetCapacity(wstr,2*cch)
DllCall("kernel32\MultiByteToWideChar", "Uint", nCP, "Uint", 0, "Uint", pv, "int", -1, "Uint", &wstr, "int", cch)

AFAIK, there is no compiler/interpreter support charset detections. There are some reason I decided not to do that as well.
  1. Most detection methods don't guarantee the results are 100% correct.
  2. The results are highly depend on the characters outside of ASCII, but those characters are rarely used in source codes compare to the characters in ASCII.
  3. It reduces the loading performance definitely.


Also, if an user can write scripts and he/she care about Unicode, this shouldn't be a problem for him/her. The current mechanism leaves the choices for the users. Note that the files with UTF-8 BOM are always recognized.


Last edited by jackieku on December 23rd, 2009, 1:41 am, edited 1 time in total.

Report this post
Top
 Profile  
Reply with quote  
Sean
 Post subject:
PostPosted: November 14th, 2009, 8:01 am 
Offline

Joined: February 12th, 2007, 7:54 am
Posts: 2462
jackieku wrote:
AFAIK, there is no compiler/interpret support charset detections. There are some reason I decided not to do that as well.
What mechanism are you using for the conversion? Anyway, I suggested it again as you seemed to not determine which one to use, UTF-8 or ANSI. I have to reencode again some of my scripts, ANSI -> UTF-8 -> ANSI. BTW, I prefer no BOM in my files/scripts, and my text editor gvim handles well files either in UTF-8 (regardless the presence of BOM) or in my system codepage. AFAIK, UTF-8 is the one with the least false alarm, so, I suggested to check first against UTF-8.


Report this post
Top
 Profile  
Reply with quote  
jackieku
 Post subject:
PostPosted: November 14th, 2009, 8:06 am 
Offline

Joined: November 30th, 2008, 1:51 pm
Posts: 73
@Sean
If you decide to use UTF-8 without BOM. (I personally prefer this format, too.) Just rename the AutoHotkey from AutoHotkey.exe to AutoHotkeyU.exe.


Report this post
Top
 Profile  
Reply with quote  
Sean
 Post subject:
PostPosted: November 14th, 2009, 8:23 am 
Offline

Joined: February 12th, 2007, 7:54 am
Posts: 2462
jackieku wrote:
If you decide to use UTF-8 without BOM. (I personally prefer this format, too.) Just rename the AutoHotkey from AutoHotkey.exe to AutoHotkeyU.exe.
Does it imply that all are settled now, ANSI for AutoHotkey.exe and UTF-8 for AutoHotkeyU.exe? OK with me then.


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.  Page 7 of 16
  [ 237 posts ]  Go to page Previous  1 ... 4, 5, 6, 7, 8, 9, 10 ... 16  Next

Board index » AutoHotkey » Scripts

All times are UTC [ DST ]

Who is online

Users browsing this forum: Apollo, iDrug, IsNull, Miguel and 56 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