http://qs321.pair.com?node_id=979458


in reply to Re^5: Perl r/w Excel with OLE
in thread Perl r/w Excel with OLE

No, you misunderstood my point. I didn't mean "use macros that are invoked by Perl using Win32::OLE". I meant "Use the macro recorder and VBA instead of using Perl". VBA and the macro recorder (which ultimately is a shiny wrapper on the underlying VBA) are the tools explicitly designed by Microsoft for automating Excel. It's just that with the power of Perl, you can do many other things that are difficult or impossible when using VBA.

After Davies explained, I now see how reusing a single instance of Excel could lead to data loss. Perhaps the authors of Win32::OLE should be contacted so that the module examples have caveats about what it really means for the system when you reuse a running Excel instance.

Replies are listed 'Best First'.
Re^7: Perl r/w Excel with OLE
by dasgar (Priest) on Jul 03, 2012 at 03:00 UTC

    Hmmm....ok. Perhaps I misunderstood you when you said:

    If I were to do simple macro type automation, then I'd record it within Excel or use the existing VBA and save myself the pain of OLE.

    That sounded like you plan to use macros for your "automation". Whether you are manually opening Excel and running the macros or using Perl to call the macros, I personally believe that the issues that I pointed out are still relevant.

    Also, by using VBA instead of Perl does not mean you escape from OLE. Any VBA code (external to Excel or inside Excel as macros) that does any Excel automation will be using OLE. The Win32::OLE module lets you access the OLE API from Perl. In other words, if you're automating Excel with VBA, macros, or Perl, you're going to use OLE in some way as far as I know.

    If I'm still misunderstanding your point, my apologies.