Mail Codeunit 397 Not Working in 2013 Beta?

OldNavDog

I am working with the U.S. version of the NAV 2013 Beta. I have been trying to get a previously-working piece of C/AL code that called the NewMessage function in the Mail Codeunit 397.

Everything is being passed to the function perfectly, but Outlook simply doesn't open. No Error, nothing. The same exact "calling" code works perfectly in 2009 R2. And before you ask, yes I DO have the "Show Dialog" (or whatever it is called) argument set to TRUE.

Here's what's even more maddening:If you click the little "Mail" button that appears on many Pages next to an email field, Outlook INSTANTLY brings up an email, addressed to whatever is the value in the email field.

I have scoured the e-planet, but all I can find is information on setting up Outlook Synchronization (which I don't need for this). I have even gone so far as to set up SMTP Mail with the server settings, etc, just in case...

One potential clue: We do NOT use Exchange, but rather use an external POP/SMTP mail service with our web hosting service. But, I stress that all of this has worked just great in 2009 R2. The only change I can think of is that now that there are no more COM objects (essentially), Codeunit 397 now uses a ".NET-ified" version of the Automation.

I have tried this with both a Service Tier running on a server running Sever 2008 R2, as well as with a "local" install of 2013, with everything residing on my laptop. In both cases, NAV 2013 itself seems to be working just fine, it's just that calls to Mail.NewMessage() SEEM to be being ignored.

By the way, this is NOT a case of the email getting "stuck" in the Outbox, or in the Drafts. They just don't SEEM to be being created AT ALL.

Help me Obi-MIBUSO; you're my only hope! [-o<

DenSter

NAV 2013 does not support COM, so all of the automation variables that point to COM objects won't work anymore. A lot of these automations have been changed to use DotNet code instead. Take a look at the standard NAV 2013 codeunit 397 and compare it to the NAV 2009 version, you'll see how that has changed.

ara3n

one correction. nav 2013 does support com but instantiated on client. On server it only supports 64 bit COM.

OldNavDog

I must not have been clear: This is NOT a matter of me using old COM objects.

MIBUSO saw fit to EAT my previous reply because I committed the apparently unforgivable sin of having an email address in a line of text; so let me try again...

For testing purposes, I am simply calling the "NewMessage" function in Codeunit 397 (Mail) in the U.S. version of the 2013 beta. I created a test Page in 2013 with an Action on it that has a hard-coded "call" to that function (see below).

THERE IS NO AUTOMATION ON MY TEST PAGE. IT IS SIMPLY USED AS A PLACE TO STICK A BUTTON TO CALL CODEUNIT 397 (see below).

(To avoid the wrath of the SQL backend that MIBUSO is built-upon, I will change the "call" to replace the email address with fake syntax:)

Here is the sum-total of the TEST code I am using to call Codeunit 397 IN 2013. Keep in mind that this test Page works FINE in 2009 R2:

Mail.NewMessage('myaddressATmycompany.com','','Testing','This is a test','',TRUE);

Of course, the 'myaddressATmycompany.com' is actually a real (my) email address, with an 'at sign'. And "Mail" is a Global defined as Codeunit 397.

As I stated above, this code is called by an Action "button" I have placed on a TEST Page in 2013.

I AM NOT USING ANY AUTOMATION, OTHER THAN WHAT IS EMBEDDED IN THE 2013 "Mail" CODEUNIT (397) !!!

Also on my test Page, (which is based on the Customer table, but that is unimportant), I have placed the "E-Mail" field. This field comes with an automatic "email" icon next to it. CLICKING THAT icon DOES LAUNCH OUTLOOK AS EXPECTED!!!

But my test "call", above, does NOT.

](*,)

So, there is either a bug in the 2013 Mail codeunit (or, more likely, in the DotNet-ified automation it uses), OR there is an (undocumented?) change in the way that NewMessage works; because this same test Page (exported as text, then imported into a 2009 R2 database) DOES work exactly as expected.

I have carefully reviewed the variables in the 2013 Mail codeunit, and all of the "automation" has been changed to use DotNet.

Please review my original post to see the rest of my testing attempts.

Does this help?

Thanks In Advance!

DenSter

So let me get this straight.... I spend some serious time looking at two different versions of that codeunit (had to start up my virtual machine for the 2013 one), shared my thoughts on the subject, and I get yelled at. I don't like to be yelled at, so I'll leave it up to others to help out. I do hope you get your problem fixed.

OldNavDog

Seriously, I wasn't yelling at anyone. I was blaming myself for not being clear.

So my attempt to clear up misunderstanding has resulted in even MORE misunderstanding!?!

SORRY!!!! That really wasn't my intent, honest!

Can we start again? [-o<

BardurKnudsen

Thank you for reporting this issue on NAV 2013. I can repro the same (lack of) behavior in NAV2013 Beta. We are looking into the issue.

ddlarsc

This is a known issue we have in BETA 'Microsoft.Dynamics.Nav.Integration.Office' dotnet component. This is fixed in the RC release, so it' only a matter of replacing this assembly from the RC build.

kine

And the RC build could be found where? :-)

davmac1

On Partnersource of course - the question is when.... 8)
I see the new price list or NAV 2013 is effective Oct 1, so I am guessing Oct 1 +/- a few days.
Maybe we should see what the odds are with the bookies in the UK.

OldNavDog

Thanks to all who actually took time to read and respond to my question, rather than wasting their effort bashing my old-fashioned "emphasis by capitalization", LOL! :roll:

I guess I will be waiting for the RTM version, then... THANKS! :whistle:

The MIBUSO gang (well, at least MOST of them!) is the best!!!

=D> =D> =D> =D>

OldNavDog

I don't suppose there's any chance of getting a "prerelease" copy of those new Automation objects; so we in the field can provide more "valuable feedback"?

:whistle:

(Doesn't hurt to ask!)

[-o< [-o< [-o<

Thanks.

ddlarsc

Hi Again we investigated this issue a Little more yesterday.

The fix seem to be available also in out BETAREFRESH release build 33595 or later.

Second you need to ensure that your Office contains the latest updates. E.g. Office 2010 need to have SP1 installed.

BardurKnudsen

We aim at shipping a 'release candidate' to partner source soon - within a couple of weeks. However, note that we REALLY want to fix any serious error that we (or you ) might find during tests, so the date is subject to change.

OldNavDog

Thanks for the update, Lars & Bardur!

I will watch PartnerSource with abated breath for those updates!

Now if Microsoft would simply release a pain-free and semi-automatic way to generate a .NET RCW Wrapper for all our NAV COM Automation we've been relying on from both Microsoft and Third Parties for the past, oh, DECADE or so, I'd be dancing a jig!!!

Afterall, that ability is built into the .NET frameworks already...

http://msdn.microsoft.com/en-us/magazine/cc301750.aspx

Sorry, couldn't resist!

SteveL

Hi, I have this same problem with my UK release version. Did you find a solution?

OldNavDog

SteveL wrote:

Hi, I have this same problem with my UK release version. Did you find a solution?

Actually, I believe that MS/NAV acknowledged and fixed this for the 2013 "release" erosion (at least in the US).

My feeling is that perhaps the UK version may not have gotten that update in time for the release date.

I'll bet you'll find a hotfix for that. I am unfortunately not familiar with the way that works outside the USA; so perhaps some of my European brothers can chime in and help...