Intel® Software Network

I do not sem to get the functions

GETCHARWIDTH    GETCHARWIDTH32   GetCharWidthFloat

 

to work in VISTA - are ther compatible functions in the latest Visual fortan which would work in VISTA

Those are Win32 API routines, not part of Intel Visual Fortran.  I think we'll need some more information as to what "doesn't work", and perhaps a small example.

---

Steve

Doctor Fortran: intel.com/software/drfortran

I have the program

 

USE DFWIN
USE DFLIB

IMPLICIT NONE

CHARACTER*15 TYPEFACE
INTEGER HFONT,HDC,RET

INTEGER NCHARS,I, NHGG,NW,ABCD(0:255)
REAL ABCD1(0:255)
TYPE (T_ABC) AB(0:255)

NCHARS=255

TYPEFACE="Arial"//char(0)

HDC = GETDC(NULL)
NHGG=-10000
NW=0
HFONT = CREATEFONT(-NHGG, NW, 0, 0, 0, 0, 0, 0, &
DEFAULT_CHARSET, OUT_TT_PRECIS, CLIP_DEFAULT_PRECIS, &
PROOF_QUALITY,INT(DEFAULT_PITCH) ,TYPEFACE)

RET=SELECTOBJECT(HDC,HFONT)

 

RET=GETCHARWIDTH32 (HDC,1,NCHARS,LOC(ABCD(1)))

RET=GETCHARWIDTHFLOAT (HDC,1,NCHARS,LOC(ABCD1(1)))
RET=GETCHARABCWIDTHS(HDC,1,255,AB(1))

DO I=65,90
WRITE(*,*)I,'  ',CHAR(I),ABCD(I),ABCD1(I),AB(I)%ABCA,AB(I)%ABCB,AB(I)%ABCC
ENDDO

STOP

END

 

In windows XP it lists the widths of characters between A and Z and all three functions

GETCHARWIDTH32 , GETCHARWIDTHFLOAT,   GETCHARABCWIDTHS

 

give values, however under Vista I just get zeros, I am using Visual Fortran Vers 6.0

 

if I upgrade will the problem be resolved

This is not a compiler problem - while there are many reasons to upgrade, this is not one of them.

I don't have immediate access to a Vista system to try your program. Perhaps another reader can comment.

---

Steve

Doctor Fortran: intel.com/software/drfortran

I compile and obtain the exe on an xp machine and transfer the exe to a vista machine where it does not produce the desired results

 steve

Any body got any ideas why the program does not work on Vista ?

These APIs are not applicable to Truetype fonts.  It could be that Vista has different defaults or the particular font isn't available.  There is a different API for Truetype fonts.  See the MSDN description http://msdn.microsoft.com/en-us/library/ms534215(VS.85).aspx

I checked and the font is available , and accoding to the MSDN site these should work in VISTA - but they do not

 

Sorry, I don't have Vista on anything, how about running the below and reporting the results

USE DFWIN
USE DFLIB

IMPLICIT NONE

CHARACTER*15 TYPEFACE
INTEGER HFONT,HDC,RET

INTEGER NCHARS,I, NHGG,NW,ABCD(0:255)
REAL ABCD1(0:255)
TYPE (T_ABC) AB(0:255)

NCHARS=255

TYPEFACE="dingers"//char(0)

HDC = GETDC(NULL)
NHGG=-10000
NW=0
HFONT = CREATEFONT(-NHGG, NW, 0, 0, 0, 0, 0, 0, &
DEFAULT_CHARSET, OUT_TT_PRECIS, CLIP_DEFAULT_PRECIS, &
PROOF_QUALITY,INT(DEFAULT_PITCH) ,TYPEFACE)

write(*,*)'hfont=',hfont,getlasterror()

RET=SELECTOBJECT(HDC,HFONT)

write(*,*)'selobjret=',ret,getlasterror()

RET=GETCHARWIDTH32 (HDC,1,NCHARS,LOC(ABCD(1)))

write(*,*)'cw32ret=',ret,getlasterror()

RET=GETCHARWIDTHFLOAT (HDC,1,NCHARS,LOC(ABCD1(1)))

write(*,*)'cwfret=',ret,getlasterror()

