Jump to content


Photo
- - - - -

Question on special characters


13 replies to this topic

#1 tkv89

tkv89

    darkstar

  • Members
  • PipPip
  • 26 posts
  • Gender:Male

Posted 20 July 2009 - 04:53 AM

Hi there! I have this customer who used a client on a Windows 98 machine. He frequently entered special characters as part of the text (ALT224 - alpha, ALT234 - Ohm, etc). However, now that machine 'konked' out, and they then got a new PC with XP. However....now they can't enter the special characters! Any ideas, anyone?

#2 Richard Bassett

Richard Bassett

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 696 posts
  • Location:Rural France

Posted 20 July 2009 - 11:21 AM

If you open a DOS box and type the command 'chcp', what does Windows say?
Nothing's as simple as you think

#3 tkv89

tkv89

    darkstar

  • Members
  • PipPip
  • 26 posts
  • Gender:Male

Posted 21 July 2009 - 02:13 AM

It says "Active Code Page : 437". Does this mean I need to change the code page or something? My search on the web shows that I may have to change this to "850", or something, but how do I do this for the PROIV client? Thanks for the help.......

#4 Richard Bassett

Richard Bassett

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 696 posts
  • Location:Rural France

Posted 21 July 2009 - 09:12 AM

Hmm.. if you want ALT+234 to be Ohm then I'm pretty sure Code Page 437 is correct.
I have code page 437 and I get an 'Ohm' character in Notepad on Windows XP when I type ALT+234.

What happens if you try that in Notepad on the PC with the problem?
Because if that works OK then I'm guessing the problem is more subtle.

