Depending on the nature of the plugin, it can be a much easier setup, and far
more resilient. Different Excel versions get very flaky, the lifecycle of
plugins can be difficult with lots of external state. By putting it is a
different process it can be easier to debug, far more resilient, and
Thanks! That's what I thought/feared..
On Tuesday, January 22, 2019 at 4:47:33 PM UTC+1, robert engels wrote:
>
> But it also depends on what you me by add-in - if it is just processing
> Excel files, that’s one thing - if its a live data source I think the best
> way is a network bridge -
Nothing as such.. What I would like to write, though. Is a Excel add-in
having a ribbon and UDFs. And I am not sure how or if this is possible
using COM from Go.
On Tuesday, January 22, 2019 at 4:46:14 PM UTC+1, robert engels wrote:
>
> What is wrong with using COM from Go ?
>
> On Jan 22,
But it also depends on what you me by add-in - if it is just processing Excel
files, that’s one thing - if its a live data source I think the best way is a
network bridge - that’s what we’ve used - a thin COM layer that Excel uses
communicates with the process via TCP.
> On Jan 22, 2019, at
What is wrong with using COM from Go ?
> On Jan 22, 2019, at 9:35 AM, mrech...@gmail.com wrote:
>
> Hi,
>
> I was wondering if there is a library supporting writing an Excel add-in in
> Go. Googling did not brought anything besides the Window COM support library.
> Therefore, the only way I
Hi,
I was wondering if there is a library supporting writing an Excel add-in in
Go. Googling did not brought anything besides the Window COM support
library. Therefore, the only way I could think of so far is writing a
back-end service in Go and communicating with it using 0MQ/Nanomsg/... from