RET=GETCHARABCWIDTHS(HDC,1,255,AB(1))

write(*,*)'abcwret=',ret,getlasterror()

DO I=65,90

   WRITE(*,*)I,'  ',CHAR(I),ABCD(I),ABCD1(I),AB(I)%ABCA,AB(I)%ABCB,AB(I)%ABCC

ENDDO

END

 

 

I'm just slightly suspicious that Vista believes that the passed buffers are too small to hold the data from the query since you pass the address of a single element rather than of the whole array.  Maybe one of the security updates for Vista was to add checks for the correct size of argument buffers.  (just a wild theory)

this is result from windows XP

hfont=  1208633627           0
 selobjret=    25821217           0
 cw32ret=           1           0
 cwfret=           1           0
 abcwret=           1           0
          65  A        5970   373.1250             -13        5996         -13
          66  B        5970   373.1250             656        4838         476
          67  C        6464   404.0000             446        5664         354
          68  D        6464   404.0000             691        5297         476
 ..................

 

and from Vista

 

hfont=  1376391332           0
 selobjret=    25821253           0
 cw32ret=           0           0
 cwfret=           0           0
 abcwret=           0           0
          65  A           0  0.0000000E+00           0           0           0
          66  B           0  0.0000000E+00           0           0           0
          67  C           0  0.0000000E+00           0           0           0
          68  D           0  0.0000000E+00           0           0           0
 ...............

Call GetLastError after the function returns zero and see what the extended error code is.

---

Steve

Doctor Fortran: intel.com/software/drfortran

Have I not done that already ?  the result form getlasterror is zero

Sorry, yes, you did.

---

Steve

Doctor Fortran: intel.com/software/drfortran

I suspect (although I don't have a Vista around so I can't check either) that GetDC(NULL) might be the culprit. Google search on "Vista getdc null" hints at the possibility that Vista has an entirely different screen model... see e.g. here. Try with a "real" DC perhaps?

---

Jugoslav (www.xeffort.com)

Hi Jugoslav those links do point to a possible problem - not sure what you mean by

a "real" DC  

 

 steve

 

I mean, pretty much any DC other than the desktop one...

For the start, try GetDC(GetDesktopWindow()). Alternatively, you can try creating (and destroying later!) a memory DC, using

hDC = GetDC(GetDesktopWindow())

hMemDC = CreateCompatibleDC(hDC)

ret = CreateCompatibleBitmap(hDC , 100, 100)

iSt = SelectObject(hMemDC, hBmp)

...

!do stuff here

...

ret = DeleteObject(GetCurrentObject(hMemDC, OBJ_BITMAP)

ret = DeleteDC(hMemDC)

Note that a) I admit this is an overkill for such a simple task and b) I'm stabbing in the dark...

---

Jugoslav (www.xeffort.com)

Hi jugoslav thanks - that did dont work either - but i will try anything to get it to work

 

 steve

The specific msdn description for GETDC indicates that GETDC(null) should behave the same on Vista as I read it.  But I would suggest adding a write of the return code and getlasterror after GETDC(null) as well and see if the extended error code is nonzero there.  It is quite odd for the return code for the other functions to retun false but for there to then be a zero GETLASTERROR() result as well.  The indicates to me some major Vista error reporting anomaly or some unknown error within this application that messes up the GETLASTERROR() return value (stack corruption, out of bounds access not reported, etc.)

I tried the program on Vista and could get it to work by changing the value of NHGG. I used NHGG=-16. It looks to me it has something to do with the fontsize.

Guido

Thankks Guido i tried -16 but no luck BUT -100 and -1000 worked. I originally had a value of 10000 and used getcharwidth to get the resolution , but will now try getcharwidth32.

I'm guessing that the lack of GETLASTERROR() result is due to the fact the the OS performs silent font substitution for you such that if the font isn't available, the font mapper selects one that's "close to" the one you specify.  If so, I'd consider the lack of such information informing you that a font substitution was performed to be a poor design.  I would at least hope for a GETLASTERROR() result of "font substitution performed", as an informational error.  Unfortunately, Windows does not seem to support very well the usual return code categories found in other operating systems (Informational, Warning, Error (processing contined), Severe Error (processing halted, etc.)).