Are you still running the same ProIV client as on Win98 (assuming that's even possible) ?

Assuming these characters are actually being stored in your database can you find out what's actually been stored?
If they're stored, do pre-existing ones still display correctly on the client on XP?
What character set / encoding is being used for the text fields in your database?

I don't know if you can change the OEM code page for one app rather than the whole OS - but that doesn't seem to be the problem anyway.
I'm thinking the ALT+nnn thing is just a historical input method nowadays and maybe Windows is translating to Unicode??
Nothing's as simple as you think

#5 Chris Pepper

Chris Pepper

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 369 posts
  • Gender:Male
  • Location:United Kingdom

Posted 21 July 2009 - 05:15 PM

Is the NumLock on?

Try All Programs=>Accessories==>System Tools==>Character Map then Help

Can you cut and paste from the Character Map screen?

#6 tkv89

tkv89

    darkstar

  • Members
  • PipPip
  • 26 posts
  • Gender:Male

Posted 22 July 2009 - 08:07 AM

If I were to use those ALT+XXX commands on Microsoft Word or edit in command prompt, the special characters turn out ok. It's only in PRO-IV that Ohm translates to O, alpha becomes a and so on (the same thing happens when I try to copy and paste from the character map).

I've checked the database and previous entries are stored correctly (in that the 3rd party report used to print them can print the special characters OK)....
On that note, the pre existing characters don't display correctly in the PRO-IV client anymore. I believe the client is the same, seeing as the customer was the one installing it and they only have one source for the installations...

anything else that could help? Maybe a specific regional or language setting?

Thanks for the responses, guys.

#7 Richard Bassett

Richard Bassett

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 696 posts
  • Location:Rural France

Posted 22 July 2009 - 10:48 AM

Hmmmmmmm..

You didn't say, but I'm assuming there is no GUI client on an XP box already working against this data? Correct?

I could be wrong and I hope I am, but I have a feeling that You May Have A Problem ™.

The reasons I think my gut is saying this are:
(1) The OEM Character set was really a green-screen thing with its origins in MS-DOS.
(2) Windows 98 (and ME) were DOS-based and did not support Unicode.
(3) Windows XP is not DOS-based and does support Unicode.

I think you do need to determine which character set encoding is in use in the database (what database is it by the way?).

This whole area is a minefield for older applications (although I have no specific experience dealing with ProIV GUI).
There are some good resources on the Web, for example if you Google for:
oem character set unicode windows

Random ideas: Do you have any config info from the Windows 98 PC? Are there other Windows 98 PCs still working with this data?
Nothing's as simple as you think

#8 Richard Bassett

Richard Bassett

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 696 posts
  • Location:Rural France

Posted 25 July 2009 - 11:31 AM

For what it's worth, I was idly looking at the ProIV (5.5r300) docs to see if I could find anything relevant. The only thing I came across was about a Regional Settings Property Sheet in the Windows Client Guide (pages numbered 55/56 in my PDF).

This talks about code page conversion but suggests it is only considered in the context of mainframe ProIV. It also says the following:

"NOTE: The PROIV Client uses some standard Windows common controls. The text in those dialogs will reflect that of the underlying operating system in some cases. Therefore, not all text will be translated."

Which is quite close to what I think the problem might be. But I emphasize I am just making an educated guess.

Nothing's as simple as you think

#9 tkv89

tkv89

    darkstar

  • Members
  • PipPip
  • 26 posts
  • Gender:Male

Posted 27 July 2009 - 06:46 AM

Hey there, sorry for the late reply. Was on-site for a few days

Anyway, the database is ISO8859P1 (comparable to Latin-1, which has those characters I was talking about -> as far as I know).

Hmmm, I've been browsing about the internet and resetting the regional and language settings to a different character set each time, but no go (although i did get some weird characters...). I'll keep on trying...

BTW, does anyone know how that regional setting on the PRO-IV client work? There's this client code conversion page selection I saw, but it's always greyed out here.........

#10 Richard Bassett

Richard Bassett

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 696 posts
  • Location:Rural France

Posted 27 July 2009 - 08:49 AM

> Anyway, the database is ISO8859P1 (comparable to Latin-1, which has those characters I was talking about -> as far as I know).

ISO 8859-1 is Latin-1, but it doesn't contain any greek characters, see:
http://en.wikipedia..../ISO/IEC_8859-1

Note that in practice, use of Windows-1252 even where ISO 8859-1 is asserted is very, very common.
http://en.wikipedia....ki/Windows-1252
Nothing's as simple as you think

#11 Richard Bassett

Richard Bassett

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 696 posts
  • Location:Rural France

Posted 27 July 2009 - 09:10 AM

From http://en.wikipedia....i/Code_page_437

Entry on keyboards
In DOS and Windows, most characters from the currently active DOS code page can be inserted by holding down the Alt key and entering the character's three-digit decimal code on the numpad. This technique is called Windows Alt keycodes. One can find out which DOS code page is currently active by issuing the DOS command mode con or chcp.

In programs that only support Windows-1252, attempts to enter characters from CP437 will result in an attempt at transliteration for the Greek letters (αΓπΣστΦΘΩδφε become aGpSstFTOdfe).
Nothing's as simple as you think

#12 Richard Bassett

Richard Bassett

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 696 posts
  • Location:Rural France

Posted 27 July 2009 - 09:22 AM

Sanity-test question: When you try to view existing data containing the Ω and α do those characters in fact display as and ?
Nothing's as simple as you think

#13 tkv89

tkv89

    darkstar

  • Members
  • PipPip
  • 26 posts
  • Gender:Male

Posted 27 July 2009 - 11:31 AM

Wow, thanks a lot! I've actually seen those pages, but I didn't really connect them until you showed me. (BTW, Ω comes out as O and α comes out as a). Based on that information, I questioned the customer again. Apparently,the ex-person in charge was using another 3rd party software called "NJ Star" to "mask" the data as it was entered into the database. Their report printing those characters were using the same mask. Apparently, that software (for some reason) can't be installed on the new machine.

In other words, the data was "masked" by the 3rd party software, and was actually entered as those gibberish characters. Which explains why the ISO8859P1 database could have 'stored' those characters (I was scratching my head on that). They are now asking why our software is not compatible with XP (w00t) . Looks like it's going to be a customer discussion issue....

Again, thanks a million to all of you who responded (especially Richard). For what it's worth, I'm sorry for taking up everyone's time with insufficient data from the customer site....

#14 Richard Bassett

Richard Bassett

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 696 posts
  • Location:Rural France

Posted 27 July 2009 - 12:11 PM

Aaaah. I was wondering how the third party report you mentioned could be working.. a mysterious Ninja Star intervenes..

They used this NJ star thing without discussing it with you and now they can't install it on XP and they suggest it's *your* software that's not compatible with XP?! That's going to be an 'interesting' discussion.

Emergency suggestion in case it's of any use: Use VMware or whatever to install a Windows 98 virtual machine on the XP box and run the old software configuration on there for now.

I'm still wondering how the NJ Star whatsit has encoded things in the data and why the existing data also shows up as O and a, maybe it's using some kind of 'invisible' shift-in/shift-out escape sequences and just happened to encode the greek characters using the latin letters that 'seem natural'.

Anyway, the text in your database certainly isn't ISO 8859-1 (w00t)

Good luck, glad to have been of some help.
Nothing's as simple as you think



Reply to this topic



  


0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users