Announcement

Collapse
No announcement yet.

illegal operation after call pbDLL from VB6

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

  • Fred Oxenby
    replied
    Tim,
    your prototype tells the compiler how to pass the variable.
    You cannot change this in your call unless you use as Any
    For strings (in VB) the default is ByRef.
    Code:
     RunReport nCount, (sDirList), sStart, (sEnd)
    The code above instructs the compiler to
     make a copy of sDirList and sEnd and pass this copies to the sub
     pass the original sStart .
    My intention was to show this diffrence
    are the parens on the variables what forces a ByRef in VB?
    No they "simulate" a ByVal


    -------------
    Fred
    mailto:[email protected][email protected]</A>
    http://www.oxenby.se

    Leave a comment:


  • Guest's Avatar
    Guest replied
    Fred -

    The convertion from ByVal to ByRef did the trick. Many thanks. I have an additional question, though -- are the parens on the variables what forces a ByRef in VB? I was unable to locate any information in the online help in VB about that and trying to put 'ByRef' in the call statement met with "type mismatch" messages from the compiler. Also, I assume that the omission of the parens on the third parameter (sStart) was unintentional.

    Can you or anyone else recommend a good reference book for VB?

    Again, many thanks.


    -------------
    Tom Vance
    CCI
    (317)579-2525

    Leave a comment:


  • Fred Oxenby
    replied
    Just a short follow-up
    From a VB-programmers standpoint there are a important diffrence
    between a "STRING" and an "ASCIIZ"-string.
    "ASCIIZ"-strings cannot represent the character 'NULL' Chr$(0)
    That is: If your string "might" include chr$(0) do not use ASCIIZ


    -------------
    Fred
    mailto:[email protected][email protected]</A>
    http://www.oxenby.se

    Leave a comment:


  • Dave Navarro
    replied
    This is from Appendix B in the PB/DLL 6.0 help file:

    Many API calls require ASCIIZ, or nul-terminated strings. Visual Basic does not natively support this data-type, so it relies on a “kludge” to pass the correct data. To pass an ASCIIZ string, you add the ByVal keyword to the Declare statement or Call,
    Code:
      Call PowerBasicDll(ByVal MyString$)
    Visual Basic converts the data in MyString$ to ANSI format with a nul (or CHR$(0)) appended to the end of it, and passes a memory address to the location of the string data. PowerBASIC does natively support ASCIIZ string, so the ByVal keyword is not used:
    Code:
      SUB PowerBasicDll(MyString AS ASCIIZ) EXPORT
        REPLACE "the" WITH "The" in MyString
      END SUB
    What you need to do is use "ASCIIZ" strings in PowerBASIC when you pass a string BYVAL from Visual Basic.

    --Dave


    -------------
    PowerBASIC Support
    mailto:[email protected][email protected]</A>

    Leave a comment:


  • Fred Oxenby
    replied
    Sending a STRING BYVAL in Visual Basic is something complete different
    from sending it BYVAL in POWERBASIC.
    As I am comfortable with using OLE-strings I always use
    BYREF STRING when I create DLL-s intended to be used from Visual Basic.

    You have to change your PB/DLL like this
    Code:
    SUB RunReport alias "RunReport" _
                  (BYVAL ReportNumber AS INTEGER, _
                   BYREF DirectoryList AS STRING, _
                   BYREF StartingDate AS STRING, _
                   BYREF EndingDate AS STRING) EXPORT
    Change your VB prototype as follows:
    Code:
    Declare Sub RunReport Lib "ter32.dll" _
                (ByVal ReportNumber As Integer, _
                 ByRef DirectoryList As String, _
                 ByRef StartingDate As String, _
                 ByRef EndingDate As String)
    In VB you now have the ability to protect your strings from being
    altered in the DLL via the ByCopy-directive
    call:
    RunReport nCount, (sDirList), sStart, (sEnd)
    -------------
    Fred
    mailto:[email protected][email protected]</A>
    http://www.oxenby.se




    [This message has been edited by Fred Oxenby (edited January 05, 2000).]

    Leave a comment:


  • Guest's Avatar
    Guest replied
    I'm the programmer working on the problem posted by Doug. The VB prototype and call are as follows:

    prototype:
    Declare Sub RunReport Lib "ter32.dll" _
    (ByVal ReportNumber As Integer, _
    ByVal DirectoryList As String, _
    ByVal StartingDate As String, _
    ByVal EndingDate As String)

    call:
    RunReport ByVal nCount, ByVal sDirList, ByVal sStart, ByVal sEnd

    The prototype in the PB code:
    DECLARE SUB RunReport ALIAS "RunReport" (BYVAL ReportNumber AS INTEGER, BYVAL DirectoryList AS STRING, _
    BYVAL StartingDate AS STRING, BYVAL EndingDate AS STRING)

    The PB SUB Statement:
    SUB RunReport(BYVAL ReportNumber AS INTEGER, _
    BYVAL DirectoryList AS STRING, _
    BYVAL StartingDate AS STRING, _
    BYVAL EndingDate AS STRING) EXPORT




    -------------
    Tom Vance
    CCI
    (317)579-2525

    Leave a comment:


  • Lance Edmonds
    replied
    It sounds like a parameter passing issue, causing VB to fail when the DLL code returns. Post your PB function prototype(s) and the VB declaration(s), and we'll see if we can spot anything.


    -------------
    Lance
    PowerBASIC Support
    ( mailto:[email protected][email protected]</A> )

    Leave a comment:


  • Guest's Avatar
    Guest started a topic illegal operation after call pbDLL from VB6

    illegal operation after call pbDLL from VB6

    I have used PBDLL to create a standalone EXE that works fine. I had the runtime parameters hard coded into the program. I have now changed the code to be a DLL and am trying to call the DLL from a VB6 program which collects the run time info from the user. The VB program manages to call the DLL and pass the runtime info. The DLL computes the report and then displays the report on the screen. I use DDOC to accomplish the print/preview. Next I get "program has preformed an illegal operation".
    DDOC is still running I can view and print the report and close the DDOC window. I never get past the call to the DLL in the VB program. Some how I am causing VB to kick out this error. Any ideas?
Working...
X