web
You’re offline. This is a read only version of the page.
close
Skip to main content

Notifications

Announcements

No record found.

News and Announcements icon
Community site session details

Community site session details

Session Id :
Dynamics 365 Community / Forums / Microsoft Dynamics SL (Archived) / Using Solomon COM libr...
Microsoft Dynamics SL (Archived)

Using Solomon COM libraries with C# for SL 6.5

(0) ShareShare
ReportReport
Posted on by wildturtle21 75

Hello,

We are using the SOLOMON COM libraries to interact with Dynamics SL 6.5 Professional edition in C#. When calling an Application.Quit() to exit the application instance, an event gets fired requesting confirmation and a balance match override. We handle the event by setting the Ref ResponseMessage instance to the appropriate enum value (NO). However, a COM exception gets thrown with the same content as the message that was appropriately handled. Any ideas what could have gone wrong here? I can always catch the exception and kill the exe as a process but this isn't really a clean way of handling. Do you know of any sample code you can point me to for handling Dynamics Solomon messages in C#?

Your input would be much appreciated.

Many Thanks

--Sam Abraham

*This post is locked for comments

I have the same question (0)
  • Nayan Mansinha Profile Picture
    Nayan Mansinha 1,245 on at

    hmmm very interesting.... I would love to know how and what COM objects are you using?  What is you C# app look like? Desktop app or web app/service?

    Inherently managed code always had problems with COM (interop) but things might be changing with C# 4 though.  Haven't dived deep into this but may be you want to experiment with C# 4 (using dynamic system type) to see if Solomon COM objects behave properly.

    Thanks

  • Verified answer
    Paul Phillips Profile Picture
    Paul Phillips 590 on at

    Hi,

    I'm not sure if you are referring to doing interop over the .dll business objects that exist for a few areas of the system (e.g. DMGSalesOrderBO.dll, FMGCustomerBO.dll, etc.) or whether you are referring to the Solomon Object Model. If it is the business objects I can't offer much help. That isn't really a supported integration method and isn't documented to my knowledge, so you probably won't have much luck finding help.

    That said, your post has some parallels to how the Solomon Object Model works so I'll provide some info in hopes that it might apply. In Object Model, any system message that corresponds to a message box presented to the user in the UI is first raised through the Microsoft.Dynamics.SL.ObjectModel.SIVApplication.Message event (signature below in VB.net), then followed immediately after by an exception for the same thing. That sounds like what is happening in your case.

    Public Event Message(ByVal MessageNumber As Integer, ByVal MessageText As String, ByVal MessageType As Microsoft.Dynamics.SL.ObjectModel.sivMessageType, ByRef MessageResponse As Microsoft.Dynamics.SL.ObjectModel.sivMessageResponse)

    If your scenario is like Object Model, you can probably just eat the exception. First, check whether the com exception Source contains "solomon" to see if it is related to Solomon. Add 2147221504 to the com ErrorCode value to convert to the SL message number. 2048 is non-fatal, 2049 is fatal, 2050 is an internal com exception, and 7500 to 7569 are other object model errors. Not sure if those work or correspond in your scenario.

    Also, I'm not sure if this is applicable, but getting an SL screen instance to quit in object model is dicey sometimes. The process I follow is:

    sivApp.Quit()

    GC.Collect()
    GC.WaitForPendingFinalizers()
    GC.Collect()
    GC.WaitForPendingFinalizers()
    GC.Collect()
    GC.WaitForPendingFinalizers()
    sivApp.Dispose()
    sivApp =     Nothing

    Note that the garbage collection calls is made 3 times in succession - the knowledgebase samples only do it once or twice, but I've found that three times is necessary in some cases. sivApp is the Object Model reference to the screen. Also, I think in some cases there can be one or more underlying com references that don't get disposed of properly. Sometimes I'll add a Thread.Sleep(2000) after quit if the screen is being difficult.

    Finally, if you eventually upgrade to version 7 there is a hotfix dealing specifically with calling object model from C# (doesn't occur from VB.net) that might be relevant:

    https://mbs.microsoft.com/knowledgebase/kbdisplay.aspx?wtntzsmnwukntmmyxupyzqpouxnxspsyrvuspuqomulslwvk 

    Hope this helps,
    Paul

  • pbrattin Profile Picture
    pbrattin 1,850 on at

    I think these issues are easier to deal with in VB.Net because VB.Net has the Resume Next and you can catch the errors as documented in the post by Paul Phillips and not have to kill the process. There are a couple onerous issues that we have to do the Paul Phillips method and then resume next to let the program finish normally.

  • wildturtle21 Profile Picture
    wildturtle21 75 on at

    Thanks Paul that was VERY helpful.

  • Suggested answer
    Liam Flint Profile Picture
    Liam Flint 10 on at

    I also think these issues are easy to use with ZetExcel tools.

Under review

Thank you for your reply! To ensure a great experience for everyone, your content is awaiting approval by our Community Managers. Please check back later.

Helpful resources

Quick Links

Responsible AI policies

As AI tools become more common, we’re introducing a Responsible AI Use…

Neeraj Kumar – Community Spotlight

We are honored to recognize Neeraj Kumar as our Community Spotlight honoree for…

Congratulations to the November Top 10 Community Leaders!

These are the community rock stars!

Leaderboard > 🔒一 Microsoft Dynamics SL (Archived)

Last 30 days Overall leaderboard

Featured topics

Product updates

Dynamics 365 release plans