DynDeveloper.com

When coding a .NET transactional form, we end up putting the same piece of code in those forms over and over - the form state code.

Every form is different, but generally we use three form states = CLEAN, POPULATED, and DIRTY. We'll use an 'Item' form for discussions sake

1. Clean is for when the form is newly opened. Generally every field on the form is disabled except the main lookup field and maybe a lookup button.
2. Populated is when the user has selected an item, but has not edited anything. Generally the item number field would be disabled, but the lookup button would not be, and all the form fields would be enabled
3. Dirty is when the form has been edited an it needs to be saved. Both the item number field and the item lookup button are disabled, all remaining fields are enabled.

We also have code to clear every field on the form.

Last, we have code to add event handlers to each field, so that when the field is edited the form will become DIRTY.

I received a requirement today to write a SQL View for a smartlist that would show tax detail history and the line items. We wanted to use TX30000 for the base table so that we'd be sure that we weren't missing any lines. But TX30000 has one line for each tax detail in the order and we really wanted one line for the order, so in the view you'll see that the first line in the where clause is a sub query that returns one line for the order.

Then we join in the SOP30300 for the item info and the SOP10105 tax table for tax detail info, per the customer's request.

I always put a select statement below the 'create view' statement to be able to easily test the code.

You're going to ask why a website dedicated to Dynamics GP development needs an article on Visual Studio Tools for Office (VSTO), right?

Give me a minute to sell you.

We do integrations. We recently did an application where the integration files arrived via email. The user either has to save the files manually, or... we write an Outlook addin that does it automatically. So, we write a VSTO add-in

This article contains a short code example of how to save files in Outlook automatically.

A large part of our work here is integration. We read in data from various sources and send it into Dynamics. On a recent job we were asked to read an Excel spreadsheet and integrate it; this article is a code example of how to do that for Excel 2010 and later formats. In other words, it needs to be an .XLSX file.

The code is heavily commented so it is self explanatory.

Hi All

I need to create an integration (with Scribe Insight) for Voided checks. I trigger on insertions to CM20200 for the original check and join to PM30300 for the applied to docs.

