National Language Support (NLS) Usage in Ifort

National Language Support (NLS) Usage in Ifort

For a project I was experimenting with a 'text' file which is Unicode (UTF-16(LE)). The test file has a few strings in it with a mixture of 'normal' ASCII characters and with some Arabic characters. I read the file as a buffer array of 2 byte integers, ignoring the first 4 bytes which are a Unicode header Z'FFFE', I can find LF and CR Z'0D00' and Z'0A00' that denote the string boundaries. I can then hit the NLS function MBConvertUnicodeToMB' to convert to double byte character set text strings. So far so good, however the Normal character all come in just fine and the Arabic characters all come back as question marks. Not so surprising perhaps as if I call NLSGetLocale my language is English and my codepage is 1252 (I think 1256 would be the correct codepage for Arabic).

If I call NLSSetLocale ('Arabic','Egypt' ) for example I get an OK return status, but then if I call NLSGetLocale nothing has changed I still get English, united kingdom and codepage 1252. If I set codepage 1256 NLSsetlocale crashes. I think perhaps it is because the locale I asked for is not installed so I have being playing with NLSEnumLocales which should give me a list of options installed and available. However, I get access violations using this call I think because I am doing it incorrectly.

A three line code snippet in the help showing declaration and usage of NLSEnumLocales would be most helpful could anyone oblige?

The help topics around NLS are rather sparse and could do with a bit of improvement and searching the forums there appears to be virtually no topics on this subject, is it not much used?

Thanks in advance

Andrew 

15 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

I think it would be an understatement to say these routines are little used. If you need help with your code, show us what you're trying and we'll try to figure it out.

Steve - Intel Developer Support

The usage comment is a tad worrying...

My last botched attempt look a bit like, the code below, What should it look like?

    use ifnls

	    TYPE (NLS$ENUMLOCALE), POINTER   :: LOCALES(:)

	    locales=NLSEnumLocales( )

Perhaps use pointer assignment (=>), not "normal" assignment.

Curious choice of interface for that function.

@Ian.

Yes I've tried that as well with a  similar result "Unhandled exception at 0x00096039 in Console1.exe: 0xC0000005: Access violation writing location 0xcccccd08." I'm a bit out of my comfort zone, I am not sure if it crashes because I am doing it wrong or because there is a system problem.

Irrespective of that issue which I still need to solved, now in my windows settings I set the language to Arabic and the Country to Egypt. Now in Fortran when I call NLSGetLocale  is says Arabic and Egypt, but still code page 1252, but perhaps I need to reboot, in which case my computer might become incomprehensible!!!!!!!!!!!!!

 

Ian has the right idea. I will try to work up an example and get back to you.

Yeah, it is a very curious interface choice, but we got this from Microsoft. I believe it mimics what the Windows APIs do, as it's the sort of thing I see there a lot.

Steve - Intel Developer Support

I looked at the API for clues, but for that API function you supply a pointer to a callback function so you must have made some coding that is a bit more than a pure wrapper I think.

http://msdn.microsoft.com/en-us/library/windows/desktop/dd317828(v=vs.85).aspx

Also, is the system on which you run your application Vista or later? (a requirement of the API).

Jim Dempsey

www.quickthreadprogramming.com

Currently on W7 x64, that isn't the problem. Reading on the subject the multi-language in support it has progressively  ramped up from w2000, the 'complete deal' does seem to arrive at W7.

I would like to get NLSEnumLocales to work as it tells you what the system options currently are. However, I am barking up the wrong tree with some of the other NLS stuff. 

Currently all the text in all my many dialogs is supplied via my own string function based on an string ID. The string function has the facility to have its database populated by reading an external file. To date that external file has always been ANSI. All my dialogs are driven via IFLOGM. IFLOGM does not support Unicode text. Windows dialogs do support Unicode text. I looked at IFLOGM.f90 for a while today. Basically IFLOGM does the following:

1) Gives the user a set of facilities for populating a Fortran data structure (eg dlgsetchar, dlgsettitle, dlgsetcallback...) in a 'Fortran friendly' way.

2) Passes the data  to the SDK dialog routines when the dialog goes live.

3) Updates the Fortran data structure from the SDK when you enter a callback or when the dialog exits.

It looks like the top end of IFLOGM could be made to use Unicode text with minimal changes, you need to be mindful that all the character buffers will have twice as many bites and also looking for null string termination is slightly different. The problem is that there is a layer below IFLOGM.f90 between it and the SDK. There are about 25 routines interfaced to that are in dlglow.cpp which is not supplied in source. All the dialog text setting function in the SDK have two versions with the same interface one for ANSI text and one for Unicode text. I suspect updating this will not be a big job but I do not know.

@Intel: What is the prospect of getting IFLOGM to support Unicode? It really should do this.

The other options are:

1) Write my own version of dlglow.cpp from scratch

2) Ditch IFLOGM and use the SDK from scratch. As I have a large amount of code that works and is structured around the use if IFLOGM this is not an appealing prospect.

3) Some other way. Does  xeffort support Unicode or have more of the source exposed? What other third party utilities exits? I have not looked at this option.

 

Did you get a change to look at this Steve? IFNLS gives:

FUNCTION NLSENUMLOCALES() RESULT(LOCALES)
!DEC$ ATTRIBUTES DEFAULT :: NLSENUMLOCALES
 TYPE NLS$ENUMLOCALE
            SEQUENCE
            CHARACTER(64)    :: LANGUAGE
            CHARACTER(64)    :: COUNTRY
            INTEGER*4        :: DEFAULTWINDOWSCODEPAGE
            INTEGER*4        :: DEFAULTCONSOLECODEPAGE
END TYPE
TYPE (NLS$ENUMLOCALE), POINTER   :: LOCALES(:)
END FUNCTION NLSENUMLOCALES
END INTERFACE

Both the examples below give access violation crashes, what is the correct usage?

USE IFNLS
TYPE (NLS$ENUMLOCALE), pointer   :: LOCALES(:)
locales=>NLSEnumLocales( )
locales=NLSEnumLocales( )

It is failing inside NLSENUMLOCALES while it is trying to copy the data to the freshly allocated pointer array. I need to ask the developers to investigate more. Issue ID is DPD200252302.

My advice here would be to call EnumSystemLocales directly - it doesn't look difficult.
 

Steve - Intel Developer Support

I will have a look at that thanks and when resolved or as part of the DPD perhaps a code snippet in the help file as this is a strange interface.

 

Once I see a working version of this I'll write an example and ask that it be added to the documentation.
 

Steve - Intel Developer Support

This has been fixed for update 2 - the routine was simply broken. I will work up an example when I get the fixed version.

Steve - Intel Developer Support

Thanks.  This aspect of my project is currently on hold whilst I am converting my application from QuickWin to Windows. I have a lot of different aspects to my user interface and I have to say there have been some challenges as Windows has a lot of API and some of the documentation is a bit hard top fathom. But, I now have a mostly working application with respect to menu's/graphics/user interaction and I hope to have a stable version shortly. The next step will be converting all my dialogs from IFLOGM to WINAPI, All the text string handling is being done via a small number of utilities so the final step of doing this in Unicode should be quite simple.

There are some issues that I have discovered in IFWIN and its subsidiaries which I will gather together in a new post at a convenient time.

 

 

 

 

 

Leave a Comment

Please sign in to add a comment. Not a member? Join today