The Dynamics GP Blogster

In Part 1 of this two-part series, we saw how to use the  Resource Information and the Runtime Execute Setup  features in GP Power Tools to gather the name of a List View object and model pass-through sanScript code that would set the image state of a specific line to checked (marked), based on an entity value in the list. As a refresher, the following video shows where we are at this point: Now this is all good, but technically speaking, this code should be parametrized to allow us to evaluate and mark a number of entities that will be coming from a setup table in my Dexterity application. We would want to iterate through that table, pass in the configured entities as parameters to this code, so they can be evaluated and marked if exists in the list. In this article, I want to show 2 more GP Power Tools features that will make your cross-dictionary code usable and transferable from GP Power Tools directly into your Dexterity application. SQL Execute Setup In the ...

As part of an existing project I am currently working on, we need the ability to programmatically select the entities with the Binary Steam's Multi-Entity Management Select Payables Checks alternate window, when running a Decentralize process. In our software, users have the ability to pre-configure and save those settings, and our code needs to be able to set the values within the entity list view and drive the processing by clicking the Build Batch button. Binary Stream's Select Payables Checks alternate window Dexterity developers are constantly challenged by the difficulties of creating cross-dictionary code to interact with resource objects in third-party dictionaries, so I thought I would show some really cool features available in GP Power Tools, written by Microsoft MVP, David Musgrave , over at Winthrop Development Consultants, that can help developers test and package their cross-dictionary code more effectively, and without second guessing whether it will work...

Back in June of 2009 - I know, right! Time flies - I wrote an article,  Retrieving dictionary build numbers outside of Dynamics GP , in which I described two methods to retrieving the build number of a particular Dexterity dictionary, none of which involved opening Dynamics GP to do so. The first method involved hovering over the dictionary itself, which would display a summary of the properties, including the build number; the second method involved right-clicking on the dictionary, then selecting Properties, then clicking on the Dictionary tab to obtain the Dictionary Version, Name, ID, associated forms and reports dictionary, compatibility ID, and compatibility message. Sample Dictionary properties tab Shortly after the publication of this article, I started seeing messages on the forums and discussion boards that the Dictionary tab was not available in certain environments, but I never really paid attention enough to find the reasons why. Just recently I was checking t...

What if you end up creating a reminder based on a long running SmartList? It had to happen, right? As it turns out, if you create a reminder based on a long running SmartList, you will run into a nasty unhandled exception leading to an error 39, when launching Microsoft Dynamics GP. In this particular case, the user created a reminder based on the Sales Transactions SmartList to display existing Orders, except they did not filter out just the orders in the work table. When the user attempts to log into Dynamics GP, they get an hourglass cursor, which eventually ends up with the error: "Unhandled database exception Save operation on table 'ASI_SOP_HDR_MSTR_Explorer" has caused an unknown error (39)." Since the issue is caused by the reminder calling such a large SmartList query to be executed, it is best to eliminate the offending reminder. You can run the following T-SQL query to identify the reminder: -- Created by Mariano Gomez, MVP SELECT * FROM dbo.SY014...

Just recently, I ran across a question on the Microsoft Dynamics GP Community forum asking for a way to copy Quick Links from one user to another. Users can tailor their Quick Links by clicking on the Customize this page...  link on the upper right corner of the Microsoft Dynamics GP homepage. Quick Links setup These settings are stored in the syHomePageQuickLinks  table (dbo.SY08140) at the system database level. However, if you want to deploy a set of Quick Links based on a template user ID, it becomes quite the challenge to have to assist each individual user in doing so. The following SQL script allows you to copy all entries from a Source_UserId to a Destination_UserId account in Microsoft Dynamics GP: -- Created by Mariano Gomez, MVP USE DYNAMICS GO DELETE FROM dbo.SY08140 WHERE USERID = 'Destination_UserId '; INSERT INTO dbo.SY08140 (USERID ,SEQNUMBR ,TYPEID ,CmdID ,CmdFormID ,CmdDictID ,DSPLNAME ,ScbTarget...

In Part 1 of this two-part article, I showed a method using Dexterity Utilities to duplicate a window on the same form. As I also explained, this method is good and, in fact, highly recommended for windows where you have a small amount of fields and window event scripts since the method calls for renaming all of these scripts to match the renamed window. If you have a more complex window, then perhaps you will want to follow this method: Method 2 - Manipulating Form Resource File This method allows you to use the magic of copy/paste and search/replace to quickly duplicate a window within a form. The following steps should get you there: 1. Launch Microsoft Dexterity IDE and open your development dictionary.  2. Highlight the form resource containing the window you want to duplicate. Highlight the form and click the Export to Text File button the Resource Explorer toolbar. 3. In the Export to Text File window, click OK to perform the export.  ...

Just today, I was trying to solve a problem that at first seemed very simple: I needed to duplicate a Microsoft Dexterity window on the same form. Background To provide some context, I have a Dexterity form which hosts a modal window that needs to be displayed in middle of a process - we will call this window, window B of form B. Form B implements an OpenWindow form script that serves as an API to any calling script. The OpenWindow scripts implements a parameter that allows the modal window to either wait for user input or continue processing automatically (that is, without user input), which in turn would close the modal window (and the form) upon completion of all processes executed by the OpenWindow script. To make matters more interesting, one of the callers happen to be a script on another modal window in another form - we will call this window, window A of form A. Now, when this code (and process) is performed from the Microsoft Dynamics GP desktop client, everything occurs...