My initial thought was to use an update trigger on CM20200 and look for void being 0 in deleted and 1 in inserted. That part seems Ok, but I need to figure out which applied payments have been reversed. After the void, payments are no longer in PM30300. (I'm not sure if they are still there when the trigger fires, but even if they are, I would prefer to join to some persistent data that exists after the void is complete, as it simplifies debugging.)

I'm assuming that there is a record somewhere of which payments the original check was applied to.

Can anyone point me in the right direction?

Regards

Hi,

I was wondering if there is a way to configure different COST LEVELS in GP, kind of the same idea of having PRICE Levels.  Has anyone heard or done this?

Thanks for your help

George

Sirs:

I'm getting 'Service cannot be started. The handle is invalid' when trying to install eConnect on a new machine. Has anyone seen this?

Public Shared Country_CodeF As DynamicsModifiedDictionary.VatCountryCodeMaintenanceForm = DynamicsModified.Forms.VatCountryCodeMaintenance

Public Shared Country_CodeW As DynamicsModifiedDictionary.VatCountryCodeMaintenanceForm.VatCountryCodeMaintenanceWindow = Country_CodeF.VatCountryCodeMaintenance

Sub Initialize() Implements IDexterityAddIn.Initialize

AddHandler Country_CodeW.AfterModalDialog, AddressOf VatCountryCodeMaintenance_AfterModalDialog

End Sub

Hello

I am trying to write a post integration script to email an error log file after an integration has completed using SQL mail.  I know that my SQL mail script works and sends the file that I designate.  I know that the script will find the correct file; but, the error log changes names each time I run the Integration, which means I have to pass a VBScript Variable to a SQL stored procedure.  Here is my code:

'****************GET THE LOG FILE INFO******

'*******************************************

 'Set the path to the log files. Edit this line as appropriate

sLogPath="D:\DYNSHARE\Log\"

 Set sFileName = CreateObject("ADODB.Parameter")

 Set pFSO = CreateObject("Scripting.FileSystemObject")

Set pFolder = pFSO.Get Folder(sLogPath)

 dtDateCreated=CDate("1/1/1900")

 For Each File In pFolder.Files

 If File.DateCreated > dtDateCreated then

 dtDateCreated = File.DateCreated

 sFileName=File.Name

 End If

Next

MsgBox (sFileName)

'*******************************************

'************CREATE AND SEND THE E-MAIL*****

 '*******************************************

Set pConnection = CreateObject("ADODB.Connection")

Set xFileName = CreateObject("ADODB.Parameter")

Set xFileName=sFileName

 'Open the connection to the database

 Call pConnection.Open("msdb","sa","Cashmere_3")

'Execute the stored procedure Call

 Call pConnection.Execute("DECLARE @filename varchar(8000) exec INSCIO_SendInegrationLog set @filename=xFileName")

 'Close the connection

Call pConnection.Close

My Error is occurring on the bottom half of the code when it is trying to pass the variable value I created xFileName to the SQL stored procedure.  Here is the exact error I am getting:

Integration Manager Exception Detail Log
Date: 3/19/2013 3:01:00 PM

Message Values:
 Primary Message: Cannot write to a closed TextWriter.
 Exception Message: Cannot write to a closed TextWriter.

Stack Informaiton:
 Source: mscorlib
 System.IO.__Error.WriterClosed()
 System.IO.StreamWriter.Flush(Boolean flushStream, Boolean flushEncoder)
 System.IO.StreamWriter.Write(Char[] buffer, Int32 index, Int32 count)
 System.IO.TextWriter.WriteLine(String value)
 Microsoft.Dynamics.GP.IntegrationManager.IMProvider.LogManager.AddActivity(Log Log, DateTime ActivityTime, String Source, String LogText, Int32 StatusCode)
 Microsoft.Dynamics.GP.IntegrationManager.IMProvider.Log.AddActivity(DateTime ActivityTime, String Source, String LogText, Int32 StatusCode)
 Microsoft.Dynamics.GP.IntegrationManager.IMProvider.IntegrationContext.WriteLogActivityEntry(String Source, String LogText, LogClassEnum LogClass, Int32 StatusCode)
 Microsoft.Dynamics.GP.IntegrationManager.IMProvider.IntegrationContext.IIntegrationEngine_Run()
 Microsoft.Dynamics.GP.IntegrationManager.IMProvider.IntegrationContext.Microsoft.Dynamics.GP.IntegrationManager.IMProvider.IIntegrationEngine.Run()
 Microsoft.Dynamics.GP.IntegrationManager.IMProvider.Integration.IIntegration_RunIntegration(IntegrationContext IntegrationContext)
 Microsoft.Dynamics.GP.IntegrationManager.IMProvider.Integration.Microsoft.Dynamics.GP.IntegrationManager.IMProvider.IIntegration.RunIntegration(IntegrationContext IntegrationContext)
 Microsoft.Dynamics.GP.IntegrationManager.frmProgress.frmProgress_Activated(Object eventSender, EventArgs eventArgs)

Data:

End Log

Any ideas what is wrong with my code?

Thanks - Joseph Guyton

When coding a .NET transactional form, we end up putting the same piece of code in those forms over and over - the form state code.

Every form is different, but generally we use three form states = CLEAN, POPULATED, and DIRTY. We'll use an 'Item' form for discussions sake

1. Clean is for when the form is newly opened. Generally every field on the form is disabled except the main lookup field and maybe a lookup button.
2. Populated is when the user has selected an item, but has not edited anything. Generally the item number field would be disabled, but the lookup button would not be, and all the form fields would be enabled
3. Dirty is when the form has been edited an it needs to be saved. Both the item number field and the item lookup button are disabled, all remaining fields are enabled.

We also have code to clear every field on the form.

Last, we have code to add event handlers to each field, so that when the field is edited the form will become DIRTY.

 This article contains template code to display Grid Footer Template and Detail Templates using a Telerik ASP.NET RadGrid. Sure, you can go to the documentation and get it... but that took me hours. Now I'll have it when I need it.

Sometimes I'm in the Telerik Winform RadGrid AddingNewRow event and I need to completely cancel the new row.

e.Cancel only cancels the add, the new row is still populated.

The code sample below will do the trick.