Font End

[Bob Zale]

The crux of this issue is really simple -- PowerBASIC will not allow you to destroy a font which is still in use. If the selected font for a GRAPHIC WINDOW were destroyed, what would happen if you then executed a GRAPHIC PRINT? It wouldn't be pretty. {smile} You must first execute a GRAPHIC WINDOW END. The same is true of fonts in Dialogs, Controls, and Printers.

It doesn't matter if the window is detached, as it could be re-attached. If a font is in use anywhere, it cannot be destroyed with FONT END.

Best regards,

Bob Zale
PowerBASIC Inc.

[Michael Mattias]

>...you want to talk about lazy/sloppy?

Hmm, I think Mr. Christopher Carroll noticed the same thing... and has already done something about it...

http://www.powerbasic.com/support/pbforums/showpost.php?p=319656&postcount=3

Good job, sir.

MCM

[Michael Mattias]

So I decided not to say anything about "good technique" or "good trick".

I want to finish that semaphore demo this weekend before starting anything new, but this week there was a post from someone regarding the "samples" program provided with the compiler for using the date-time picker Common Control.

So... I looked over the original (poster had modified it for posting) and sheesh, you want to talk about lazy/sloppy? I simply MUST update that and comment it a little bit. The sample "works" but neither teaches anything nor is it terribly adaptable to anything resembling The Real World.

[Rodney Hicks]

But it's still "good programming technique" to close what you open, release what you get and destroy what you create.

I had been going to make a comment of that nature, that there should be a xxxx END for any xxxx NEW. There are several

DIALOG NEW
GRAPHIC WINDOW NEW
FONT NEW
GRAPHIC BITMAP NEW
WIFE KNEW

Before I did, I checked to see if PBForms issued a DIALOG END statement to go with the DIALOG NEW statement when it generates code and found that it doesn't.
So I decided not to say anything about "good technique" or "good trick".

[Michael Mattias]

>When your program ends, any existing fonts are automatically destroyed by >PowerBASIC

Unless I'm mistaken...

... PB only has to do anything because it still supports Win 9x/ME, which "features" shared GDI objects. In "genuine 32-bit" Windows, I think the O/S will destroy the process' GDI objects when that process ends.

But it's still "good programming technique" to close what you open, release what you get and destroy what you create.

[Gösta H. Lovgren-2]

>Here is a trick.

Minus eight marketing points.

While on the subject of style points, mundo minus points to you for not identifying whom you are quoting when there are numerous possibilities and/or msgs are not contiguous.

=================================
In rivers and bad governments,
the lightest things swim at top.
Ben Franklin
=================================

[Michael Mattias]

>Here is a trick.

Minus eight marketing points.

When someone else does it, it's a trick; when you do it, it's a technique.

[jcfuller]

For my uses this excerpt from the help files comforts.
James

When your program ends, any existing fonts are automatically destroyed by PowerBASIC

[Michael Mattias]

>What's the big deal about releasing a font, or not? It's 4 bytes

No, the HANDLE uses four bytes. What PowerBASIC stores at whereever that handle's data are located could contain a lot more.

That's why we use handles instead of "all the associated data." Much easier for the programmer to refer to an integer than to finding and using all the data associated with that object.

[Gösta H. Lovgren-2]

I'm curiouos. What's the big deal about releasing a font, or not? It's 4 bytes. Have to use an awful lot of fonts to use up any significant amount of memory. It's not like tying up large bl;ock for text or graphics or something.

Just curiious.

===================================================
"There is no sincerer love than the love of food."
George Bernard Shaw (1856-1950)
===================================================

[Rodney Hicks]

Or you could take advantage of the failure to create a font, from the documentation:

If the font creation fails, the value zero (0) is assigned to fhndl.

The following code compiles thus does not produce an error because of the first FONT NEW statement.

#COMPILE EXE
#INCLUDE "win32api.inc"

