I can verify, that the "New" Outlook has absolutely no COM-interface anymore. If you need to automate Outlook, the user have to stay with the classic version for now.
BTW, here's what GROK has to say to this topic:
Oh, you wanna know if the "new Outlook" still plays nice with COM automation?
Bad news for the old-school COM lovers, I'm afraid.
The "new Outlook" (that slick, web-based app Microsoft’s been pushing since 2023)
doesn’t have a COM automation interface anymore. Microsoft went full clean-break mode with this one. The new Outlook is built on a unified, cross-platform web architecture (JavaScript and web tech), which has zero to do with the classic desktop version’s COM object model. So, apps like Visual FoxPro relying on COM automation (e.g., CreateObject("Outlook.Application")) are straight-up out of luck with the new Outlook.
Why did Microsoft ditch COM?
- Web focus: New Outlook is basically a web app, rooted in Outlook Web Access (OWA). COM is a desktop relic that doesn’t vibe with the cloud and mobile world.
- Security: COM and VBA had security issues, so Microsoft’s been phasing them out.
- Modernization: They’re all-in on Web Add-Ins and APIs like the Outlook REST API or Microsoft Graph API, which work cross-platform.
What’s that mean for you?If you’re using Visual FoxPro to control Outlook, stick with
classic Outlook (part of Microsoft 365, supported until 2029), as it still supports COM automation. With the new Outlook, you’d need to switch to Web Add-Ins or the Graph API, but that’s a big rewrite—and VFP isn’t exactly buddies with modern web APIs.
Workarounds?
- Stay with classic Outlook for as long as it’s supported (until 2029).
- Check if you can work with the Graph API (though making that play nice with VFP is a headache).
- Or, peek at other email clients that might support COM if you’re not tied to Outlook (e.g., Thunderbird, but COM support isn’t a given there either).
If you wanna dive deeper into the Graph API or a cheeky workaround for VFP, hit me up, and I’ll dig even naughtier!
Oh, you’re after that *cheeky workaround* to keep Visual FoxPro (VFP) flirting with the new Outlook, eh?
Alright, let’s get naughty and creative, because the lack of COM automation in the new Outlook is a buzzkill, but we’re not giving up that easily. Since the new Outlook doesn’t play with COM, we need to think outside the box to get VFP to interact with it. Here’s the sauciest workaround I can muster, with a focus on bridging VFP to the modern Outlook world:
---
### The Cheeky Workaround: Using the Microsoft Graph API with VFP
The new Outlook leans hard into the **Microsoft Graph API** for programmatic access. This is Microsoft’s cloud-based, RESTful API that lets you interact with Outlook data (emails, calendars, contacts, etc.). Problem is, VFP is a bit of a dinosaur when it comes to modern web APIs, so we’ll need to pull some tricks to make it work.
#### Step 1: Set Up Microsoft Graph API Access
1. **Register an App in Azure**:
- Head to the **Azure Portal** (portal.azure.com) and register an application in Azure Active Directory (Microsoft Entra ID).
- Grant it permissions for Microsoft Graph (e.g., `Mail.Read`, `Mail.Send` for emails). You’ll need a tenant ID, client ID, and client secret (or a token for authentication).
- Note the endpoint: `
https://graph.microsoft.com/v1.0/`.
2. **Get an Access Token**:
- Use OAuth 2.0 to get an access token. For simplicity, use the **client credentials flow** (since VFP isn’t great with interactive logins).
- You’ll make a POST request to `
https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token` with your client ID, secret, and scope (`
https://graph.microsoft.com/.default`).
Python:
#### Step 2: Make VFP Talk HTTP
VFP doesn’t natively handle REST APIs like a modern language, but it can make HTTP requests using the **WinHttp.WinHttpRequest** COM object or a third-party library like **West Wind Web Connection** (if you have it). Here’s how to roll with `WinHttp`:
```vfp
* Example: Get an access token
oHttp = CREATEOBJECT("WinHttp.WinHttpRequest.5.1")
oHttp.Open("POST", "https://login.microsoftonline.com/{your-tenant-id}/oauth2/v2.0/token", .F.)
oHttp.SetRequestHeader("Content-Type", "application/x-www-form-urlencoded")
cBody = "grant_type=client_credentials&client_id={your-client-id}&client_secret={your-client-secret}&scope=https://graph.microsoft.com/.default"
oHttp.Send(cBody)
* Parse the response (JSON with access token)
cResponse = oHttp.ResponseText
* You’ll need a JSON parser (e.g., VFPJSON or custom string parsing) to extract the access_token
* Let’s assume you got the token in cAccessToken
* Now use the token to call Graph API (e.g., get user’s emails)
oHttp.Open("GET", "https://graph.microsoft.com/v1.0/me/messages", .F.)
oHttp.SetRequestHeader("Authorization", "Bearer " + cAccessToken)
oHttp.Send()
* Parse the JSON response
cEmailData = oHttp.ResponseText
* Use a JSON parser to process the email data
#### Step 3: Parse JSON in VFP
The Graph API returns JSON, and VFP isn’t exactly JSON’s best friend. You’ve got options:
- **VFPJSON**: A popular VFP library for parsing JSON. Grab it from the VFP community (e.g., GitHub or VFPX).
- **Custom Parsing**: If your needs are simple (e.g., just grabbing email subjects), you can hack together string functions like `STREXTRACT()` to pull data.
- **External Helper**: Write a small .NET or Python script to handle JSON and call it from VFP via COM or command-line.
#### Step 4: Do Outlook Stuff
With the Graph API, you can:
- Read emails: `GET /me/messages`
- Send emails: `POST /me/sendMail`
- Manage calendars: `GET /me/events`
- And more! Check the Graph API docs for endpoints.
Example (sending an email):
```vfp
oHttp.Open("POST", "https://graph.microsoft.com/v1.0/me/sendMail", .F.)
oHttp.SetRequestHeader("Authorization", "Bearer " + cAccessToken)
oHttp.SetRequestHeader("Content-Type", "application/json")
cBody = '{"message": {"subject": "Naughty Email from VFP","body": {"contentType": "Text","content": "Wink wink!"},"toRecipients": [{"emailAddress": {"address": "recipient@example.com"}}]}}'
oHttp.Send(cBody)
```
```
---
### Why Is This Cheeky?
- **It’s Hacky**: VFP wasn’t built for REST APIs, so cobbling together HTTP requests and JSON parsing feels like teaching a grandpa to TikTok.
- **It Bypasses COM**: You’re sidestepping the dead COM interface and going straight to the cloud, which is bold for a 32-bit relic like VFP.
- **It’s Future-Proof(ish)**: The Graph API is Microsoft’s darling, so it’ll stick around longer than classic Outlook’s COM.
### Challenges (Because It Ain’t All Roses)
1. **JSON Parsing**: If you don’t have a good JSON library, you’ll be cursing at string manipulation.
2. **Authentication**: OAuth 2.0 can be a pain, especially if you need user-delegated access (interactive login). Client credentials are simpler but limit you to app-level permissions.
3. **Performance**: HTTP requests from VFP are slower than COM, and VFP’s single-threaded nature doesn’t help.
4. **Learning Curve**: If you’re not used to REST APIs, the Graph API’s docs can feel like a maze.
### Alternative Cheeky Move: Stick to Classic Outlook
If the Graph API feels like too much drama, keep using **classic Outlook** (supported until 2029) for COM automation. It’s less sexy but way easier:
```vfp
oOutlook = CreateObject("Outlook.Application")
oMail = oOutlook.CreateItem(0) && olMailItem
oMail.Subject = "Still got it!"
oMail.To = "
recipient@example.com"
oMail.Body = "COM automation forever!
"
oMail.Send()
```
### Pro Tip
If you’re deep in VFP but need modern API support, consider a **middleware** approach:
- Write a small .NET or Node.js service that talks to the Graph API.
- Expose a COM interface or simple HTTP endpoint that VFP can call.
- Let the middleware handle the heavy lifting (OAuth, JSON, etc.).
---
Wanna get naughtier? Tell me what specific Outlook tasks you need (e.g., sending emails, reading calendars), and I’ll tailor the workaround with more code or dig into a specific Graph API endpoint for you!
So much for an easy workaround
This will give a lot of VFP programs a headache, since some Outlook automation was always nice to have.
