Announcement

Collapse
No announcement yet.

Win32API.INC and SQLTools conflict

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

  • Win32API.INC and SQLTools conflict

    Both files have %LOCALE_USER_DEFAULT being set, cauding a duplicate equate error in compiling anything with SQLTools and Win32API. Which to change? I have changed Win32API's to %LOCALE_USER_DEFAULTe but now, what else to break? If I changed the SQL include file, I think I might break the .dll. This other way, at least it would be in my source code to change.
    Barry

  • #2
    Another SQL Tools licensee reported this (via email) just yesterday, but I have not yet been able to replicate the problem. Still working on it.

    The odd thing seems to be that WIN32API.INC defines %LOCALE_USER_DEFAULT this way...

    &h0000

    ...and SQL Tools defines it this way...

    &h0

    ...so I'm not sure what the problem really is. Full source code for a program that fails -- including WIN32API.INC etc. etc. -- would be greatly appreciated, sent to the email address below.

    Both values evaluate to zero, so an easy solution would be to change either INC file to match the other. It should have no effect whatsoever on the operation of either PB or SQL Tools.

    I'll report back as I discover more about this issue...

    -- Eric Pearson, Perfect Sync, Inc.
    Last edited by Eric Pearson; 11 Oct 2009, 10:32 AM.
    "Not my circus, not my monkeys."

    Comment


    • #3
      The odd thing seems to be that WIN32API.INC defines %LOCALE_USER_DEFAULT this way...

      &h0000
      You must be using an old version of win32api.inc. The latest one correctly defines it as &H0400.
      Forum: http://www.jose.it-berater.org/smfforum/index.php

      Comment


      • #4
        Aha! Gracias, José!

        More soon...

        -- Eric
        "Not my circus, not my monkeys."

        Comment


        • #5
          Originally posted by José Roca View Post
          You must be using an old version of win32api.inc. The latest one correctly defines it as &H0400.
          But the problem is not the value.. If win32api ones it one way, but we are using SQL Tools, then we want the value from SQL_Tools. THe problem is the name. Of course we could place one inside a compiler conditional directive to skip it if already defined.
          Barry

          Comment


          • #6
            The problem is not the name, but the value. It is not a SQLTools private constant that happens to have the same name, but a Windows API constant, and must have the correct value. The solution is to change the value in the SQLTools include file.
            Forum: http://www.jose.it-berater.org/smfforum/index.php

            Comment


            • #7
              Here is the resolution of this problem...

              PowerBASIC corrected an error in the WIN32API.INC file when the recent .02 versions were released. The SQL Tools INC files contained exactly the same error, and they have not (yet) been corrected, so when programs are compiled using SQL Tools and WIN32API.INC, the values conflict with each other. José is correct; all of the INC files refer to the same WIN32 API value, and the correct value for %LOCALE_USER_DEFAULT is &h0400 not &h0000.

              In the short term, SQL Tools users should edit their SQL_Std.INC or SQL_Pro.INC file to correct the value, as follows:
              Code:
              %LOCALE_USER_DEFAULT   = &h0400
              In the near future Perfect Sync will distribute updated INC files, but we want to make a few other tweaks and double-checks first.

              I apologize for any inconvenience that this has caused; I should have caught this during the beta-testing of the .02 compilers.

              -- Eric Pearson, Perfect Sync, Inc.
              "Not my circus, not my monkeys."

              Comment


              • #8
                Ah, so if I had read the help file, it would tell me that. Here's a case where the quick error code does not tell all, but the help file makes it obvious.
                Last edited by Barry Erick; 12 Oct 2009, 06:45 AM.
                Barry

                Comment


                • #9
                  >The problem is not the name, but the value.

                  I think the problem is "same name, different value"
                  Michael Mattias
                  Tal Systems (retired)
                  Port Washington WI USA
                  [email protected]
                  http://www.talsystems.com

                  Comment


                  • #10
                    In January 2009, I commented out these 2 lines in SQL_PRO.INC to avoid conflict:
                    Code:
                    %LOCALE_USER_DEFAULT   = &h0
                    %LOCALE_SYSTEM_DEFAULT = &h0800&

                    Comment

                    Working...
                    X