Stack Fault Troubleshootingl

[Michael Mattias]

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

[Dominic Mitchell]

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).]

[Michael Mattias]

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

[Dominic Mitchell]

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

  
    ' 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).]