0

I have an application that handles the the CM_DIALOGKEY message on it's main form.

procedure CMDialogKey(var Message: TCMDialogKey); message CM_DIALOGKEY;

This worked up until some point recently, but I can't figure out at what point something was changed, and more importantly what. If I create a blank application, put in the message handler above then the message is handled and I can do things on certain keystrokes. Somewhere along the line some code must have been added that handles a message and doesn't propogate that message, but for the life of me I can't figure out what. Any ideas on how to go about debugging this? Breakpoints are obviously out of the question, unless someone has an idea of a breakpoint somewhere specific.

Steve
  • 6,382
  • 3
  • 41
  • 66
  • Use your version control repo to isolate the change in code that led to the change in behaviour. Alternatively make an SSCCE. – David Heffernan Nov 04 '13 at 10:11
  • You can put a breakpoint in TWinControl.CNKeyDown, press Tab and find out why CM_DIALOGKEY is not performed. – Sertac Akyuz Nov 04 '13 at 11:16
  • 1
    Surely you have some sort of version control? This should be pretty easy - go back to the last version that worked, compare it to the first version that didn't.... – J... Nov 04 '13 at 11:25
  • 1
    I suspect the problem is due to an upgrade in a third party component set. That's a large commit, and even if I find which update caused the problem, I still will need to see what creates the problem. sure, that should really be the work of the Third party developer, but I've found, from previous experience, that if you can say a little more than "It does't work", you're more likely to get an decent answer. – Steve Nov 04 '13 at 11:41
  • You could try using `SetWindowsHookEx` to try to catch the message, either before or after (or both) whatever window procedure processes it. – J... Nov 04 '13 at 12:07

1 Answers1

1

Any ideas on how to go about debugging this?

Here's how I would go about debugging this:

  1. Use your version control system to isolate the commit that changed behaviour.
  2. Using the last commit that worked as intended, set a breakpoint in CMDialogKey.
  3. Run the program until the breakpoint triggers and make a copy of the call stack in this state.
  4. Switch to the first commit that does not work. Now set a breakpoint higher up the call stack from step 3 which does trigger. You may need to work a little to find such a place, and you may need to use a conditional breakpoint. For instance you might need the condition Message.Msg=CM_DIALOGKEY.
  5. Now step forwards and find the point at which the execution diverges from the call stack seen in step 3.

At this point you should have isolated the behaviour change and be in a position to investigate a solution.

David Heffernan
  • 601,492
  • 42
  • 1,072
  • 1,490