FUNCTION PBMAIN () AS LONG

    GRAPHIC WINDOW "Fonty Python",100,100,300,200 TO hBMP???
    FONT NEW "" TO hfontnew&
    FONT NEW "Lucida Console",12,2,0,1,100 TO hFont???
    GRAPHIC ATTACH hBMP???,0
    GRAPHIC COLOR %WHITE, %BLACK
    GRAPHIC SET POS (20,20)
    
    GRAPHIC SET FONT hFont???
    GRAPHIC PRINT "HEY, NEAT!!"
    MSGBOX "Look, no error:"+$CRLF+ERROR$(ERR)
    GRAPHIC SET FONT hfontnew&     'comment out this line for error
    GRAPHIC COLOR %BLACK,%WHITE
    GRAPHIC PRINT "HEY, NEATER!!"
    FONT END hFont???
    IF ERR THEN
      MSGBOX "Look, an ILLEGAL FUNCTION CALL error:"+$CRLF+ERROR$(ERR)
    ELSE
      MSGBOX "Honest, I didn't do nothing wrong!"
    END IF

    GRAPHIC WINDOW END

END FUNCTION

Looks like a Macro waiting to happen.

[Chris Boss]

You need to have one temporary font which can be used to with GRAPHIC SET FONT so the other fonts can be freed. Even GRAPHIC DETACH does not prevent the #5 runtime error.

Here is a trick.

Use this subroutine instead of GRAPHIC SET FONT.

SUB GraphicSetFont(BYVAL hFont&)
    STATIC hTempFont&
    IF hTempFont&=0 THEN
        FONT NEW "Times New Roman", 40, 1, 1, 0, 0 TO hTempFont&
    END IF
    IF hFont&=0 THEN hFont&=hTempFont&
    GRAPHIC SET FONT hFont&
END SUB

When you no longer need the fonts, simply call this routine and pass a value of zero (0) for hFont&. This will make the routine use the temporary font to set the font so the others are free to delete.

I took a little code from a PB sample app (textrotate.bas) and modified it to use my subroutine above.

ie.

  CONTROL ADD GRAPHIC, hDlg, %IDC_GRAPHIC1,"", 0, 0, 500, 400
  GRAPHIC ATTACH hDlg, %IDC_GRAPHIC1
  GRAPHIC CLEAR RGB(192, 0, 0)
  GRAPHIC BOX (0, 0) - (80, 400),,RGB(0, 0, 64), RGB(0, 64, 128)
  GRAPHIC COLOR %YELLOW, -2
  FONT NEW "Times New Roman", 40, 1, 1, 0, 900 TO hFont900
  ' ----------------------
  GraphicSetFont hFont900
  ' ----------------------
  GRAPHIC SET POS (0, 400)
  GRAPHIC PRINT " PowerBASIC "
  FONT NEW "Times New Roman", 40, 1, 1, 0, 300 TO hFont300
  ' ----------------------
  GraphicSetFont hFont300
  ' ----------------------
  GRAPHIC SET POS (90, 180)
  GRAPHIC PRINT "Graphic Print"
  GRAPHIC SET POS (100, 250)
  GRAPHIC PRINT "in any angle!"
  ' ----------------------
  GraphicSetFont 0                   ' call routine with a value of zero to set temp font
  ' ----------------------
  FONT END hFont900
  FONT END hFont300
  ' no #5 error generated

[Rodney Hicks]

This has also come up here before.

This has come up before but wasn't tagged. I tagged this one so that if someone searches tags for "FONT END" at least this one will come up.

A very good example of why we should use the TAGS feature.

Also, some of us learn by repetition, and some of us learn by repeatedly trying to help.

[Michael Mattias]

This has also come up here before.

I think it was answered by someone cutting and pasting from the doc for FONT END:

If the specified font is still in use by a control, a Graphic Control, a Graphic Window, or an XPrint page, an error 5 (Illegal Function Call) will be generated.

[Rodney Hicks]

GRAPHIC SET FONT fnthndl2&
FONT END fnthndl1&

You may have to replace the font you are using (fnthndl1&) with another (fnthndl2&) before you can use the FONT END fnthndl1& statement. 'In use' means it is still attached or assigned somewhere from my experience with it.

[Paul Dixon]

Walt,
if you post a short, compilable example of failing code then you're more likely to get an answer. I don't get an illegal function error using FONT END.

Paul.

[Walt Decker]

How does one release a font created with FONT NEW without generating error 5 (illegal function call)? I've tried GRAPHIC DETACH and GRAPHIC BITMAP END before FONT END hndl but still get error 5.