C
Chris Roth [ Visio MVP ]
Hi All,
I'm developing a VB.NET COM add-in for Visio, but am frustrated by the fact
that I have to restart Visio every time I want to test changes to the
add-on. Is there a technique for separating the components such that the
main COM add-in is small, lean, and doesn't change very often, but can
access code in another library that is being updated often?
I've tried developing a .NET .exe which can re-synch with Visio when I run
after re-compile. This works, but very poorly. For instance:
- GetObject doesn't work very well with .NET. It's not reliable.
(I read something about a Running Table or whatnot...)
- When I do Get Visio, MarkerEvents seem to drop out sporadically
- It doesn't seem possilbe to create a proper dialog - it is a separate
window from Visio, and shows behind Visio.
In other words, .EXEs in Visio and .NET suck, or else I am missing some key
tricks.
Thanks,
Chris
I'm developing a VB.NET COM add-in for Visio, but am frustrated by the fact
that I have to restart Visio every time I want to test changes to the
add-on. Is there a technique for separating the components such that the
main COM add-in is small, lean, and doesn't change very often, but can
access code in another library that is being updated often?
I've tried developing a .NET .exe which can re-synch with Visio when I run
after re-compile. This works, but very poorly. For instance:
- GetObject doesn't work very well with .NET. It's not reliable.
(I read something about a Running Table or whatnot...)
- When I do Get Visio, MarkerEvents seem to drop out sporadically
- It doesn't seem possilbe to create a proper dialog - it is a separate
window from Visio, and shows behind Visio.
In other words, .EXEs in Visio and .NET suck, or else I am missing some key
tricks.
Thanks,
Chris