Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
New Contributor I

Breakpoint broken and DC's not easily available

My x86 code started having problems so I put a breakpoint but the debugger in MSVS 2013 just seemed to ignore it. I was building in Debug X86 mode and my code fragment looks like:

!======================================
      case (WM_PAINT)
!======================================
   if (message == WM_PAINT) Then
      type *, 'same here in case -- message = ', message
   end if
         if (codex == 10) Then
            codex = 0
            Call SetupMyDlg(.FALSE., codex)
            codex = 1
         End If
         Call MyHeaderOut()
         hDC = BeginPaint(ghWndMain, lp)
         if (hDC == NULL) Then
            hDC = GetDC(ghWndMain)
            if (hDC == NULL) Then
               bret = Beep( 950, 2400)
               bret = Beep( 250, 600)
               bret = Beep( 950, 2400)
               type *, 'Could not get a hDC', rectp
               return
            End If
         End If

It turned out that under certain options, I wasn't able to get a DC (3 tones beeped), but under all the other, it got a DC with no problems. All 5 options (gMyOption) come through OK except for bMyOption = 1. All the other seem to work OK. Any suggestions on (1) why debugger will not break and (2) why DC's have avbailability issues?

Thanks,

Brooks Van Horn

0 Kudos
1 Reply
Highlighted
Black Belt

Breakpoints being ignored

Breakpoints being ignored might be a symptom of the source file that you are setting the breakpoint in not being relevant to the EXE or DLL being debugged - for example perhaps the EXE or DLL being debugged is not what you think it is, or the EXE or DLL has not been built with debug information.

There is insufficient information to say much about getting a NULL HDC, noting that you mention variables in your description that don't appear in the stretch of code (what do you mean by "certain options"?), no variable declarations are shown and debugging entire programs based on a very limited fragment of code is always going to be an exercise in guessing. 

Random points of speculation or observation:

- Inspect the result of a call to GetLastError to get additional information on why a particular Windows API call failed (call GetLastError immediately after a failing API call).

- What does SetupMyDlg do?  If it displays another dialog then that could cause many problems.

- If MyHeaderOut does graphics rendering then it is outside the begin/end paint pair.

- If the HDC from BeginPaint is null then something is seriously wrong (or what you are supplying as the paint struct argument is bad in some way) - calling GetDC will likely just repeat the failure.

- Inability to acquire a DC suggests that you have a GDI object leak somewhere - i.e you are creating objects without deleting them.

- `type` is not a standard conforming Fortran statement - given it offers nothing over a print statement I would strongly recommend sticking with the standard print form.

 

0 Kudos