I am involved in a c++ refactoring project and sometimes there are differences resulting, when there should be none. Currently, what I do is basically setting a breakpoint at some place, and then go through the program by F10/F11. The first problem is the size of the projects, traversing it takes a lot of time. Second, sometimes I have differences only in the end of a very big test sentences (say, 600 words), thus just getting to the different word is painfully slow.
1. Is it possible to write some kind of macro for Visual Studio, which will start from the breakpoint, then go step-by-step through the program until end while printing some fields?
2. Are there any neat tricks or tools to simplify the task?
Thanks!
You can create Macros by using Tools>Macros>Macro IDE
If prefer the following method because it's faster for me.
You can record macros using Tools>Macros>Record temporary macro
Everything you type will then be recorded into a macro.
After you recorded what you want to be automated, you can edit the generated code by using View>Other windows>Macro Explorer. Your macro will be recorded in MyMacros>RecordingModule>TemporaryMacro in Macro Explorer window. If you right click that and select edit.
One way to test if the program is terminated:
While Not DTE.Debugger.CurrentProgram Is Nothing
Related
I'm generating thumbnails for office files using c++. I open and save the files using automation similar to this: https://support.microsoft.com/en-us/kb/179494. Since there are many files, this takes a lot of time and the program should run through the night.
Everything works fine, except when a file contains an auto start macro, which doesn't even exist.
Sub AutoOpen()
Application.Run ("stupidMacroWhichDoesntExist")
End Sub
In this case, the Loop stops, and an error message appears that the macro couldn't be executed.
Off Course, I have set the macro settings in the trust center to -> disable all macros without notification
The error message still appears
In Excel, I can prevent this with:
objExcelApp.SetEnableEvents(false);
Unfortunately, the word application in c++ doesn't have a SetEnableEvents method. I have googled a lot and found a lot of VB Code to prevent this. Mostly it was something like:
objWord.WordBasic.DisableAutoMacros 1
But I haven't found anything in c++
I'm very thankful for your help.
I believe you're looking for:
WordApplication.AutomationSecurity = msoAutomationSecurityForceDisable
The Trust Center setting doesn't apply to documents being opened using automation. This property and its MsoAutomationSecurity enumeration correspond to that setting in the object model.
FWIW the WordBasic approach should also be possible using C++. I don't know C++ syntax, but with C# I'd need to use PInvoke (GetType().InvokeMember) to communicate directly with the IDispatch (I think that's the right term).
I have solved it. I'm backing up the actual macro (vbaData.xml and vbaProject.bin in the word folder), put a dummy macro into the word file, open it via automation and save it to generate the thumbnail. After that, I put back the backed up macro into the word file.
Since the dummy macro does nothing I am safe that nothing will be executed, whatever is programmed in the original macro.
So, I have a program in C++ and I use visual studio 2010. My program is mostly procedural not object oriented programming though. The first part of my program does something, then the second half does something else that uses the information of the first half. The first half takes a while (~ 20 minutes) to run (I knew this through running it in debug mode and put a break point right after the end of that first half).
The thing is that I am experimenting different ideas for that second half. Now, whenever I write the code for any new idea, I have to run the whole code from scratch, and thus have to wait the 20 minutes before the new second half runs. This is very inconvenient/inefficient; since I will be doing this for a while. I also can not really write all my ideas at once and run different programs (with the same first half and different second halves corresponding to each idea) simultaneously, just because I get each new idea after I run the older one and understand somethings about the behavior of my algorithm.
So, is there any way I can start running the code right after the first part whenever I change something(s) in the second part, instead of having to compile it and run it from scratch each time I change something in the second part? And how is that, if possible?
Since you are using Visual Studio, you should look into Edit and Continue:
Edit and Continue is a time-saving feature that enables you to make
changes to your source code while your program is in break mode. When
you resume execution of the program by choosing an execution command
like Continue or Step, Edit and Continue automatically applies the
code changes with some limitations. This allows you to make changes to
your code during a debugging session, instead of having to stop,
recompile your entire program, and restart the debugging session.
But please pay attention to the limitations - Unsupported Scenarios, you might have to structure your code changes to fit within what's supported.
I am trying to use gdb with MySQL source code which is written in C/C++. In mysql-test/t, I create a custom test case file, say, example.test and then debug it by using the following line of code
/mysql-test-run --gdb example
Now I want to see the flow of execution as it changes from one function in a file to another in some different file. I am not sure of how the execution changes, so I can't pre define the break points. Any solution to how I can get to see the flow with multiple files of source code?
You can use the next directive to take line-by-line steps through the source. When appropriate, you can use the step directive to take steps "into" the function(s) being called on the current line.
A reasonable method would be to do next until you think you only just pass the externally visible behavior you're looking for. Then start over, stopping at the line right before you saw the behavior last time. Then step this time. Repeat as necessary until you find the code you're looking for. If you believe that it's encountering some sort of deadlock, it's significantly easier -- just interrupt (Ctrl-C) the program when you think it's stuck and it should stop right in the interesting spot.
In general, walking through the source you'll build up some places you think are interesting. You can note the source file and line number and/or function names as appropriate and set those breakpoints directly in the future to avoid tedious next/next/next business.
I have a solution with 21 C++ projects and 1 VB.NET project.
The IDE responds very slowly when I simply move the carret in a file or try to open the menu. The process seems to take 50% of CPU for each movement.
It only happens with this solution and only on my machine.
The solution has total of 2380 source and header files, of which 1280 are header files.
I tried to remove all connection to the source control (Perforce) but it didn't help.
Also, I have Visual Assist installed but even after removing it (uninstall), the same behavior continued.
Any idea?
Deactivate intellisense.
Link
Intellisense parses the whole project and slows down the IDE drastically. If you use Visual Assist then you won't really need it. Visual Assist is less resource hungry and scans in the background, intellisense steals too many resources during its parsing.
Could this apply in your case?
http://coolthingoftheday.blogspot.com/2008/03/visual-basic-2008-hotfix-to-fix-slow.html
Note that disabling Intellisense may also break stuff like the Class Wizard (at least I'm pretty sure it does in VS2005). As already suggested it's a good idea to get rid of all the temporary files like .ncb regularly, because they can get huge and will slow down the IDE.
Also, if you're using Visual Assist, try rebuilding the database, disabling it or installing a different version.
I have a few solutions with over 100 projects, so I know exactly how you feel. Solutions containing some managed projects are especially bad. Disabling Intellisense helps a lot. I've never seen such problems from Visual Assist (or other similar refactoring tools), and that fills in a lot of the missing functionality from losing Intellisense.
I've also encountered some projects that had code that would cause the Intellisense thread to endlessly loop and never finish parsing the code. Most of those times we were never able to pin down the exact bit of code that caused the problem. Certain heavy use of templates and nested macros were often high on the suspicion list.
The only good way to be sure that Intellisense is disabled is to create a directory with the same name as the ncb file. Go to your solution directory, delete the ncb, and create a directory named your_solution_name.ncb. Because it can't recreate the ncb file, you'll get an error box to click through every time you open the solution, but that's a small price to pay.
Simply deleting the ncb will mean that VS will just create it again. The methods that I've seen from inside the VS options will turn off some of the features but will not prevent it from trying to parse all your code.
I have frequently encounter the following debugging scenario:
Tester provide some reproduce steps for a bug. And to find out where the problem is, I try to play with these reproduce steps to get the minimum necessary reproduce steps. Sometimes, luckily I found that when do a minor change to the steps, the problem is gone.
Then the job turns to find the difference in code workflow between these two reproduce steps. This job is tedious and painful especially when you are working on a large code base and it go through a lot code and involve lots of state changes which you are not familiar with.
So I was wondering is there any tools available to compare "code workflow". As I've learned the "wt" command in WinDbg, I thought it might be possible to do it. For example, I can run the "wt" command on some out most functions with 2 different reproduce steps and then compare the difference between outputs. Then it should be easy to found where the code flow starts to diverge.
But the problem with WinDBG is "wt" is quite slow (maybe I should use a log file instead of output to screen) and not very user-friendly (compared with visual studio debugger) ... So I want to ask you guys is there any existing tools available . or is it possible and difficult to develop a "plug-in" for visual studio debugger to support this functionality ?
Thanks
I'd run it under a profiler in "coverage" mode, then use diff on the results to see which parts of the code were executed in one run by not the other.
Sorry, I don't know of a tool which can do what you want, but even if it existed it doesn't sound like the quickest approach to finding out where the lower layer code is failing.
I would recommend to instrument your layer's code with high-level logs so you can know which module fails, stalls, etc. In debug, your logger can write to file, to output debug window, etc.
In general, failing fast and using exceptions are good ways to find out easily where things go bad.
Doing something after the fact is not going to cut it, since your problem is reproducing it.
The issue with bugs is seldom some interal wackiness but usually what the user's actually doing. If you log all the commands that the user enters then they can simply send you the log. You can substitute button clicks, mouse selects, etc. This will have some cost but certainly much less than something that keeps track of every method visited.
I am assuming that if you have a large application that you have good logging or tracing.
I work on a large server product with over 40 processes and over one million lines of code. Most of the time the error in the trace file is enough to identify the location of problem. However sometimes the error I see in the trace file is caused by some earlier code and the reason for this can be hard to spot. Then I use a comparative debugging technique:
Reproduce the first scenario, copy the trace to a new file (if the application is multi threaded ensure you only have the trace for the thread that does the work).
Reproduce the second scenario, copy the trace to a new file.
Remove the timestamps from the log files (I use awk or sed for this).
Compare the log files with winmerge or similar, to see where and how they diverge.
This technique can be a little time consuming, but is much quicker than stepping through thousand of lines in the debugger.
Another useful technique is producing uml sequence diagrams from trace files. For this you need the function entry and exit positions logged consistently. Then write a small script to parse your trace files and use sequence.jar to produce uml diagrams as png files. This is a great way to understand the logic of code you haven't touched in a while. I wrapped a small awk script in a batch file, I just provide trace file and line number to start then it untangles the threads and generates the input text to sequence.jar then runs its to create the uml diagram.