Announcement

Collapse
No announcement yet.

Stack Fault Troubleshootingl

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

  • Stack Fault Troubleshootingl

    Using PB/DLL 6.0 and "API style" (i.e., not DDT) programming, I am developing a program which is basically a single dialog box (currently modal). In the dialog box procedure I am frequently resetting dialog items using SendMessage to the dialog box itself (e.g., BM_SETCHECK).

    I have been generating "stack fault" illegal operations and was trying to figure out where the problem is, and I "think" the problem is in re-entrancy: there are a number of places where I re-use the same LOCAL dataname to aid in processing a message.

    In general, is a good place to look for the source of "stack fault" errors in "re-entrancy" problems? That is, am I looking in the right place, or should I be looking elsewhere?

    Thanks,
    MCM
    Michael Mattias
    Tal Systems Inc. (retired)
    Racine WI USA
    [email protected]
    http://www.talsystems.com

  • #2
    After ruling out the obvious for example, variables too large for the stack, infinite looping is what
    I check for next(generates a stack fault in a hurry).
    Here are some examples that generate a loop condition unless extra code is written to detect it.
    [
    FUNCTION Test_WndProc(BYVAL hWnd AS LONG, BYVAL lMsg AS LONG, BYVAL lParam1 AS LONG, BYVAL lParam2 AS LONG) AS LONG

    1. Sending the same message to the window or a function that sends the same message to the window.
    CASE %WM_MOVE
    SendMessage hWnd, %WM_MOVE, 0, MAKLNG(x, y)
    or this
    SetWindowPos hWnd, %NULL, x, y, 0, 0, %SWP_NOSIZE OR %SWP_NOZORDER

    2. A message spawning other messages or a function that spwans messages.
    CASE %WM_WINDOWPOSCHANGING
    SendMessage hWnd1, %WM_MOVE, 0, MAKLNG(x,y)
    or this
    SetWindowPos hWnd1, %NULL, x, y, 0, 0, %SWP_NOSIZE OR %SWP_NOZORDER

    If hWnd and hWnd1 are both child controls or are both top level windows then this will cause
    a loop condition. This is because changing the position of a window generates WM_WINDOWPOSCHANGING
    messages to its siblings. This is why it is important to know what messages functionA or messageB
    will generate.

    Here is another example
    CASE %EN_UPDATE
    code to check and change contents of edit control before contents are displayed
    (e.g. contents must be within 10 and 100)
    SetWindowText hWndEdit, lpString1

    SetWindowText generates EN_UPDATE and EN_CHANGE message.

    3. ControlA sends a message to controlB which in turn sends a message to controlA or vice versa.
    Buddy controls are a good example of this.
    hWnd1 = edit control, hWnd2 = updown control
    CASE EN_CHANGE
    SendMessage hWnd2, %UDM_SETPOS, 0, n

    This will generate a loop condition because when the updown control receives this message it
    sends WM_SETTEXT to the edit control which give rise to EN_UPDATE and EN_CHANGE messages.

    These examples are taken from memory and they not things one will normally do but I hope this helps.

    Oops! Reuse of local variables is not a problem unless you are using them to update global or
    static variables.

    ------------------
    Dominic Mitchell



    [This message has been edited by Dominic Mitchell (edited August 17, 2000).]
    Dominic Mitchell
    Phoenix Visual Designer
    http://www.phnxthunder.com

    Comment


    • #3
      Thank you for that. I was able to get the stack fault fixed by doing pretty much what you suggested; that is, not using SendMessage (to a dialog box) except when I am sure there are no messages generated by the message.

      You have one example there - EN_CHANGE with an up-down-buddy - I was GOING to do tomorrow, but I think I will find an alternate method.

      Regards,
      MCM
      Michael Mattias
      Tal Systems Inc. (retired)
      Racine WI USA
      [email protected]
      http://www.talsystems.com

      Comment


      • #4
        Sending messages to a window procedure from the same window
        procedure is not the problem. That is a normal thing to do.
        The problem is knowing when infinite loops will occur and how
        to avoid them.
        Actually using buddy controls is not difficult once you understand
        how they interact. Here is a code snippet from a sdk style dialog
        that allows the user to input the color of an object in four ways.
        The actual rgb values of the color the user selects via these four
        methods are displayed in the edit controls.
        1. System color - dropdown combobox
        2. Basic colors(colored squares) - hit testing(left mouse button)
        3+4. Custom colors - edit/updown buddy control pairing
        Code:
          
            ' Hit testing
            ' -----------
            ' I am actually updating the edit control via the UDM_SETPOS message
            ' since it generates a WM_SETTEXT message to the buddy of the updown control.
            ' The edit control generates EN_UPDATE and EN_CHANGED notifications.
            CASE %WM_LBUTTONDOWN
              ilTbl = Color_GetIdxAtCursor(tclr, LoIntVPB(lParam2), HiIntVPB(lParam2))
              IF ilTbl <> %FUNC_ERR THEN
                ' Set do not use system color
                SendMessage tclr.hWndCombo(0), %CB_SETCURSEL, 0, 0
                IF tclr.dwColor(ilTbl) <> dwColor THEN
                  ' The new color is saved during WM_COMMAND(EN_CHANGED)
                  SendMessage tclr.hWndUpDown(0), %UDM_SETPOS, 0, GetRedValue(tclr.dwColor(ilTbl))
                  SendMessage tclr.hWndUpDown(1), %UDM_SETPOS, 0, GetGreenValue(tclr.dwColor(ilTbl))
                  SendMessage tclr.hWndUpDown(2), %UDM_SETPOS, 0, GetBlueValue(tclr.dwColor(ilTbl))
                END IF
              END IF
              SetFocus tclr.hWndEdit(0)
              FUNCTION = %FALSE
              EXIT FUNCTION
        
            ' User clicked updown control
            ' ---------------------------
            ' Clicking the updown control generates a WM_SETTEXT message which
            ' updates the edit control.
            CASE %WM_VSCROLL
              ' Set do not use system color
              SendMessage tclr.hWndCombo(0), %CB_SETCURSEL, 0, 0
                 
            CASE %WM_COMMAND
               
              SELECT CASE HIWRD(lParam1)
                ' User types something in edit control
                ' ------------------------------------
                ' This message is generated when the user types something in the edit
                ' control.  This demonstrates limiting text input. Notice that this
                ' causes a loop but that it is not infinite.
                CASE %EN_UPDATE
                  ' Get the current value in the edit control
                  lCount = SendMessage(lParam2, %WM_GETTEXT, 10, BYVAL lInfoAddr)
                  ' If there is text in the control
                  IF ISTRUE lCount THEN
                    IF VAL(szInfo) > 255 THEN
                      szInfo = "255"
                      SendMessage lParam2, %WM_SETTEXT, 0, BYVAL lInfoAddr
                    END IF
                  END IF
                   
                ' User types something in edit control
                ' ------------------------------------
                CASE %EN_CHANGE
                  ' Get the current value in the edit control
                  lCount = SendMessage(lParam2, %WM_GETTEXT, 10, BYVAL lInfoAddr)
                  ' If there is text in the control
                  IF ISTRUE lCount THEN
                    ' If the edit control has the keyboard focus the
                    ' user is entering test directly into the control
                    IF lParam2 = GetFocus() THEN
                      ' Set do not use system color
                      SendMessage tclr.hWndCombo(0), %CB_SETCURSEL, 0, 0
                    END IF
                    ' Get the red, green and blue values
                    ' When the updown control receives the UDM_GETPOS message it
                    ' sends a WM_GETTEXT message to the edit control.  The following
                    ' calls cause the updown controls to update their current positions
                    ' base on the captions of the edit controls.
                    bRed   = SendMessage(tclr.hWndUpDown(0), %UDM_GETPOS, 0, 0)
                    bGreen = SendMessage(tclr.hWndUpDown(1), %UDM_GETPOS, 0, 0)
                    bBlue  = SendMessage(tclr.hWndUpDown(2), %UDM_GETPOS, 0, 0)
                    ' Calculate 32-bit rgb value
                    dwColor = GetRGB(bRed, bGreen, bBlue)
                          .............
                   ' Code for updating the colored square with the focus
                          .............
        ------------------
        Dominic Mitchell



        [This message has been edited by Dominic Mitchell (edited August 17, 2000).]
        Dominic Mitchell
        Phoenix Visual Designer
        http://www.phnxthunder.com

        Comment

        Working...
        X