FONT NEW statement

[Jordi Vallès]

Using FONT NEW statement I detected a problem when Symbol font is used, also happens with other non alphanumeric fonts. Same fonts are displayed correctly using the supplied PBFormsMakeFont function or the old MakeFont function of Dave Navarro.
Run the next sample to see the problem:

#Compile Exe
#Dim All

#Include "Win32Api.inc"
#Include "PBForms.inc"

Function PbMain()
   Local hDlg, hFont1, hfont2 As Dword

   [COLOR=Red]Font New[/COLOR] "Symbol", 12, 2, 0, 0, 0 To hFont1         'tested with several pitch and charset
   hFont2 = [COLOR=Red]PBFormsMakeFont[/COLOR]("Symbol", 12, %FW_NORMAL, %FALSE, %FALSE, %FALSE, %SYMBOL_CHARSET)

   Dialog New 0, "Test", , , 100, 100, %WS_CAPTION Or %WS_SYSMENU, 0 To hDlg
   Control Add Button, hDlg, 111, "W",  40, 24, 20, 16
   Control Add Button, hDlg, 222, "W",  40, 54, 20, 16
   Control Send        hDlg, 111, %WM_SETFONT, hFont1, 0
   Control Send        hDlg, 222, %WM_SETFONT, hFont2, 0
   
   Dialog Show Modal hDlg
   Font End hFont1
   If hFont2  Then DeleteObject hFont2
End Function

At this moment I don't know if mine is wrong or is a product failure or some misunderstanding.
Sample supplied has been tested with PBWin 9.02 under Vista Premium SP2.
Someone that can clarify me this behaviour?

[Michael Mattias]

> Control Send hDlg, 111, %WM_SETFONT, hFont1, 0
===>
CONTROL SET FONT statement "NEW!"

?????

[Jordi Vallès]

Thanks Michael. Obviously I need new glasses.
Jordi

[Michael Mattias]

You mean that fixed the problem? That was a guess.

Maybe I should buy a Powerball(r) ticket for tomorrow's drawing.....

[Jordi Vallès]

Oh, yes, the problem is fixed.
(Control Send <> Control Set)
Thanks a lot

[Michael Mattias]

This would seem to be an EXCELLENT example of why, when developing a screen using 'DDT,' one should use intrinsic DDT functions (CONTROL SET FONT) even when your gut says, "That has GOT to be the same as <something> (CONTROL SEND ... WM_SETFONT) "

The simple explanation is, the DDT engine does stuff 'under the hood'.... 'stuff' you don't know about, and stuff which is subject to change without notice.

That is, 'Beating the system' often does not.

MCM

[Gary Beene]

No!!!! Nooooooooooooooo!!!!!!!!!!!!!!!!!!!!!!!!!!!

The correct answer is to KNOW what can be done or not, then use the knowledge freely.

If one's knowledge is highly suspect, then perhaps safety is the correct call. But humans are well known for being able to proceed with less than perfect information!

If, in a particular case, sufficiently non-suspect information is not available, then PowerBASIC needs to respond - even if the answer is that "we can't commit to how the two programming techniques supported by PowerBASIC will work together". Then, knowing the degree of suspicion surrounding the mixed use of features, a programmer can make an informed choice.

I really, really don't want the answer to be that the two will never mix, or that we can't depend on them to mix! I've made my own suggestion to PowerBASIC Inc. that they commit to working towards compatibility between SDK and DDT - not simply parallel developments.

Isn't there an old saying, something like "In the land of the unknowing, the man with knowledge is King!"?

(Sorry for the late response. I seem to have missed this particular post.)

[Bob Zale]

Sorry, Gary, but that's very inaccurate. We've posted many times (more than I care to count) on this topic. Generally speaking, it's very prudent to use Windows API's with a DDT window, as long as DDT doesn't offer an equivalent function. I don't think you can ask for more than that. It's quite safe (not to mention desirable) that you expand DDT with the Windows API. It's not advised that you use DDT functions with a window created outside of DDT. If PowerBASIC doesn't have close knowledge of a window, how can it safely perform a management function on that window?

Common sense should prevail, because it works. Talk of "parallel development" is not in anyone's best interest. It's not factual.

Bob Zale
PowerBASIC Inc.

[Gary Beene]

