MailTo in compiled script starts Outlook configuration (not Outlook)

[TheyCallMeBacon]

I am using Office 365 (Microsoft 365 Apps for Enterprise) v2208 on Windows 10 build 22H2 on most of the test machines where this is happening. (Some are running slightly older O365 builds [2202] or Windows 10 [20H2]).

SciTE 32-bit V4.4.6
AutoIT v3.3.16.1
AutoITWrapper v21.316.1639.1

I have a small script that behaves very differently when compiled.  

ShellExecute("mailto:" & $sTo & "?cc=" & $sCC & "&subject=" & $sSubject & "&body=" & $sBody)

Runs perfectly when the script is running from SciTE.  It opens Outlook 365 whether the app is running or not, and pops up a perfectly formatted new message window with all the info in the right places.  Sending that message works perfectly.  

Once compiled, that command starts up a "Welcome to Office 2016" window that asks to configure the Office 2016 app (365 was built on 2016, so it could be buried in there - dunno).  On one machine, I am prompted to "select an app to complete this action" even though 365 is working on that system as well.  On all of the test machines I have created a MailTo hyperlink for testing that works as expected. 

The value of HKEY_CLASSES_ROOT\mailto\shell\open\command is "C:\Program Files\Microsoft Office\Root\Office16\OUTLOOK.EXE" -c IPM.Note /mailto "%1" on all of the test machines. 

I prefer to use the MailTo option rather than the Outlook UDF because I cannot guarantee the end users will have Office 365 installed as some will have older versions, or no Office at all.  This function is part of an End-of-Life notifier script that tells the user their equipment must be replaced and to click the mail button to send a message to our Depot and initiate the replacement.

This really is driving me nuts. Any help or suggested alternatives that anyone can provide is extremely appreciated. (long time lurker, very infrequent caller...lol)

Thanks!!

[ioa747]

check on win settings / Apps /  Default apps /
which is the default app for the  email

me e.g. I have firefox as default app for the  email , because after firefox it gives you the possibility to choose from the firefox environment, which app for the  email

 

[TheyCallMeBacon]

Thanks for the response. 

All test machines use Outlook as the default app as indicated in the registry key value provided.  To restate, it works when running in SciTE, but behaves differently after it is compiled. 

[nend]

You can try this UDF for sending mail to a 365 server.
https://www.autoitscript.com/forum/topic/203411-mail-udf/#comment-1469732

Edited June 20, 2023 by nend

[rsn]

I was unable to duplicate your results. When compiled or run from SciTE, if I didn't have a default mail client selected, it prompted me for an action. When I selected a default mail client (hat tip @ioa747) , it opened a compose email window in outlook or more options in Firefox.

Note that the MailTo class you referenced doesn't set the default mail client in Win8 or later. Microsoft migrated it to "HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\Shell\Associations\UrlAssociations\mailto" in more recent builds of Windows and it's hashed so you can't just edit it (see here).

Which leads us to how to set that: I've used SetFTA (here) or via @Danyfirex's AutoIT only solution (here). You'll still have to determine which mail client is installed but after setting whatever that is, you can use ShellExecute to your hearts delight.

 

[TheyCallMeBacon]

Thanks for the response.  I was a very active mod back in teh Flash days, so I recognize the effort that it takes to replicate errors on the one line of code I provided.  

Something in the body string ($sBody) must have been tripping something in the api soewhere.  This issue started when I tried to read the $sBody from an IniRead, and when that failed, I changed to an If/Then based upon another variable.  For whatever reason the first value worked ok, the second one caused the odd "Welcome to Office 2016" to fire.  I abandoned the changes to $sBody, leaving a modified version of the first value and it works as expected.  

As for the registry key difference, I added that just to show how the Win7 machines that will run this script were configured when the error occurred.  It was not referenced anywhere in the script. 

If this had a more permanent use I would tweak the contents of the MailTo, but this will be discarded in a few months when the Win7 macines are out of the environment.  

Thanks again for your help!