One of the things my add-in is supposed to do is present a report to
the user, stating (among other things) how many errors and warnings
were generated in the course of a build. To do this, I've registered
event handlers for BuildBegin, BuildDone, and TaskAdded (for the "Build
Errors" task pane).
Usually, these work exactly as intended. But there are two problems.
First, _NONE_ of the event handlers seem to want to fire if I've got
either a breakpoint or a MessageBox.Show() call in any of them.
Removing the breakpoint/MessageBox.Show() call fixes the problem.
Second, the TaskAdded handler doesn't seem to always fire when a task
is added to the task list. For example, I accidentally introduced some
linking errors into one solution. I can see the resulting task items
being added to the Build Errors task pane, but they don't come through
in the report. (The error count remains 0, when it should be 5.) The
fun part about this one is, it registers compiler errors just fine--I
deliberately introduced an error in a C++ file (changed "NULL" to
"NUL"), and the report said I had 1 error.
Any ideas?
--M
Matthew Korth - 25 Feb 2005 19:19 GMT
> Second, the TaskAdded handler doesn't seem to always fire when a task
> is added to the task list. For example, I accidentally introduced
[quoted text clipped - 4 lines]
> just fine--I deliberately introduced an error in a C++ file (changed
> "NULL" to "NUL"), and the report said I had 1 error.
I've solved this part.
It looks like TaskItem.Line was throwing an exception if there was no
line associated with the task, rather than returning the default value
(0), as I'd assumed. So, the TaskAdded handler _was_ firing, but if it
processed a linker error, the exception would be thrown. Because the
exception wasn't caught, it aborted the exceution of the event handler
before I could account for the error.
--M
Dmitry Shaporenkov - 28 Feb 2005 10:37 GMT
Hello Matthew,
make sure that your store references to VS event objects in variables that
live long enough for your purposes
(normally they should live in the course of your add-in lifecycle).
E.g. the following code for subscribing to event is in fact wrong:
applicationObject.Events.BuildEvents.OnBuildBegin += new ....
The problem is that this line of code does not create a reference to a BuildEvents
objects, so it will be collected as soon
as the next garbage collection happens. This will prevent your handler from
being notified about the event. Instead, store
a reference to the BuildEvents in a member of the add-in Connect class (or
somewhere else):
public class Connect
{
private BuildEvents myBuildEvents;
.....
myBuildEvents = applicationObject.Events.BuildEvents;
myBuildEvents += new ....
}
Regards,
Dmitry Shaporenkov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
> Usually, these work exactly as intended. But there are two problems.
>
> First, _NONE_ of the event handlers seem to want to fire if I've got
> either a breakpoint or a MessageBox.Show() call in any of them.
> Removing the breakpoint/MessageBox.Show() call fixes the problem.