Bob,

You wander from the purpose of my post.

I didn't make any statements of fact/non-fact at all. I simply expressed my desires, as a customer, on what I want from PowerBASIC.

As the provider of PowerBASIC you can accept or reject the request - for whatever reasons you choose. But even if my request is accurately characterized as "inaccurate", "not factual" or lacking "common sense", my job is to tell you what I want - not what I think possible or how to implement it.

It's a very odd thread this time - rarely have I been on one side of a discussion, where both Bob and MCM have been on the other! I can't help but grin!

[Michael Mattias]

Gary , I think your 'dream' of "totally parallel and back and forth compatible" is not a good dream.

All the high-level language statements are designed to simplify programming... it's more than reasonable to expect that sometimes a proprietary handling of a "thing to do" is going to be required to do just that. And no, I'm not happy with the documentation of same, either. But when it's properly documented, I can work with just about anything.

Just FWIW, Mr. Zale and I agree about ninety percent of the time, although much of this no one sees save the two of us.

But that ten percent ......

MCM

[Bob Zale]

Hi Gary--

There are no "sides" here. We just want to help provide accurate information to the readers.

We have thousands of casual observers who visit frequently. If they read a request for "3-byte, 24-bit integers because 16-bit isn't large enough", some might think that 16-bit integers are the only ones available. Of course, 32-bit and 64-bit are supported by PB, but they just might infer otherwise. We'd prefer to avoid that possibility by responding with factual information.

The same is true with DDT. If someone reads a notion that DDT might be simply parallel to the API, we want to dissuade that inference with the facts. The guidelines are:

"Generally speaking, it's prudent to use Windows API's with a DDT window, as long as DDT doesn't offer an equivalent function. It's quite safe (not to mention desirable) that you expand DDT with the Windows API. It's not advised that you use DDT functions with a window created outside of DDT."

By the way, I certainly wasn't suggesting that you lacked common sense. I was saying that "common sense" should be used in selecting API's that are appropriate to be used with DDT windows. With 1000's of API's, it just isn't possible to qualify each of them for use with each DDT function in every situation. That would require the Library of Congress on a CD. {smile}

Bob Zale
PowerBASIC Inc.

[Bob Zale]

...Just FWIW, Mr. Zale and I agree about ninety percent of the time, although much of this no one sees save the two of us.

But that ten percent ......

That ten percent is an area I'd be happy to help you with. {smile} I'm sure that, with a little effort, you'll be able to see the light! {smile}

Best...

Bob

[Michael Mattias]

> you'll be able to see the light! {smile}

No, no, no.

I am the convert-ER, you are the convert-EE.

MCM

[Bob Zale]

Wonderful. Then, when you finish your converter program (you know, the one that converts BASIC source code into executable machine code), you'll be in an excellent position to do just that. Let me know when you're ready?

Best regards,

Bob Zale
PowerBASIC Inc.

[Jordi Vallès]

Following the initial topic of this thread, I conclude that font handlers generated by sentences FONT NEW are usable only in pure DDT, because can't be used in APIs, for example, in routines OwnerDraw. It's true?

Jordi

[José Roca]

Following the initial topic of this thread, I conclude that font handlers generated by sentences FONT NEW are usable only in pure DDT, because can't be used in APIs, for example, in routines OwnerDraw. It's true?

Jordi

I think so. As a rule, I never use any DDT related statements in my SDK programs. Even if some work today, tomorrow may be changed an broke them.

[Barry Marks]

We have thousands of casual observers who visit frequently. If they read a request for "3-byte, 24-bit integers because 16-bit isn't large enough", some might think that 16-bit integers are the only ones available. Of course, 32-bit and 64-bit are supported by PB, but they just might infer otherwise. We'd prefer to avoid that possibility by responding with factual information.

Wow! This is exciting news! When you implement 24 bit integers will you also implement 12 bit bytes? And does that mean the size of a bit will increase by 50%?

Barry

[Bob Zale]

Generally speaking, it's very prudent to use Windows API's with a DDT window, as long as DDT doesn't offer an equivalent function.

It's quite safe (not to mention desirable) that you expand DDT with the Windows API. It's generally not advised that you use DDT functions with a window created outside of DDT.

Bob Zale
PowerBASIC Inc.