No announcement yet.

VARPTR problem

  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    Anyway, I spent today looking into this some more, and based on
    what I read in the MSDN, I see that PB is interpreting VB zero-
    length strings incorrectly. A zero-length VB string has a valid
    non-null address. When a VB program needs to pass an actual null
    string to an API as opposed to "", this is done by passing
    vbNullString. However, when "" is passed from VB to PB's ASCIIZ
    argument, the "" is incorrectly interpreted the same as
    No, it's not. When VB converts an empty string to ASCIIZ, it does so by creating
    a string consisting only of a NUL terminator and passing that. This is fine with
    PowerBASIC. Your test program was for PowerBASIC, not VB, and PowerBASIC converts
    dynamic strings to ASCIIZ differently. The preferred solution, in PB, is to pass
    an actual ASCIIZ when a function expects an ASCIIZ. Otherwise, you may end up with
    a null pointer, which is what an empty dynamic string looks like.

    Tom Hanlin
    PowerBASIC Staff


    • #22
      Tom, I did some further testing, and I see that my statement
      about VB/PB string parameters was incorrect. I had done a lot of
      testing, but I must have compared the wrong results together.
      I was about to post an example, but then I found from testing,
      and from the documentation, that an un-initialized VB string is
      treated as an empty string from within VB. However, when you pass
      an un-initialized string to an outside function which takes fixed-
      length strings, then it's passed as a NULL, just like
      vbNullString. So PB was receiving the info just the way VB
      sent it, and what VB was sending was consistent with the way
      they documented it. So I learned that there's a subtle difference
      in VB between an un-initialized string and an empty string.

      I shouldn't have included VB in the discussion. My original
      concern in this thread was about why within PB an empty literal
      string was received as a NULL from another PB routine. I still
      would like to see PB pass a literal empty string, "", as a valid
      non-null pointer to a routine that expects an ASCIIZ argument
      (from within PB). This would be consistent with the way PB correctly
      handles incoming literal empty strings from elsewhere, as well as
      how other compilers I've tested handle such strings from within.

      Notice, that I'm particularly speaking about a literal, "", string
      argument as opposed to a dynamic string variable. (PB doesn't
      even let you pass a dynamic string variable directly when an ASCIIZ
      argument is expected. It requires you to place BYCOPY if the argument
      is a dynamic string. And in this case also, it wouldn't hurt to
      pass the BYCOPYed pointer to a non-zero address for empty string

      Lance, concerning global error handling, I don't necessarily have
      a specific idea in mind. I'm not even sure if global error
      is the best term to describe what I want. There are
      several alternatives that would be easier than the current
      On Error GoTo. One straight-forward possibility is something
      like what VB does (and even PB/DOS if I remember correctly).

      When you click on "Run" from the IDE, it would attempt to run
      the program to completion, but it would pause if ERR is set, and
      place the cursor at the most recently executed line of code.
      I have alternative code inside #IF/#ELSE blocks which allows me
      to run a simple "host" program from PB/CC which uses the DLL code.
      So that part wouldn't be a problem.

      In the particular situation I was in, this would have allowed me
      to quickly rule out a lot of code that I had to sequentially step
      into, or surround with On Error GoTo (which in my case
      modified the flow of my program to cause another error on top of
      the one I was looking for. And the place where I concentrated on
      placing a lot of error handling code was nowhere near the source of
      the error, which was yet somewhere else from where it was crashing).

      I would also like support for TRY/CATCH as well, but for a
      different reason. The global error handler would be as a kind
      of scaffold, mostly of use in the development stage. When the
      project is nearly completed the programmer would remove it,
      since it would no longer be needed. But the TRY/CATCH method
      would be of use, optionally, in a finished program.

      Interestingly, I use Try/Except in the Delphi sample program that
      calls my PB DLL (you can do it with C++ also). PB does not catch
      things like numeric overflow, whereas the Delphi host program that
      calls my DLL catches them. So it would seem like something that
      shouldn't be too difficult to add. It's probably like an
      extension of On Error GoTo, except it can handle Overflow and
      others, and the Try/Catch syntax would be familiar to people who
      are using other compilers.

      Daniel Corbier
      UCalc Fast Math Parser
      Daniel Corbier
      uCalc Fast Math Parser
      uCalc Language Builder