Announcement

Collapse
No announcement yet.

FONT NEW statement

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • FONT NEW statement

    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:
    Code:
    #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?

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

    ?????
    Michael Mattias
    Tal Systems (retired)
    Port Washington WI USA
    [email protected]
    http://www.talsystems.com

    Comment


    • #3
      Thanks Michael. Obviously I need new glasses.
      Jordi

      Comment


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

        Maybe I should buy a Powerball(r) ticket for tomorrow's drawing.....
        Michael Mattias
        Tal Systems (retired)
        Port Washington WI USA
        [email protected]
        http://www.talsystems.com

        Comment


        • #5
          Oh, yes, the problem is fixed.
          (Control Send <> Control Set)
          Thanks a lot
          Last edited by Jordi Vallès; 30 Oct 2009, 12:30 PM. Reason: Finger check

          Comment


          • #6
            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
            Michael Mattias
            Tal Systems (retired)
            Port Washington WI USA
            [email protected]
            http://www.talsystems.com

            Comment


            • #7
              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.)
              Last edited by Gary Beene; 2 Nov 2009, 04:45 PM.

              Comment


              • #8
                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.

                Comment


                • #9
                  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!

                  Comment


                  • #10
                    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
                    Michael Mattias
                    Tal Systems (retired)
                    Port Washington WI USA
                    [email protected]
                    http://www.talsystems.com

                    Comment


                    • #11
                      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.

                      Comment


                      • #12
                        Originally posted by Michael Mattias View Post
                        ...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

                        Comment


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

                          No, no, no.

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

                          MCM
                          Michael Mattias
                          Tal Systems (retired)
                          Port Washington WI USA
                          [email protected]
                          http://www.talsystems.com

                          Comment


                          • #14
                            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.

                            Comment


                            • #15
                              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

                              Comment


                              • #16
                                Originally posted by Jordi Vallès View Post
                                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.
                                Forum: http://www.jose.it-berater.org/smfforum/index.php

                                Comment


                                • #17
                                  Originally posted by Bob Zale View Post
                                  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

                                  Comment


                                  • #18
                                    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.

                                    Comment

                                    Working...
                                    X