Announcement

Collapse
No announcement yet.

Predefined(?) UDT "Point" in PBCC 5

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

  • Predefined(?) UDT "Point" in PBCC 5

    If i declare in PBCC 5 an UDT named Point, with members x and y as single,
    the compiler protests against this with "mismatch with prior definition".
    However, as there is nothing included, there is not supposed to be any prior definition.

    If i declare members x and y as Long, the compiler seems perfectly happy,
    which suggests that inside PBCC 5 there lives a predefined UDT named Point,
    with members x and y as Long.

    I could not find anything about this in the help file.
    I also checked the issue with PBCC 4, and found that it is specific for PBCC 5.
    Should i consider this as a compiler bug, or is there some other explanation ?

    Arie Verheul


    Code:
    #Compile Exe
    #Dim All
    #Break On
    
    Type Point
        x As Single
        y As Single
    End Type
    
    Function PBMain () As Long
    
        Local Pt As Point
    
        Print Pt.x,Pt.y
    
        Pt.x = 10
        Pt.y = 15
    
        Print Pt.x,Pt.y
    
        WaitKey$
    
    End Function

  • #2
    >Should i consider this as a compiler bug,

    Assuming no other explanation is forthcoming, yes.

    However, if an explanation is forthcoming, also yes, except here it would be a help file bug rather than a compiler or IDE bug.

    Call me a purist, but if there is a predefined UDT in the belly of the compiler somewhere, that definition should be 'findable' in the documentation.

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

    Comment


    • #3
      This may shock you, Michael, but our compiler does not have a belly.

      Bob Zale

      Comment


      • #4
        I knew that because "belly" can't be found in the help file; i.e., no "belly bugs."

        But "belly" does not cause a duplicate defintion error at compile time and POINT does.
        Michael Mattias
        Tal Systems Inc. (retired)
        Racine WI USA
        [email protected]
        http://www.talsystems.com

        Comment


        • #5
          It rather looks as though the Windows POINT type is built into the current compilers. I'll file a query with R&D.

          Comment


          • #6
            This same subject came up in June, 2009!
            http://www.powerbasic.com/support/pb...reserved+words
            Rod
            I want not 'not', not Knot, not Knott, not Nott, not knot, not naught, not nought, but aught.

            Comment


            • #7
              Thanks Michael. I felt exactly the same way.

              Thanks Tom. I suppose we will hear about the outcome in due time.

              You are right indeed Rodney, i did not notice that as i normally do not
              follow the Windows programming forum.
              I *suspect* that the type declaration was added accidentally, as it is
              difficult to think of a good reason to do so, but i understand that
              we will know soon.


              Arie Verheul

              Comment


              • #8
                From Support, I was told it was in the compiler and was undocumented. I requested for it to be documented, along with any other UDTs the compiler handles for me.

                Inquiring minds like to know.

                Comment


                • #9
                  I fully agree with that Gary.
                  In fact the variable declaration is included in the code.
                  Having undocumented variables included in your code would be asking for trouble.
                  At least it should be clear who owns this variable: the compiler or the user.

                  Arie Verheul

                  Comment


                  • #10
                    There are no undocumented variables in PowerBASIC. The definition of a user-defined type for the POINT structure is included. This definition is identical to that documented in the API include files.

                    The CB.NM*** notification functions require the use of several other pre-defined UDT's (NMKEY, NMMOUSE, etc.), and the POINT structure is also required, as it is a member of NMMOUSE.

                    Bob Zale
                    PowerBASIC Inc.

                    Comment


                    • #11
                      Thanks Bob. That makes it clear.
                      So there are no internal variables included, but just UDT definitions,
                      and we are free to use these definitions also for our own purposes,
                      if a variable of the same type would be needed.

                      But still, and this is just a thought, would it in that case not be preferable
                      to use for the built in type definitions random generated names so that they
                      are not going to interfere with commonly used names ?

                      Arie Verheul

                      Comment


                      • #12
                        still, and this is just a thought, would it in that case not be preferable
                        to use for the built in type definitions random generated names so that they
                        are not going to interfere with commonly used names ?
                        No. It would be better to simply DOCUMENT all these things.

                        All it would take is one page in the help file, "Predefined UDTs", just like there are pages for the predefined equates.

                        And it would also help if one of my NSFs were adopted: on 'duplicate definition' error, include WHERE the symbol was first defined, be it in one of your files (including any #INCLUDEd files) or with a predefined symbol (UDT or equate).

                        eg,
                        Code:
                           error 480  Duplicate definition . Symbol 'POINT' previously defined 
                          {in file xxxx line yyy}|internally by compiler }
                        MCM
                        Michael Mattias
                        Tal Systems Inc. (retired)
                        Racine WI USA
                        [email protected]
                        http://www.talsystems.com

                        Comment


                        • #13
                          The new predefined types are NmChar, NmHdr, NmKey, NmMouse, NmToolTipsCreated, Point, and PointAPI (which is the same as Point). These match the corresponding Win32API types, and were brought in to PowerBASIC to support new language features. They will be added to the documentation and IDE keywords.

                          Comment


                          • #14
                            > NmChar, NmHdr, NmKey, NmMouse, NmToolTipsCreated...

                            Added to PB/CC? Pray what for? They are not used by PB/CC.

                            For that matter, POINT and POINTAPI are also unused by PB/CC, since you only need for POINT for NMMOUSE, which is not used in PB/CC.

                            Oh, well, I know THIS is a losing battle. Maybe once it's properly documented and/or the error messages spiffed up it will be moot.

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

                            Comment


                            • #15
                              Overview of built in UDT's

                              From Tom's list and the API files the following overview
                              of built in UDT's may be compiled.
                              Most of them are pretty specific.

                              Arie Verheul


                              Code:
                              '' OVERVIEW OF BUILT IN UDT'S
                              
                              Type Point
                                  x               As Long
                                  y               As Long
                              End Type
                              
                              Type PointAPI
                                  x               As Long
                                  y               As Long
                              End Type
                              
                              Type NMHdr
                                  hwndFrom        As Dword
                                  idfrom          As Dword
                                  Code            As Long
                              End Type
                              
                              Type NMChar
                                  hdr             As NMHdr
                                  ch              As Dword
                                  dwItemPrev      As Dword
                                  dwItemNext      As Dword
                              End Type
                              
                              Type NMKey
                                  hdr             As NMHdr
                                  nVKey           As Dword
                                  uFlags          As Dword
                              End Type
                              
                              Type NMMouse
                                  hdr             As NMHdr
                                  dwItemSpec      As Dword
                                  dwItemData      As Dword
                                  pt              As PointAPI
                                  dwHitInfo       As Dword
                              End Type
                              
                              Type NMToolTipsCReated
                                  hdr             As NMHdr
                                  hwndToolTips    As Dword
                              End Type

                              Comment


                              • #16
                                You forgot DIRDATA.. Unless you were just trying to show the undocumented stuff.
                                Michael Mattias
                                Tal Systems Inc. (retired)
                                Racine WI USA
                                [email protected]
                                http://www.talsystems.com

                                Comment


                                • #17
                                  If you need a list of the documented types, please see the documentation.

                                  Comment


                                  • #18
                                    >If you need a list of the documented types, please see the documentation.

                                    I tried to find same in the PB/CC 5.0.1 help file. I failed. I searched on TYPE, "user-defined", "predefined" forms thereof, and never found it.

                                    Can anyone tell me what keys to hit and what to type to find this info in the help file?

                                    Or, may I buy a vowel? Call a friend?

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

                                    Comment


                                    • #19
                                      Sure. A vowel will cost you $1,000. Got a credit card?

                                      Comment

                                      Working...
                                      X