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.
Any ideas on how to go about debugging this?
Here's how I would go about debugging this:
Use your version control system to isolate the commit that changed behaviour.
Using the last commit that worked as intended, set a breakpoint in CMDialogKey.
Run the program until the breakpoint triggers and make a copy of the call stack in this state.
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.
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.
Related
It often happens, to me, that after testing and making a build while I forget to check the activate property first. Then when I install the program on a different system an exception occurs due to failed connection. It's really annoying.
I've searched for a solution for a long time but it looks like it is impossible without making a new connection component inherited from TFDConnection. I don't want to do that and maybe someone here knows a simple way to get around this problem.
Check out the property ConnectedStoredUsage in TFDConnection.
That controls how to use the Connected property value saved to the DFM.
So for your need, you can uncheck auRunTime.
For more info on ConnectedStoredUsage, see the DocWiki.
I like to use these to debug (can you tell I'm a noob?) and have left them in my code as is when deploying to the app store. Are there any negative implications for this you can personally think of?
I have looked at these resources and I am getting the feeling it's not a good idea:
http://doing-it-wrong.mikeweller.com/2012/07/youre-doing-it-wrong-1-nslogdebug-ios.html
https://developer.apple.com/library/mac/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/LoggingErrorsAndWarnings.html#//apple_ref/doc/uid/10000172i-SW8-SW7
This was also a good resource:
http://www.theonlylars.com/blog/2012/07/03/ditching-nslog-advanced-ios-logging-part-1/
That said, when you ship to the store and DO keep NSLogs in there, what have you logged?
Create a snippet with the above settings. Where it says "debug statement", replace that with:
<#debug statement#>
Now, since the completion shortcut is set to "NSLog", every time you start typing NSLog, it will autocomplete to this snippet and you will have the "debug statement" part selected and ready to type over.
You'll never have to worry about commenting out your NSLog statements again, and you'll never have to forget about using #if DEBUG since the completion shortcut is what you would type anyway.
Apple's Official Documentation for creating a Snippet (I've included this link because I think it's really kind of sad that this is apparently the only way to do it?)...
And my explanation...
Copy and paste the following code into Xcode:
#if DEBUG
NSLog(<#debug statement#>);
#endif
Select the entire code block you just copy-pasted. Click, hold, and drag this code block down to the snippets section (usually in the bottom right corner).
Select this snippet to get a screen like this:
Click "Edit" and fill out the details. Give it a title and description. Leave platform on "All", and language on "Objective-C". Set the completion shortcut to "NSLog", and leave the completion scope on "Function or Method" (what this option defauts to may depend on where you pasted the code to originally and where you dragged it from).
As Aaron Brager's answer points out, NSLog could be a performance concern, particularly in loops (also in places that don't seem very much like loops but actually are, like cellForRowAtIndexPath...).
But more importantly, you may be exposing information you don't necessarily want to be made publicly available.
I'm not saying there doesn't exist something that might be useful to include to present to the end user in the log statements, but personally, I've yet to find it. How many times have you ever investigated the output of an app's log statements to diagnose an issue you were having with it? How many times have you contacted an app developer and they asked you to check these statements to help diagnose a technical issue you were having?
The Mike Weller post you linked makes the right call. NSLog is for user-facing warnings.
There also might be performance issues, especially within loops, since it uses a string formatter.
You can and should use DDLog or other tools to ignore the debug messages when you make your release build.
When I run my application it works well, but during transitions between its views I have a lot of CGContext errors in the console output, but the app still works well, no crashes or bugs I didn't see. Description: so I only run my app - all work well - but there appears error messages in the console:
And after any other view transition they appear again and again. So the question - how to fix this? And what may be the reason of this error messages? There a lot of views and code in my application so I don't even know what part is error-prone.But these messages appear after transitions between all views in my app. Thanks in advance.
Look for some method in your code where you call CGContextSaveGState, CGContextSetBlendMode, CGContextSetApha, etc. Chances are that you won´t find many places where you do that.
Well, if you find it, look for some statement (just before those listed in your console log) where a context is created, and try to understand why it fails. You may set a breakpoint on that line and inspect the parameters to the CGContextCreate call.
If you need more help, paste the code you have (hopefully) found.
I'm having trouble getting a windows service to start. Each time it runs, in the IDE, as a service, or otherwise, an error shows up in the windows event log stating:
"The service process could not connect to the service controller."
When debugging, I can step through the ServiceCreate procedure, and I successful print to a log file there. However, I have identical code (save the message string) in the ServiceStart or ServiceExecute procedures and it never appears to run.
The debugger lets me step into Application.CreateForm, which jumps straight to the ServiceCreate procedure but I cannot step into Application.Run.
Any ideas?
Edit: To clarify, I am debugging by starting the windows service, then attaching to the process in Delphi during a wait that I added to start up.
Edit 2: Okay, it's now letting me step into Application.Run and more details where ever I want. I had turned off debug dcus. Thought stepping through the VCL code did nothing to help me see what the problem was. I still have no idea how ServiceStart or ServiceExecute are supposed to get called.
this is the only error message you receive? what code do you have in the initialization section of your pas files? this error is generally raised when an error is raised and your application doesn't catch it. try to log all the events from app. also, take a look into the Windows event viewer for more details related to this.
I'm developing a Word addin, and somehow the shortcuts defined in TAction.ShortCut are always trigged more than one time, and this is tricky to me and hard to solve, so I resort to TForm.OnKeyDown event and cleared all TAction.ShortCut properties, this approach works well, except that the shortcuts are not shown on the corresponding menu items, but I want them to be displayed on those menu items.
So I come up this idea: Set values for TMenuItem.Shortcut so that the program can show the shortcut hint to the end user, and does not allow VCL to handle these shortcuts, instead, handle them in TForm.OnKeyDown. So my question is how to disable TAction.Shortcut or TMenuItem.Shortcut? Thank you in advance.
For a start, you have an Enabled property on both TAction and TMenuItem. Just set it to False.
Next, one of the possible causes of your event being triggered more than once is that you may be using Application.ProcessMessages; or at least a badly written component that you're using is doing so. One should be very wary of using that Delphi feature because it can cause 're-entrant' code (unintentional recursion).
The root cause of your problem is the events being triggered more than one time. You could try to workaround this problem offcourse but I would suggest to:
Place a breakpoint in your eventhandler.
Copy the Call Stack's content [CTRL+ALT+S] to whatever editor you like for every time you hit the breakpoint.
Start brainstorming as to why the calls lead to hitting the event multiple times.
Fix your code if it is your code to fix.
Hacker way (usually not recommended):
copy unit that contain TAction in separate folder, modify source of TAction that makes ShortCut method do nothing. Put this folder to search path as first item.
rebuild your app.
I use this technique to fix bugs in VCL, but after installing Delphi patches you should not forget to update 'hacked' version of modified units.