in reply to Re: Re: Win32::OLE Examples?
in thread Win32::OLE Examples?

The point is, OLE is a Microsoft "technology", so it's really the other way around. OLE only works on Micrsoft and Microsoft compliant software products. Technically, it works with certain applications and codebases that implement an interface named IDispatch.

Unfortunately, from what I can see, Wordpad really has no interfaces derived from IDispatch, which means no OLE (someone please correct me if I'm wrong).

I ask again, though, what are you thinking of doing? Perhaps there is another way around it that a few here could suggest.

C-.

Replies are listed 'Best First'.
Re:^4 Win32::OLE Examples?
by Flame (Deacon) on Mar 21, 2002 at 17:45 UTC
    I'm using Win32::GUI and I have a rich-text box. I was attempting to use it as a WYSIWYG html editor (of sorts). I actually was able to make it work, up to a point, but I've been looking for alternatives. One of the people on the Win32::GUI mailing list suggested I take a look at Win32::OLE.

    At the moment, I have no specific goal, but since my interest was piqued, I want to see if I can actually get my hands on a working example.

    Could you simply describe what a program using OLE might look like? What purposes could one fulfill?

    By automation, I assume that means that it actually launches the other program and manipulates it? Or does it just run portions of the other program. For example, could OLE be used to create a browser with IE and Win32::GUI? Or would it just be limited to opening IE and controling it?

    Thanks, I hope this explains what I'm trying to figure out a little better.


    "Weird things happen, get used to it."

    Flame ~ Lead Programmer: GMS

[reply]
      The purpose of OLE is to allow an outside code base to interact with and control an OLE enabled (IDispatch derived) application.

      The OLE interface has a client and a server. Your assumption is correct in that Perl code calling Win32::OLE and accessing an application does indeed create an instance of the application. The application can be on the local machine or remote, and it is the Server, while your code is the client, so it would be limited to opening IE and controlling it.

      I have created OLE interfacing applications to automate many of the business processes I encounter. From autoformatting wordfiles, reading and aggregating data from from them based on a template, creating dynamic reports in excel from data mined from the web based on a template provided by the "customer" (all of my customers are internal). I've written apps to go through a series of public mail boxes and save off all the attachments, create slides in a PowerPoint presentation based on data I mined from the web (part of the excel application)...The list goes on and on.

      I've also written COM components with this interface in mind so that others could transform XML documents through BizTalk and access MSMQ queues in an application specific manner using whatever programming language they preferred.

      Really, anything that is done on a regular basis in any of these applications can be automated with the OLE interface. When you are writing in VBA for any of these applications, you are writing code directly against the OLE interface.

      C-.

[reply]

In Section Seekers of Perl Wisdom