Announcement

Collapse
No announcement yet.

my dll causes windows fault

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

  • Michael Mattias
    replied
    I'm not mellowing out at all; I have been saying this for years.

    But if it makes you feel better....

    "A signicantly higher rate should be expected if one includes as compiler problems user mistakes directly attributable to inaccurate, incomplete, hard-to-find or misleading documentation."

    Happy now?

    (I've been saying that for years, too.)

    MCM

    Leave a comment:


  • Gösta H. Lovgren-2
    replied
    Originally posted by Michael Mattias View Post
    Some day I would like to see a statistic from all the years of support calls taken by PowerBASIC: "Percent of calls claiming compiler problem which turned out to be user problem rather than compiler problem."

    One, two percent tops is where I'd put my money.

    There are some bugs to be sure, but not very many. Compiler problem is the last place to look for program problems.
    Must be springtime in Minnesota. M's getting mellow again. {grin}

    (I know, I know. He lives in Wisconsin but that's not as alliteral.)

    =========================================
    "My advice to you is get married:
    if you find a good wife you'll be happy;
    if not, you'll become a philosopher."
    Socrates (470-399 B.C.)
    =========================================

    Leave a comment:


  • Michael Mattias
    replied
    Some day I would like to see a statistic from all the years of support calls taken by PowerBASIC: "Percent of calls claiming compiler problem which turned out to be user problem rather than compiler problem."

    One, two percent tops is where I'd put my money.

    There are some bugs to be sure, but not very many. Compiler problem is the last place to look for program problems.

    Leave a comment:


  • Cliff Nichols
    replied
    that is why I did not cry "bug", because my problems are 99.99% my programming errors.
    Oh come now, don't you know that "It could NOT be my code, it MUST be a PB problem???"

    Honestly though, its nice to see that someone can admit their mistakes, and not blame it on the compiler.

    Leave a comment:


  • John Tate
    replied
    Thanks, Michael. I feel really stupid! I thought I was a better programmer than that!!
    In any case, that is why I did not cry "bug", because my problems are 99.99% my programming errors.

    Even though I solved the problem by using parse$, I still wanted to know why it would not work using Parse.

    Thanks again,

    John Tate

    Leave a comment:


  • Michael Mattias
    replied
    Code:
    'x = PARSECOUNT(USERDATE,ANY "./-")
    'REDIM Ud(1 TO x)
    'PARSE userdate,Ud(),ANY ",./-"
    Your parse strings are different: one includes comma, one does not. If the input uses comma as a delimiter, the array will not be large enough to hold all the elements and you will commit an array bounds violation (error 9).

    Good place to take out insurance against mistyped "magic numbers" ...

    Code:
      LOCAL Delim  AS STRING 
      Delim = ",./-" 
    ...
      X        =  PARSECOUNT (UserDate, ANY Delim) 
      REDIM     UD (1 TO X) 
      PARSE     UserDate, UD(), ANY Delim

    MCM
    Last edited by Michael Mattias; 24 May 2009, 08:32 AM.

    Leave a comment:


  • John Tate
    replied
    Here is what I have found out so far. It is the assignment statements in the dll where I assign val(array var) to a long var.
    I have been using parse(string, any char) to fill my array with the month,day and year from the date string. If I use parse$ only, I get no error 9.
    Strange. What am I doing wrong?

    John Tate

    Code:
    #COMPILE DLL
    #DIM ALL
    
    %USEMACROS = 1
    #INCLUDE "Win32API.inc"
    
    GLOBAL ghInstance AS DWORD
    
    
    
    
    
    
    
    '-------------------------------------------------------------------------------
    ' Main DLL entry point called by Windows...
    '
    FUNCTION LIBMAIN (BYVAL hInstance   AS LONG, _
                      BYVAL fwdReason   AS LONG, _
                      BYVAL lpvReserved AS LONG) AS LONG
    
        SELECT CASE fwdReason
    
        CASE %DLL_PROCESS_ATTACH
            'Indicates that the DLL is being loaded by another process (a DLL
            'or EXE is loading the DLL).  DLLs can use this opportunity to
            'initialize any instance or global data, such as arrays.
    
            ghInstance = hInstance
    
            FUNCTION = 1   'success!
    
            'FUNCTION = 0   'failure!  This will prevent the EXE from running.
    
        CASE %DLL_PROCESS_DETACH
            'Indicates that the DLL is being unloaded or detached from the
            'calling application.  DLLs can take this opportunity to clean
            'up all resources for all threads attached and known to the DLL.
    
            FUNCTION = 1   'success!
    
            'FUNCTION = 0   'failure!
    
        CASE %DLL_THREAD_ATTACH
            'Indicates that the DLL is being loaded by a new thread in the
            'calling application.  DLLs can use this opportunity to
            'initialize any thread local storage (TLS).
    
          '  FUNCTION = 1   'success!
    
            'FUNCTION = 0   'failure!
    
        CASE %DLL_THREAD_DETACH
            'Indicates that the thread is exiting cleanly.  If the DLL has
            'allocated any thread local storage, it should be released.
    
         '   FUNCTION = 1   'success!
    
            'FUNCTION = 0   'failure!
    
        END SELECT
    
    
     END FUNCTION
    
     FUNCTION Juliandate ALIAS "Juliandate" (BYVAL userdate AS STRING) EXPORT AS LONG
    
    LOCAL MONTH ,DAY ,YEAR AS LONG
    LOCAL m,d,y,jdn,a  AS LONG
    LOCAL UD() AS STRING,x AS LONG
    'x = PARSECOUNT(USERDATE,ANY "./-")
    'REDIM Ud(1 TO x)
    'PARSE userdate,Ud(),ANY ",./-"
    'all ok to here
    'the assignment statements below cause the error 9
    'm = VAL(Ud(1))
    'd = VAL(Ud(2))
    'y = VAL(Ud(3))
    'month = VAL(Ud$(1)):day = VAL(Ud$(2)) :year = VAL(Ud$(3))
    
    'using the parse$ causes no error 9
    month = VAL(PARSE$(userdate,ANY ",./-",1))
    day = VAL(PARSE$(userdate,ANY ",./-",2))
    year = VAL(PARSE$(userdate,ANY ",./-",3))
    
    IF year => 80 AND year <100    THEN year = year  +1900
    IF year <80 THEN year = year + 2000
    
        a = (14 - month)\12
        y = year + 4800 -a
        m = month +(12*a) - 3
        JDN = day +((153*m)+2)\5 + (365*y) + (y\4) - (y\100) +(y\400) - 32045
     '   END IF
    FUNCTION = jdn
    END FUNCTION

    Leave a comment:


  • Michael Mattias
    replied
    >It seems that the error was not so much in the dll itself.

    Great 'Real Life' demonstration that when memory corruption is involved, the error was not necessarily made immediately preceding the time of death.

    PS:
    It is obvious I do not know what I am doing with dlls.
    You're doing fine.

    Functions in DLLs are just like inline functions. The only difference is you need a DECLARE statement instead of an #INCLUDE file in the calling module.*



    MCM
    * Not including compiler-specific restrictions on inter-module validity of certain reference objects or handles such as DDT-created controls or file handles. You mileage may vary. Winner is responsible for all taxes. Void where prohibited

    Leave a comment:


  • John Tate
    replied
    I copied the code from my dll into a function that I used in then source program. I can now see that I have an error 9 showing up. I will search for the source of that error, which debug display says comes after execution of my new date conversion function.
    It seems that the error was not so much in the dll itself.

    I will pursue it in the morning. It is 12:40 pm in Oregon.

    John Tate

    Leave a comment:


  • John Tate
    replied
    I changed the byref to byval and I can run it twice in the IDE, but get the error the first time when running it from a menu that shells the calling exe file.
    Thanks, Edwin for helping.

    It is obvious I do not know what I am doing with dlls.


    John Tate

    Leave a comment:


  • Edwin Knoppert
    replied
    Change byref to byval.
    How did you come up with byref..?

    Returning non-zero in the libmain is required.

    Leave a comment:


  • John Tate
    started a topic my dll causes windows fault

    my dll causes windows fault

    I created a dll to convert a date string into the unique day number. I use this dll in several programs without any problems. However, one program causes the "windows must close" message after running the program 2 or three times in succession without closing the program. The details in the windows error seems to point to my dll.



    This is the declare I use for the dll.

    DECLARE FUNCTION JULIANDLL LIB "Julian.dll" ALIAS "Juliandate" (BYREF userdate AS STRING) AS LONG

    and here is the dll code

    Code:
    #COMPILE DLL
    #DIM ALL
    
    %USEMACROS = 1
    #INCLUDE "Win32API.inc"
    
    GLOBAL ghInstance AS DWORD
    
    
    
    
    
    
    
    '-------------------------------------------------------------------------------
    ' Main DLL entry point called by Windows...
    '
    FUNCTION LIBMAIN (BYVAL hInstance   AS LONG, _
                      BYVAL fwdReason   AS LONG, _
                      BYVAL lpvReserved AS LONG) AS LONG
    
        SELECT CASE fwdReason
    
        CASE %DLL_PROCESS_ATTACH
            'Indicates that the DLL is being loaded by another process (a DLL
            'or EXE is loading the DLL).  DLLs can use this opportunity to
            'initialize any instance or global data, such as arrays.
    
            ghInstance = hInstance
    
            FUNCTION = 1   'success!
    
            'FUNCTION = 0   'failure!  This will prevent the EXE from running.
    
        CASE %DLL_PROCESS_DETACH
            'Indicates that the DLL is being unloaded or detached from the
            'calling application.  DLLs can take this opportunity to clean
            'up all resources for all threads attached and known to the DLL.
    
            FUNCTION = 1   'success!
    
            'FUNCTION = 0   'failure!
    
        CASE %DLL_THREAD_ATTACH
            'Indicates that the DLL is being loaded by a new thread in the
            'calling application.  DLLs can use this opportunity to
            'initialize any thread local storage (TLS).
    
            FUNCTION = 1   'success!
    
            'FUNCTION = 0   'failure!
    
        CASE %DLL_THREAD_DETACH
            'Indicates that the thread is exiting cleanly.  If the DLL has
            'allocated any thread local storage, it should be released.
    
            FUNCTION = 1   'success!
    
            'FUNCTION = 0   'failure!
    
        END SELECT
    
    
     END FUNCTION
    
     FUNCTION Juliandate ALIAS "Juliandate" (BYREF userdate AS STRING) EXPORT AS LONG
    
    LOCAL MONTH ,DAY ,YEAR,ya,cf,yf,mf,century AS LONG
    LOCAL MJULIAN AS LONG
    LOCAL m,d,y,jdn,a  AS LONG
    LOCAL UD() AS STRING,x AS LONG
    x = PARSECOUNT(USERDATE,ANY "./-")
    REDIM Ud$(1 TO x)
    PARSE userdate,Ud$(),ANY",./-"
    
    m = VAL(Ud$(1)):d = VAL(Ud$(2)) :y = VAL(Ud$(3))
    month = VAL(Ud$(1)):day = VAL(Ud$(2)) :year = VAL(Ud$(3))
    IF year => 80 AND year <100    THEN year = year  +1900
    IF year <80 THEN year = year + 2000
    
        a = (14 - month)\12
        y = year + 4800 -a
        m = month +(12*a) - 3
        JDN = d +((153*m)+2)\5 + (365*y) + (y\4) - (y\100) +(y\400) - 32045
     '   END IF
    FUNCTION = jdn
    END FUNCTION
    I have written test code to verify that all the date strings sent to dll are correct. All dates are generated programatically in another program.

    I can usually fix errors with the PB tools, but "trace" and "debug display" show no errors. If someone would look at the compilable code in the zip file, I would certainly appreciate any help.

    Thanks,

    John Tate
    Attached Files
Working...
X