Announcement

Collapse
No announcement yet.

This Whine's Time Has Come...

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

  • This Whine's Time Has Come...

    <whine>

    Last week I received direct email from two separate people complaining code I had posted in the Source Code Forum did not compile with some new version of a PB compiler. One of those persons went so far as to state the code had "bugs." While there might be bugs in the code, until it is compiled and run there is no way to tell, is there?

    Anyway, the last two weeks I have been moving a couple of application across compiler versions myself: from PB/DLL v6.00 to v6.11, and have run into some of the same problems.

    However, none of my problems had to do with the code or the compiler per se; rather, the problems have to do with changes to the PB-supplied Windows header files (e.g., Win32API.INC) - and so did two of the three "bugs" reported to me by the two persons mentioned above. I am trying to use the Windows header files supplied with the release, rather than the previous versions, which, of course, will work just fine. (You didn't know that? Then you need to study up on what the DECLARE statement is. See the source code bundler application I recently posted if you want to save "all" #INCLUDEd files for a working application in a separate folder.)

    In my case, of the ten (10) problems I had, nine (9) were caught by the compiler at <U>compile</U> time (type mismatch, new keyword, restriction that dataname cannot be name of a TYPE, stuff like that). Only one - so far - had to do with the re-casting of API call <U>results</U> from LONG to DWORD, and therefore only detectable at run-time (although when my program encountered this, the results WERE SPECTACULAR!!!).

    So what's my point?

    1. I would ask anyone who posts source code in the Source Code Forum to indicate in program comments A) the compiler <U>version</U> used and B) the date of any Windows header files used. (PB-supplied header files now contain a date). No, not all of what I have posted over the past three years has this, but I am starting to do it.

    This practice might be even more useful with all the changes in PB/CC 3.00 and PB/Win-Dll 7.00.

    2. If one is going to download and attempt to use posted source code and has difficulty <U>compiling</U> the program, please check the compiler version; if the version was not supplied by the contributor, check the 'post date' to see if it's possible/likely the source code was created for a different version of the compiler. I do not think there is a "compiler version history" on this web site, but that might be a useful addition; e.g., "PB/DLL 6.00 released January 2001, 6.10 released January 2002, 6.11 released April 2002, etc...".

    3. I noticed that when doing an IDE compile with 6.11, the cursor now goes to the "error column." But even if it doesn't, "migrators" should check the error codes if the error is on line containing a Windows call. These errors indicate the first thing to check is the DECLARE in the Windows header files for consistency with the CALL line in the application code:

    420 Relational operator expected - The compiler has found a string operand in a position where a numeric operand should be, or a type mismatch has been detected.

    422 Scalar variable expected - The compiler expected a scalar variable as a formal parameter to a user-defined function.

    426 Variable expected - A variable was expected in the syntax of the statement. [You also get this if you try to pass a numeric literal as a parameter to a function when that parameter is DECLARED 'AS ANY.' MCM]

    464 Mismatch with prior definition - A Sub or Function prototype does not match the prior DECLARE statement.

    466 Duplicate name definition - A SUB name, FUNCTION name, label name, or variable name was defined more than once in your code. [As more FUNCTION and TYPEs are added to the header files, this occurs more often].

    480 Parameter mismatch, may need BYCOPY - There is a declaration difference when using a CALL statement, against the prior parameter declaration of a Sub or Function. [Also applies to implied calls. See the error explanation in the 6.10+ help files for other causes. MCM].
    I would also suggest that any DECLARE with one or more parameters declared 'AS ANY' be carefully checked against the appropriate Windows API documentation. (Here's a thought: maybe someone will write an application to scan source code and the #INCLUDE files and report out the DECLARE and any call lines when one or more parameters are declared "AS ANY". Be a real nice quick way to check this...).

    As I have stated here before, the O/S vendor's Windows' header files were written for use with Microsoft-brand compilers - primarily their C/C++ compilers; there is no such thing as a "word-for-word" translation, and those at PB who converted the files for use in PowerBASIC had to make some decisions about the implementation of the API calls 'as applied to a PB-brand Windows compiler.'. That had to be a lot of work for someone, and we should all be happy it was done for us. However, because decisions were required, it was not the same as documenting 'internal' calls such ARRAY SCAN or ATN or FRAC; some differences between how <U>you</U> would DECLARE an API function and how it appears in the PB-supplied files should be <U>expected.</U>

    I have used a lot of code supplied by many people, and as often as not I have had "compiler version/Windows header file migration issues," especially as I tend to run about six months behind on both compiler version and Windows header file updates.

    But "migration issues" are not "bugs"; and I for one believe those who provide code for others to use have no obligation to provide free migration consulting services.

    So please stop sending me email about migration issues unless you are prepared to enter into a professional services agreement, OK?

    </whine>

    Michael Mattias
    Tal Systems Inc
    Racine WI
    [email protected]

    PS: Bug reports are different. I have always acknowledged and fixed honest-to-goodness programming errors, so feel free to send email about those. (I have received a total of one honest-to-goodness bug report over the past three years).




    [This message has been edited by Michael Mattias (edited June 16, 2002).]
    Michael Mattias
    Tal Systems (retired)
    Port Washington WI USA
    [email protected]
    http://www.talsystems.com

  • #2
    Michael,
    Well said, well put. I agree 110% I appreciate all the effort put
    into the fine contribuions in this forum and personally find this to
    be one of the things that makes PB stand out as the best compiler option.
    I'm sure that the number of 'freely' posted files will greatly diminish
    if too much time is required to "support" them... especially 12-48 or more
    months later!

    --Joe

    ------------------
    Joe Byrne
    mailto:[email protected]
    [email protected]
    </A>
    Software makes Hardware Happen

    Comment


    • #3
      Michael,
      I agree with you.
      From now on I will try to follow your precious suggestions also in my personal code.


      ------------------
      Eros Olmi
      mailto:[email protected][email protected]</A>

      Comment


      • #4
        Compiling some of the older postings isn't easy.
        Many of them need rewrites to the current headers and
        the authors would be the best ones to do it.

        ------------------

        Comment


        • #5
          I agree total with MCM, most of the time they are LITTLE problems
          due to outdated sources. You can not expect original writers to maintain
          the code, as sometimes they don't even remember putting it there.
          If one run's into a problem and has a cure for it,
          this should/could be placed in the original source thread.
          If you don't find or have a cure, place a question on these forums, and do
          not send e-mail to the original writer. If needed, they'll reply by this forum,
          and if not, ANOTHER ONE DOES !!! (well 99,99%)


          Herman.



          ------------------
          You gotta run, and don't loop back.
          You gotta run, and don't loop back.

          Comment


          • #6
            It's impossible to keep track of and update all samples each time
            something has changed. Who is willing to pay for the time it takes?

            Samples are samples - they show a way and are meant to be bent and
            twisted to suit own needs, nothing more. To be a programmer is more
            than just compiling other people's code. Sometimes we actually must
            read error messages and try to find out why this or that doesn't
            work like expected. IMHO, that's what make programming so fun, we
            are fed with new mysteries to solve all the time..


            ------------------
            http://www.tolkenxp.com/pb
            Download: incLean, PBcodec, custom controls and code, etc.
            Borje Hagsten - [email protected]

            Comment


            • #7
              from Borje--

              Samples are samples - they show a way and are meant to be bent and twisted to suit own needs, nothing more. To be a programmer is more than just compiling other people's code. Sometimes we actually must read error messages and try to find out why this or that doesn't work like expected.
              Any way, perhaps, to post this excellent reminder at the top of the source code forum? I'm often amazed and frightened (especially frightened)by the number of programmers who apparently rely on code they don't understand. Their questions later, either here or privately, make clear that they haven't examined the code carefully, or at all, or that they lack the expertise required to use the code properly.

              Programming takes time. Learning how takes far longer. Them's the facts.


              [This message has been edited by Greg Turgeon (edited November 03, 2003).]

              Comment


              • #8
                Michael,
                I made a program that helps me with this exact problem. It is called IDELookup and
                it is posted at: http://www.powerbasic.com/files/pub/pbwin/tools/

                The way this helps, is you can highlight the API in question and press a hot-key
                to instantly pop-up a window that shows the exact Declare statement from the Win32API.inc.
                It makes it very easy to quickly look at each api.

                And to help with the multiple versions of Win32API.inc, I always copy the previous
                versions to a sub directory before exracting the new version. Then when I reindex
                the IDELookup program, it will index both versions. And when I press the Hotkey, it
                will pull up the first definition, and I can click the "Next Match" button to show
                other Win32API.inc versions. That way I can see how it was changed.

                BTW, I also made a version for the Jellyfish editor, that has a few more options because of
                the flexibility of the Jellyfish Plugin option. (Thanks Paul!)

                But I agree that is a great idea to post the date of the Win32api.inc file when posting code.
                (Although you would need to keep a copy of each version of the headers...) Tom or Lance, can we
                make a sugestion to let us also download the last 2 or 3 versions, just in case?


                ------------------
                "I haven't lost my mind... its backed up on tape... I think??"
                "I haven't lost my mind... its backed up on tape... I think??" :D

                Comment


                • #9
                  " the exact Declare statement from the Win32API.inc" often will not help. Read carefully above: the PB DECLARE statements are not - and cannot be - 'word for word' translations. (Also they change).

                  Better you should learn how/know where to look in you API reference and make the required adjustments yourself.

                  MCM

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

                  Comment


                  • #10
                    Always start with the API reference. We aim to match it. Doesn't hurt
                    a bit to make sure that our translations meet your expectations. Check
                    'em. Let us know if something seems off. You, or us, or both are liable
                    to learn something useful in the process.

                    ------------------
                    Tom Hanlin, PowerBASIC Staff
                    Opinions expressed may not be those of my employer or myself

                    Comment

                    Working...
                    X