Results 1 to 9 of 9

Thread: Instrb No variant

  1. #1

    Thread Starter
    Lively Member
    Join Date
    Nov 2016
    Posts
    69

    Instrb No variant

    The Instrb function gives a "variant" value; it's certainly fast but it would be faster if it generated a "long" value. Has anyone ever programmed an alternative using eg. the api functions?

  2. #2
    Frenzied Member
    Join Date
    Feb 2003
    Posts
    1,369

    Re: Instrb No variant

    Odd, when I try "? typename(instrb("Test","e"))" in the immediate window I get "Long" as a result. How did you determine InstrB's return type?

  3. #3
    Frenzied Member
    Join Date
    Dec 2014
    Posts
    1,443

    Re: Instrb No variant

    unlikely.
    show the code that resulted in a variant.

  4. #4

    Thread Starter
    Lively Member
    Join Date
    Nov 2016
    Posts
    69

    Re: Instrb No variant

    MSDN LibraryVisual Studio 6 version writes: "INSTRB Returns a Variant (Long) that specifies the position of the first occurrence of one string within another."

  5. #5
    PowerPoster
    Join Date
    Feb 2006
    Posts
    22,501

    Re: Instrb No variant

    Both InStr() and InStrB() are legacy functions and both return a Variant of subtype Long. InStrRev() was new (in VB6?) and returns a proper Long.

  6. #6
    Frenzied Member
    Join Date
    Dec 2014
    Posts
    1,443

    Re: Instrb No variant

    maybe it means that depending on the type variable you use for the return value, it will convert into that but the default type is long.

    but looking here: https://docs.microsoft.com/en-us/ope...1-0acf1616f2f9

    Returns a Long specifying the position of the first occurrence of one string within another.

    so, not sure what that "variant" means.

  7. #7
    PowerPoster
    Join Date
    Feb 2006
    Posts
    22,501

    Re: Instrb No variant

    That documentation is wrong there, misstating reality.

    Look at the function prototype at the top of the page. It doesn't specify the return type, which mean Variant by default.

    Just like "Dim X" gives a Variant.

  8. #8
    PowerPoster wqweto's Avatar
    Join Date
    May 2011
    Posts
    3,094

    Re: Instrb No variant

    Btw, InStr is intrinsic function while VBA.InStr is typelib imported one. You are looking at the typelib prototype for the latter one. The MS-VBAL documentation describes the semantics of the former and it's up to the compiler to implement it whatever it seems fit depending on compilation size/performance options.

    When using both the compiler implements the callsite differently. The intrinsic directly calls ___vbaInStr export of MSVBVM60.DLL which accepts BSTR parameters on stack and returns *Long* result in eax register while VBA.InStr painfully converts all parameters to Variants using __vbaVarDup and then the result back from Variant indeed.

    cheers,
    </wqw>

  9. #9
    PowerPoster
    Join Date
    Feb 2006
    Posts
    22,501

    Re: Instrb No variant

    There is a pitfall to be aware of when replacing InStrB() with an API call.

    The VB-callable entrypoints I have found are not BSTR-aware. They can still be used until you have a case that runs aground on a rock, and that rock is the presence of NUL characters in your String.

    They expect "sz" type C strings where a NUL marks the end of the buffer. So they can exit early and report "not found" when your BSTR value does indeed have the target substring somewhere after any in-band NUL characters (within the value buffer of the BSTR).

    One obvious culprit here is StrStrA() in SHLWAPI. There are lots more in various C runtime libraries.


    While we can often avoid treating NUL as a valid character within actual text, binary data is another matter entirely. This can make InStrB() a powerful ally despite its overhead, and often BSTR (String) typed buffers can be better than Byte arrays.

    That may not be perfect but it has that significant advantage of NUL-bearing and searchability. Sadly far too many coders screw it up by using StrConv() inappropriately and misunderstanding the paradigm of "BSTR as binary buffer" in general. It's an advanced technique that can bite the best of us.

    That's one more argument in favor of the information hiding power of classes. By keeping "tricky" code encapsulated and reusing it any bugs can be found and squashed in one place. This focus can help raise confidence that you just can't have if you constantly copy/paste code inline and slap it around until it "seems to work."

    Oops, that's another thread.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Click Here to Expand Forum to Full Width