Results 1 to 4 of 4
  1. #1
    Join Date
    Nov 2001
    Posts
    45

    Question Unanswered: New results: This function@subform crashes - but why?

    For those who were following my miserable quest on why access 2002 form crashes for no obvious reason (thank you for all the tips already), I have a new theory. By removing some related code, so far I had no crashes any more. However this code is essential for me to display data in a sub form:

    Function bitCompare(intByte As Byte, intBitNumber As Integer) As Boolean
    If (intByte And 2 ^ intBitNumber) Then bitCompare = True Else bitCompare = False
    End Function

    This one takes a byte value (which is actually saved in the record as a byte integer number) and checks if a specific bit (numbered 0 to 7) is set or not set. I am doing it this way to save space (1 byte < 2 bytes * 8 checkboxes = 16 bytes).
    In a continous subform I then have several checkboxes with controlsource properies "=bitCompare(intByte@record, 0/1/2/3/etc..."

    This code works fine - it does what it is supposed to do. Except it crashes sometimes...
    - Is anything wrong with this code?
    - Are 150 executions of this code (= # of entries @ subform) too much for Access?

    (Problem is I can not go back to true boolean values, because large amounts of data were input already; also this would increase the size of the database by factor 16 (10 MB -> 160 MB - undiscussable!))

  2. #2
    Join Date
    Dec 2002
    Location
    Préverenges, Switzerland
    Posts
    3,740
    i have seen a2k get confused when lots of things are happening: in my case it was a report of 50 pages containing 16 graphs on each page: data sometimes showed up on the wrong page ...it seemed to be printer driver dependent (worse with PCL drivers than with PS drivers). this did not happen in a95

    the only way i could get this report to work for me in a2k was to generate one page of the report then doEvents and then move on to the next page etc.

    have you got somewhere in the code you could doEvents or otherwise commit pending transactions

    also try some checking in your function:

    Function bitCompare(intByte As Byte, intBitNumber As Integer) As Boolean
    on error goto err_bitCompare
    if isnull(intByte) then msgbox "null intByte"
    if isnull(intBitNumber) then msgbox "null intBitNumber"
    If (intByte And 2 ^ intBitNumber) Then bitCompare = True Else bitCompare = False
    exit bitCompare:
    exit function
    err_bitCompare:
    msgbox err.description
    resume err_bitCompare
    End Function

    bool is not so convenient as a return: consider returning an integer instead with 0=false; -1=true; AND -99 as an error return so the above becomes:

    ...
    msgbox err.description
    bitCompare = -99
    resume err_bitCompare
    ...

    then your caller must check the return instead of simply using it:

    ......
    dim bitCompareReturn as integer
    bitCompareReturn = bitCompare(x, y)
    if bitCompareReturn = -99
    'handle the error
    else
    'yourBoolresult = bitCompareReturn
    endif
    ......


    izy

  3. #3
    Join Date
    Nov 2001
    Posts
    45
    Rehi izy:-)

    I tried your code (also with DoEvents inside) but no luck just plain stupid crashes... this is unbelievable - i couldnt even find anything at microsoft...

  4. #4
    Join Date
    Dec 2002
    Location
    Préverenges, Switzerland
    Posts
    3,740
    hi^2 waldemar

    well now, if the inbound parameters are not null and there is no error triggered in bitCompare it looks like it is the caller that is crashing... either it can't call bitCompare or it can't handle the return from bitCompare. consider adding further checks to bitCompare to ensure that the parameters it receives are within bounds (e.g. intBitNumber > 0 and < 9 etc)

    if you are using bitCompare directly as a value for a field/textbox etc, please give some detail. otherwise, if you are calling bitCompare from code, for your calling routine "mysub", consider something like this:

    private sub mysub()
    ' this is the routine that calls bitCompare
    on error goto err_mysub_1
    dim tempResult as boolean ' store bitCompare's return
    ' ...your preliminary code...
    on error goto err_mysub_2 ' you are just about to call bitCompare
    tempResult = bitcompare x, y ' your bitCompare call
    on error goto err_mysub_3 ' you have done messing with bitCompare
    ' now use tempResult to do whatever you used to do
    ' with the return from the call to bitCompare
    ' ...the rest of your code...
    exit_mysub:
    exit sub
    err_mysub_1:
    msgbox "mysub crashed, before calling bitCompare"
    resume exit_mysub
    err_mysub_2:
    msgbox "mysub crashed calling byteCompare with " & x & "," & y & ", " & tempResult
    resume exit_mysub
    err_mysub_3:
    msgbox "mysub crashed after successfully calling bitCompare
    resume exit_mysub
    end sub

    hopefully this + the suggested error trapping in bitCompare will show what is crashing when.



    150 calls is too many for manual breakpoints... instead consider a public variable CallsToBitCompare and at each entry to bitCompare do a
    CallsToBitCompare = CallsToBitCompare + 1
    and check the count each time you crash: maybe you have one renegade record you can track down this way.


    izy

Posting Permissions

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