4 ms·

They're describing a different kind of automation. COM APIs were commonly used for hosting an application and automating functionality that normally would requ

They're describing a different kind of automation. COM APIs were commonly used for hosting an application and automating functionality that normally would require UI interaction. You can do this with the MS Office applications, among others.

sjmulder 8y ago
Embedding Internet Explorer through COM also seems the only way to embed a browser in Win32 without bundling an entire browser with your app. I implemented that in plain C for giggles, it was enlightening but also very cumbersome.
- TimJYoung 8y ago
  Yes, it's somewhat tricky to get entirely right, which is why Delphi/Lazarus/.NET have wrapper components that take all of the pain out of doing it. It's just a matter of dropping a control on a form and setting a few properties. We use an embedded IE instance for running web applications in our web development IDE, Elevate Web Builder, but we're looking to move to embedded Chrome if MS doesn't provide an option for embedding Edge in non-UWP desktop applications soon.
  - sjmulder 8y ago
    Yeah, having the OLE site and window provided by the framework helps a ton. Once you have those putting in the browser is a breeze. (I E_NOTIMPL-ed all the fancy menu merging and window border stuff but you get that with Delphi and .NET) I still haven't implemented the IDispatch-based event handling yet. It's the only remaining thing but it's daunting. There's hardly any low level documentation. Elevate Web Builder looks interesting. We need something like classic Visual Basic but for the web because building simple web applications is needlessly complicated. I'll give it a try! edit: not filling in that form though, sorry!
    - TimJYoung 8y ago
      Re: Yeah, I just had to deal with the IDispatch event handling for status events with the XMLHTTPRequest API in Windows, and it required a crazy amount of research before I got it all right. Re: trial registration - we're going back to simple trial downloads soon, especially due to the GDPR. The original reason for the registration is that we had some issues with abuse, and the registration helped that quite a bit. In the meantime, you can just skip most of it with "N/A", if you're still interested. You can also just run some demo applications here: https://www.elevatesoft.com/products?category=ewb&type=web https://www.elevatesoft.com/products?category=ewb&type=web (at the bottom of the page)
ethbro 8y ago
That was my understanding too. What's the use case here? I'm hard pressed to think of something big enough where UI automation is too slow, but it isn't a better idea to re-architect the process to not use MS Office or consumer apps. Maybe finance? I'm sure they've got enormous Excel files... I work in this space, and individual COM implementations are pretty bad in terms of development effort : utility. Because at the end you have one, single purpose function.
- TimJYoung 8y ago
  I think it's often easy to underestimate just how much VBA-type code has been written around the MS Office suite of applications since the late 90s. It's a massive amount of department-level (or higher), home-grown code that leverages the MS Office functionality in lieu of paying professional software developers to develop something more streamlined, but much more expensive.
  - ethbro 8y ago
    Dealing with that is a big part of my day to day. ;) My point being that for everything but performance critical use cases, generic UI automation works well. So was trying to think of situations where 1) performance requirements were higher than UI automation could deliver & 2) performance requirements are low enough that it doesn't make more sense to rewrite the code in a more appropriate system.

sjmulder 8y ago

Embedding Internet Explorer through COM also seems the only way to embed a browser in Win32 without bundling an entire browser with your app. I implemented that in plain C for giggles, it was enlightening but also very cumbersome.

TimJYoung 8y ago
Yes, it's somewhat tricky to get entirely right, which is why Delphi/Lazarus/.NET have wrapper components that take all of the pain out of doing it. It's just a matter of dropping a control on a form and setting a few properties. We use an embedded IE instance for running web applications in our web development IDE, Elevate Web Builder, but we're looking to move to embedded Chrome if MS doesn't provide an option for embedding Edge in non-UWP desktop applications soon.
- sjmulder 8y ago
  Yeah, having the OLE site and window provided by the framework helps a ton. Once you have those putting in the browser is a breeze. (I E_NOTIMPL-ed all the fancy menu merging and window border stuff but you get that with Delphi and .NET) I still haven't implemented the IDispatch-based event handling yet. It's the only remaining thing but it's daunting. There's hardly any low level documentation. Elevate Web Builder looks interesting. We need something like classic Visual Basic but for the web because building simple web applications is needlessly complicated. I'll give it a try! edit: not filling in that form though, sorry!
  - TimJYoung 8y ago
    Re: Yeah, I just had to deal with the IDispatch event handling for status events with the XMLHTTPRequest API in Windows, and it required a crazy amount of research before I got it all right. Re: trial registration - we're going back to simple trial downloads soon, especially due to the GDPR. The original reason for the registration is that we had some issues with abuse, and the registration helped that quite a bit. In the meantime, you can just skip most of it with "N/A", if you're still interested. You can also just run some demo applications here: https://www.elevatesoft.com/products?category=ewb&type=web https://www.elevatesoft.com/products?category=ewb&type=web (at the bottom of the page)

ethbro 8y ago

That was my understanding too. What's the use case here? I'm hard pressed to think of something big enough where UI automation is too slow, but it isn't a better idea to re-architect the process to not use MS Office or consumer apps. Maybe finance? I'm sure they've got enormous Excel files... I work in this space, and individual COM implementations are pretty bad in terms of development effort : utility. Because at the end you have one, single purpose function.

TimJYoung 8y ago
I think it's often easy to underestimate just how much VBA-type code has been written around the MS Office suite of applications since the late 90s. It's a massive amount of department-level (or higher), home-grown code that leverages the MS Office functionality in lieu of paying professional software developers to develop something more streamlined, but much more expensive.
- ethbro 8y ago
  Dealing with that is a big part of my day to day. ;) My point being that for everything but performance critical use cases, generic UI automation works well. So was trying to think of situations where 1) performance requirements were higher than UI automation could deliver & 2) performance requirements are low enough that it doesn't make more sense to rewrite the code in a more appropriate system.