Visio 2007 Development Best Practices

[WPfeffer]

I have found a few white papers, talks, etc. on best practices for Visio
Development (the majority of which are for Visio 2003, when I'm looking for
Visio 2007) and they are all pretty much saying the same thing, use the COM
EventSink method. What I would like to see is, a comparison between the COM
EventSink way of doing things and the VSTO way of doing things. Why is the
EventSink method a better practice than the VSTO method? If I am trapping
events from Visio inside of an AddIn, why should I use COM instead of what
appears to be the more native / intuitive way of doing things in VSTO? And,
why is it next to impossible to find any documentation on doing things in C#
instead of VB? The only C# code that I've found in any quatity is in the
examples that come with the SDK, all the blogs that I've found and all of the
SDK documentation is in VB. I have yet to find any documentation on accessing
the different properties of the Visio objects in C#. (I figured it out though
rather quickly, it would just have been nice if somewhere in the
documentation it had been stated that in C# you use <object>.get_<property>()
instead of the VB way of <object>.<property>.)

I apologize if I sound like I'm ranting, I'm just getting a little
frustrated with what appears to be a lack of documentation for a language
that Microsoft was touting a couple of years back as the next big thing and
for a lack of comparitive data to back up the notion that COM AddIns are a
better way to go than VSTO add ins.

Thanks in advance for any help that can be given.

Wayne E. Pfeffer

 

[David Parker]

If you have read Chris Castillo's blog (
http://blogs.msdn.com/chcast/archive/2007/03/28/creating-visio-add-ins-with-vsto-2005-se.aspx )
then you'll know that he (and the rest of the Visio team ) advocate not
using WithEvents but to use AddAdvise, even with VSTO. This is because
AddAdvise only rasises the events that you want whilst WithEvents is a
blunderbus approach. You will get much better performance if you avoid
being to "chatty".

 

[WPfeffer]

I have read his blog. However, once again the problem that I run into is that
all of the example code and information is in VB and geared towards VB
developers. Am I to assume then that since C# doesn't have a 'WithEvents'
declaration that we can't turn them off? Or is there something that I'm not
understanding about the way C# handles events (this is quite possible). If I
don't have the WithEvents modifier in C# then the only options are either the
whole "fire hose" method of event handling that the 'EventSink' way of doing
things eliminates, or that all events are turned off by default and that when
I write my delegates only those events that I have delegates written for will
be fired. If the former is true, then C# support in Visio needs to be
re-evaluated, if the latter is true then this needs to be documented
somewhere. (Not documented _better_, because that assumes it's documented to
begin with.)

I would also like to know why VB allows for dotted notation to access the
different levels of objects in Visio, but C# does not. Instead I have to use
the 'get_<property_name>()' methods.

Wayne

 

[Nikolay Belyh]

Hello Wayne.

C# handles Visio events exactly the same way VB does. The only
difference is the syntax. When you subscribe to object's events using
'WithEvents' keyword ('+=' in C#) what you are actually using behind
the screens is a good old COM "connection points" mechanism (you can
try googling on these words..)

This mechanism requires the subscriber to handle all events object
fires using it's event interface. It is the compiler/runtime who
filters out the events for you. That is, all events you have not write
handlers for are handled by the "stub" "handler" runtime has created.
But they are all fired and handled. And this is the waste of time the
books are talking about.

Using VisEventProc (aka "EventSink") you will be able to subscribe to
single event. Only this single event you subscribed to will be fired
and handled. But this comes at the cost of some extra code complexity,
since this mechanis is actually based on Visio's native VisEventProc
event handling mechanism used by Visio since it was built in 1992 (?).
Therefore, you should not be surprised when you see 8 weird parameters
passed in.

As for COM, since Visio is actually unmanaged (!) application, you
have no choice but COM interop for NET whichever event handling
approach you choose. And all these get_<> are nothing more but
consequences of the COM interop. In "reality", Visio by itself doesn't
have all those get_<> methods. They were automatically created for you
by compiler from Visio COM type library (Microsoft.Visio.Interop you
are using was created this way). We are living in the matrix, haven't
you realized this yet? And digging deeper might lead you to the "end
of the world" (c) Thirteens Floor

As for VB, I think it is actually a GOOD idea to write examples in VB,
since they:
- Look natural. you dont need all those ridiculous braces and get_<>
stuff.
- You don't need anything but Visio itself (VBA) to run them.

Kind regards, Nikolay

 

[WPfeffer]

Thank you for your response. I was quite helpful. Apparently I'm not as smart
as I thought I was. It still doesn't make a lot of sense why Visio still
requires COM, and is still 'unmanaged' but if that's way it is...........

Thank you very much for your help.

Wayne