> That sounds like a tricky one!

> When you create a Custom Task Pane via Excel-DNA, it is only involved
> in the initial hookup, to do the on-demand COM registration. Excel-DNA
> has no involvement or interference in the CTP as it runs - no wrappers
> or anything in between. Perhaps VSTO has some wrapper code that might
> make it integrate better - you might discover this by poking around
> the VSTO library with ILSpy a bit, and then implement the same code in
> your add-in.

> There used to be some issues with WPF being hosted in Office apps, but
> I have no experience myself or a nice reference at hand. Before you do
> the complicated-sounding VBA/COM updating, just check whether you can
> update the content of your CTP fast enough from a timer or something.
> I don't really understand your update loop - it might be that you are
> just doing too much work on the main thread. DoEvents is pretty much a
> red flag to me. The interaction between Excel's ScreenUpdating and how
> the CTP is hosted is a mystery, but maybe someone on the Excel for
> Developers forum might ahve some ideas.

> So my suggestion would be:

> - If you really see a difference between Excel-DNA and VSTO, then it
> is due to code that is in the VSTO libraries setting some confguration
> or doing something clever to the UserControl. Excel-DNA is not
> involved in the WPF/CTP drawing path at all.

> - Make an example of a WPF form outside Excel, which matches the
> content that you want to draw, and check that you can update it at the
> rate you require. WPF has a million tuning options, like bitmap
> caching, that can make a huge difference to its performance.

> - Next, make a WPF/CTP that displays the content and is updated from a
> timer or something - no VBA/COM or Excel involved in the updates, just
> hosted in Excel. This will test the hosting in the WinForms host and
> Excel, and give you confidence that the message loops and display
> environment doesn't mess anything up.

> - Next, update the data from .NET code in your add-in, allowing you to
> figure out any threading issues, since your updates will probably be
> generated on a secondary thread, and you need to update the WPF
> controls on the main thread.

> - Finally, consider you to hook up the real data.

> Good luck!

> Govert

> On Jun 29, 10:25 am, aberglas <aberg...@gmail.com> wrote:

> > Hello Govert,

> > I have a task pane with a moderately complex WPF user control in it,
> > which involves Flow Documents, and seems to take about 15ms to
> > render.  It seems that the flicker happens during the render.

> > The flicker is not just to white, but to black, which makes it look
> > quite bad.  Or sometimes bits of the Excel graphics end up in it.
> > Have tried setting background colors of everything -- wpf control,
> > elementHost, containing form.

> > I'm not sure whether this is an ExelDna issue or a  Wpf/Excel one.  It
> > is worse with ExcelDna than VSTO, but it is also very variable for non
> > obvious reasons -- it gets better over time!

> > I am actually driving the .Net from VBA via com.  I update the display
> > by
> > m = new Model();
> > m.properties=...;
> > DataContext = m;
> > Ie no events to confuse things.  (The model is completely different
> > each time, so this should also be faster.)

> > It seams to be more of a WPF issue, not winForms. In both .net 3.5 and
> > 4.0.  Excel 2010.

> > It is difficult to reproduce in a small example.  But by updating a
> > WPF model 100 times from VBA, DoEvents between, and ScreenUpdating =
> > *False* it flickers a bit.  ScreenUpdating = True smooths it out(!). I
> > think because in a small example each of the 100 WPF redraw is very
> > quick, and the XL cleans it up before you can notice.

> > Doing the 100 updates within .Net does not flicker, even with a

> > wpf.Dispatcher.Invoke(System.Windows.Threading.DispatcherPriority.Render,
> > EmptyDelegate);
> > between them which seems to force the update to the screen.

> > Any ideas most welcome.

> > Anthony