SETFONT Returns only Italic

SETFONT Returns only Italic

Hi There,

New to IVF and new to these forums...not sure where to post this question.

I am in the process of porting a DOS 6.2 Fortran program to IVF XE 2011 quickWin and WIndows 7 Standard Embedded and am perplexed with a font issue.

The OS Fonts CPL shows 5 proportional Arial Fonts (Black, Bold, Bold Italic, Italic and Regular). In \windows\Fonts there are 5 corresponding ttf files.

 The statement SETFONT('t''Arial''h20w12b') returns the correct result BUT it is italic. I don't want italic....

I deleted the ttf file corresponding to Arial Black (it's the only one I could delete), rebooted and saw the correct font returned for the above SETFONT statement.

I have the same problem with Courier New but am unable to delete any of them as they are protected system fonts....

Hope its just me being brain dead again but I am stumped.

Thanks.

10 posts / 0 nouveau(x)
Dernière contribution
Reportez-vous à notre Notice d'optimisation pour plus d'informations sur les choix et l'optimisation des performances dans les produits logiciels Intel.

Just a guess but Is the Italic a consequence of the best fit 'b' to the height and width combination you have specified. Try dropping the w12 and see what happens?

Thanks for your comment...

No - I have previously tried 'h20', 'h20b', 'w12', 'w12b'....all come back italic.

Regards.. 

Here is how you specify a font in Windows; the result is a handle to a font structure.

Sample invocation: hfont_14  = CreateSimpleFont ('Arial'C, 14, .FALSE., .FALSE.)

And note that when you finish using the font, DeleteObject(font_handle) must be called to avoid memory leaks.

! Creates a font with simple characteristics. The face name and size
! are provided, along with bold and italic flags. Returns a handle
! to the new font, or 0 on failiure.
!
INTEGER(HANDLE) FUNCTION CreateSimpleFont (faceName, size, bold, italic)
    IMPLICIT NONE
    CHARACTER(LEN=*), INTENT(IN)   :: faceName
    INTEGER, INTENT(IN)            :: size
    LOGICAL, INTENT(IN)            :: bold
    LOGICAL, INTENT(IN)            :: italic
    TYPE(T_LOGFONT)                :: logfont
    INTEGER(HANDLE)                :: hfont
    logfont%lfHeight        = size
    logfont%lfWidth            = 0
    logfont%lfEscapement    = 0
    logfont%lfOrientation    = 0
    IF (bold) THEN
        logfont%lfWeight = FW_BOLD
    ELSE
        logfont%lfWeight = FW_NORMAL
    END IF
    logfont%lfItalic            = italic
    logfont%lfUnderline            = .FALSE.
    logfont%lfStrikeout            = .FALSE.
    logfont%lfCharSet            = ANSI_CHARSET
    logfont%lfOutPrecision        = OUT_DEFAULT_PRECIS
    logfont%lfClipPrecision        = CLIP_DEFAULT_PRECIS
    logfont%lfQuality            = DEFAULT_QUALITY
    logfont%lfPitchAndFamily    = IOR(DEFAULT_PITCH, FF_DONTCARE)
    logfont%lfFaceName            = faceName
    hfont = CreateFontIndirect (logfont)
   CreateSimpleFont = hfont
END FUNCTION CreateSimpleFont

SETFONT is a QuickWin routine, so it isn't useful to call the Windows API directly.

Steve

Thanks Paul.

As Steve said, this is a quickWin app. Am I able to use the method you outlined or am I limited to SETFONT ?

Thanks.

Quickwin, as I understand (but do not use) it, is an abstraction layer designed to provide simple Windows features while shielding users from the nitty-gritty, which is fine until you need to specify a level of GUI detail which has been abstracted out (ie, IVF didn't think you would need that).  There should be nothing to prevent a program from invoking Win32 API functions directly in conjuction with Quickwin.  Here is how you tell a control within a dialog what font to use (for text content which has been specified elsewhere, possibly with the resource editor):

hwndControl = GetDlgItem (hwnd, IDC_ESWTEXT2)
hfont = CreateSimpleFont ('Verdana'C, 18, .FALSE., .FALSE.)
rval = SendMessage (hwndControl, WM_SETFONT, hfont, TRUE)

(and note that the final SendMessage argument is the WinAPI constant TRUE, which is not the same as the F90 .TRUE.)  This code would appear in the dialog proc function's WM_INITDIALOG section (and hence you need to provide a proc function for the dialog) so that the font can be specified before the dialog is rendered.

The Quickwin SETFONT function is specifically only applicable to text ouput with the Quickwin OUTGTEXT function, if that is what is being used then seting a font via API calls will not help. Pauls comment about Quickwin is a valid one however it does give a easier starting point for writing a 'Windows' aplication in fortran but it does have its limitations.

 

I was ready to report that I have no trouble with this, then I realized that I'm not sure what you are trying to do. What do you mean by "the correct results"? Note that the trailing "b" is not a request for bold (use "e" for that), but rather a request for Windows to make a "best fit." Sometimes it's hard to predict what Windows might come up with when given free reign like this--especially with fonts, which are very finicky.

Here's what I get with some variations on your font spec:

't''Arial''h20w12'          just what you'd expect
't''Arial''h20w12e'        bold
't''Arial''h20w12i'         italic
't''Arial''h20w12b'        same as the first (no bold, no italic)

Not sure this helps, other than to clarify the problem. Specifying "b" invites various results on various systems.

Thanks for all the feedback.

I have been on the road for the past few days and have not had the opportunity to touch base here till now...

My problem is / was that I would get italic in addition to whatever else was specified (bold, underline, italic, best fit) in the four examples from dbogss above.

I had the app on a Windows 7 Pro machine at one stage and saw my text rendered properly (outgtext) so I 'installed' the Arial and Courier New fonts from that machine onto my Windows 7 Standard Embedded machine. It worked.

The app is now deployed in its factory environment and is displaying all text correctly.

Once again, thanks to all for your input.

Connectez-vous pour laisser un commentaire.