nlsgetlocale

[steve_konarski]

I am trying to call the subroutine nlsgetlocale and have the following code - (only relevant parts included)

-------------------------------------------------------------

USE DFNLS
IMPLICIT NONE

INTEGER codep
CHARACTER*100 lang,country
..

.. call nlsgetlocale(lang,country,codep)

-------------------------------------------------------------------------------------------

On compilation I get the following error

dfnls.lib(locale.obj) : error LNK2001: unresolved external symbol _ChangeQWINCP

any ideas

[Steven_L_Intel1]

I see you're still using CVF, but I tried a small test case in both CVF and Intel Fortran and didn't see this problem. How are you building this? Can you come up with a small but complete test case?

[anthonyrichards]

I use Compaq Visual Fortran. This program compiled and ran OK for me...

program nsltest

use dfnls
implicit none
CHARACTER*100 lang,country
integer*4 codep

print *, 'Hello World'

codep=NLS$CurrentCodepage
call nlsgetlocale(lang,country,codep )

end program nsltest

[anthonyrichards]

Apologies for the double post..it would appear to be a browser problem as when I posted the first message I got browser message about the web page being unreachable, so tried again...and got the same response. I then ckecked the forum to find both replies had actually got through OK!

But when I tried to delete the superfluous message a couple of minutes later, I got a message about the time limit for deleting had been exceeded and to contact the forum administrator. The time limit seems to be rather short! So can you please do the honours, Steve?

[jimdempseyatthecove]

>> But when I tried to delete the superfluous message a couple of minutes later, I got a message about the time limit for deleting had been exceeded

I had that experience too, but I was able to go back in and edit the message. The extra message body could be replaced with "Ignore this - cannot delete message"

Jim

[Steven_L_Intel1]

I took care of it.

[steve_konarski]

I get good comilation with the small hello world program - BUT when i try and compile my large program get the error ,I commented out the line

call nlsgetlocale(lang,country,codep )

in my program and added a 'dummy' subroutine

subroutinenlstes

use dfnls
implicit none
CHARACTER*100 lang,country
integer*4 codep
print *, 'Hello World'
! codep=NLS$CurrentCodepage
call nlsgetlocale(lang,country,codep )
return
end

but still got the error message

[Steven_L_Intel1]

What's your build command line? You need to link with either DFQWIN.LIB (for a QuickWin application) or DFCONSOL.LIB (everything else) to resolve this reference. You'll get this with a default build but if you have customized the link you may not see it.

[Jugoslav_Dujic]

Is it a mixed-language project perhaps with non-Fortran main? _ChangeQWINCP is defined in ifconsol.lib (and, AFAIK, has nothing or little to do with QuickWin).

Quote from the manual ("Building Intel Fortran/C Mixed-Language Programs on Windows* Systems" page):

A mixed language solution containing a Fortran library project should have Disable Default Library Search Rules set to No in the IDE. To check this setting, choose Project>Properties and then choose the Libraries category. If you change the Disable Default Library Search Rules setting to Yes, you will need to explicitly add the needed runtime libraries to the non-Fortran project. If you are adding libraries explicitly, make sure you add IFCONSOL.LIB to the libraries of the non-Fortran project. This library is needed to perform almost any kind of I/O with Intel Fortran

[steve_konarski]

Compilation is OK with DFCONSOL.LIB but get a run time error in

call nlsgetlocale(lang,country,codep ).

The simple Hello world program runs OK

[Steven_L_Intel1]

And the run time error says, ????

[steve_konarski]

When I run the program I get a run time error -2 not sure what this is. When I debug the error occurs in nlsgetlocale - not sure how to obatin further information

[anthonyrichards]

The 'hello world' example below

program nsltest
 use dfnls
implicit none
CHARACTER*100 lang,country
integer*4 codep
print *, 'Hello World'
codep=NLS$CurrentCodepage
call nlsgetlocale(lang,country,codep )
print *, 'lang= ',trim(lang),';country= ',trim(country),'; code page= ',codep
 end program nsltest
 



 was created as a simple 'Fortran Console application' in CVF 
 and when compiled and run gave the output: 

Hello World
lang= English;country= United Kingdom; code page= 1252
Press any key to continue

The (default) project settings (debug) are:
 
kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib
advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib 
odbc32.lib odbccp32.lib /nologo /subsystem:console 
/incremental:no /pdb:"Debug/nsltest.pdb" /debug 
/machine:I386 /out:"Debug/nsltest.exe" /pdbtype:sept

If your 'larger' program is failing when you use the code
in a subroutine, then I presume that it 
may be because your project has different project settings. 
It would be helpful to both us and yourself if you copy 
and paste the full error message(s) that you get in your 
next post, if there is one.

[steve_konarski]

Apologies for delay in posting - I have been away

I still having problems with the program crashing - however I have a further query before moving on . I have the program

program nlstest
use dfnls
implicit none
integer*2 uni1(1),uni2(1)
character*30 lang,country
character*2 c2
integer*4 codep,j1,j2 ,n

call nlsgetlocale(lang,country,codep)
write(*,*)'locale ',lang(1:8),country(1:8),codep

do n=176,190
uni1(1)= n
call nlsetlocale(lang,country,codep)
j1=mbconvertunicodetomb(uni1,c2)
j2=mbconvertmbtounicode(c2,uni2)

write(*,*)uni1(1),j1,j2,' ',c2(1:j1),uni2(1),' ',char(n)

enddo

stop
end

on an english set up 'machine' i get

localeEnglish United K 1252
176 1 1 176
177 1 1 177
178 1 1 178
179 1 1 179
180 1 1 180
181 1 1 181
182 1 1 182
183 1 1 183
184 1 1 184
185 1 1 185
186 1 1&n bsp; 186
187 1 1 187
188 1 1 188
189 1 1 189
190 1 1 190

and on the japanese set up machine i get

locale English United S 932
176 2 1 176
177 2 1 } 177
178 1 1 2 50
179 1 1 3 51
180 2 1 L 180
181 2 1 956
182 2 1 182
183 2 1 E 12539
184 2 1 C -244
185 1 1 1 49
186 1 1 o 111
187 2 1 8811
188 1 1 ? 63
189& nbsp; 1 1 ? 63
190 1 1 ? 63

On the Japanese machine, why are some of the characters mulibyte and why do you not get the same unicode integer valus out of mbconvertmbtounicode as the input one to mbconvertunicodetomb