Author Topic: entering extended characters in SlickEdit 2007  (Read 12570 times)

Marita Hoeh

  • New Community Member
  • Posts: 1
  • Hero Points: 0
entering extended characters in SlickEdit 2007
« on: April 03, 2008, 02:49:28 pm »
Can anybody help me figure out how I can enter extended characters in SlickEdit 2007? In all other applications I can just enter e.g. alt+132 for a German a Umlaut but SlickEdit only displays a blank instead of the extended character. Many thanks!
Marita

Lisa

  • Senior Community Member
  • Posts: 238
  • Hero Points: 23
  • User-friendly geek-speak translator extraordinaire
Re: entering extended characters in SlickEdit 2007
« Reply #1 on: April 03, 2008, 05:05:05 pm »
Hi - would Edit > Insert Literal be what you need? You can enter characters in Decimal, Hex, or ASCII.

Clark

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 4669
  • Hero Points: 375
Re: entering extended characters in SlickEdit 2007
« Reply #2 on: April 03, 2008, 06:25:56 pm »
Hmm...weird

Windows:

Hold down left Alt (I didn't try the right Alt)
turn Num Lock on (or toggle it off then on) <-- MUST DO THIS EVERY TIME
type 132

The above seems to work for an SBCS and Unicode buffers.  I don't know why it is necessary to mess with NumLock every time.  I will check into this.

Clark

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 4669
  • Hero Points: 375
Re: entering extended characters in SlickEdit 2007
« Reply #3 on: April 04, 2008, 05:33:51 pm »
Interesting.  Looks like at some point Microsoft made a change to the OS to support Alt followed by digits.  Originally this was built into the BIOS when DOS was around (boy I'm old:-).  Microsoft never added this feature to Windows 3.1 and I'm pretter sure the early NT OSes didn't have this either.  We built this feature into SlickEdit.  At a glance, what built-in seems like a correct implementation but what Windows has built-in is don't something weird.  Character 132 is being translated to character 0xe4.  Even if you translate character 132 from active code page to Unicode, you don't get 0xe4 so I have no idea what Microsoft is up to here.

The good news is that I simply removed the code in SlickEdit which implements this feature so it falls through to the Windows implementation.  Pressing NumLock above has the interesting effect of bypassing SlickEdit's built-in code.

Users of older versions of SlickEdit will need to use the NumLock work around or use "insert-literal".  As for V13 users, a fix will be available for this in 13.0.1.

Clark

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 4669
  • Hero Points: 375
Re: entering extended characters in SlickEdit 2007
« Reply #4 on: April 04, 2008, 06:47:29 pm »
I just learned the following.  If you type Alt+0132, you get character 132, but if you type Alt+132, you get character xe4.  This is built-in windows.  For V13, this change will be available in 13.0.1

Phil Barila

  • Senior Community Member
  • Posts: 742
  • Hero Points: 61
Re: entering extended characters in SlickEdit 2007
« Reply #5 on: April 07, 2008, 05:27:31 pm »
Interesting.  Looks like at some point Microsoft made a change to the OS to support Alt followed by digits.  Originally this was built into the BIOS when DOS was around (boy I'm old:-).  Microsoft never added this feature to Windows 3.1 and I'm pretter sure the early NT OSes didn't have this either.  We built this feature into SlickEdit.  At a glance, what built-in seems like a correct implementation but what Windows has built-in is don't something weird.  Character 132 is being translated to character 0xe4.  Even if you translate character 132 from active code page to Unicode, you don't get 0xe4 so I have no idea what Microsoft is up to here.

The good news is that I simply removed the code in SlickEdit which implements this feature so it falls through to the Windows implementation.  Pressing NumLock above has the interesting effect of bypassing SlickEdit's built-in code.

Users of older versions of SlickEdit will need to use the NumLock work around or use "insert-literal".  As for V13 users, a fix will be available for this in 13.0.1.
This has been in Windows since 3.0, and NT3.51 certainly had it.  You just had to enter 4 digits, including any necessary leading zeros, as you note here:
I just learned the following.  If you type Alt+0132, you get character 132, but if you type Alt+132, you get character xe4.  This is built-in windows.  For V13, this change will be available in 13.0.1

mwb1100

  • Senior Community Member
  • Posts: 142
  • Hero Points: 13
Re: entering extended characters in SlickEdit 2007
« Reply #6 on: April 07, 2008, 06:02:20 pm »
The difference between Alt-0132 and Alt-132 are related to ANSI vs. OEM codepages and translating between the two.  The OEM (codepage 437) character at position 132(decimal) is an 'a' with an umlaut (รค).  This gets translated by to the Windows ANSI codepage (at least codepage 1252) to character code 228 (decimal).  Of course, if your codepages are different from mine, this mappings may not hold.

See:  http://community.slickedit.com/index.php?topic=3220.msg13200#msg13200

Clark

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 4669
  • Hero Points: 375
Re: entering extended characters in SlickEdit 2007
« Reply #7 on: April 08, 2008, 02:57:16 pm »
Thanks for the info.  I managed to figure out that Microsoft was translating based on the OEM code page by talking with some co-workers here and testing it.

buggyfunbunny

  • Senior Community Member
  • Posts: 233
  • Hero Points: 4
Re: entering extended characters in SlickEdit 2007
« Reply #8 on: May 15, 2008, 01:48:55 pm »
Related.  If you display the Tools>ANSI Table, you see that dec(159)/hex(9F) is <Y-umlaut>.  I can enter that as alt-159 in the vim editor frame.  However, neither the command line vim replace nor the menu replace recognizes the character.   I *think* I used to be able to replace these high-bit characters.  Will either replace facility be 'fixed' as part of this?