Seen this from three users recently. The issue is that the user clicks the on order hyperlink text in item enquiry to see the purchase orders in Purchase Order Processing Item Enquiry, but nothing is shown in the window.
Notice at the bottom it says processing. I assume that this window is trying to populate on another thread to keep it responsive and that thread is never returning the results?
Going to the GP process monitor in this example showed that it was clogged up with a posting process that was not budging.
Once the user was cleared down, previous transaction level posting error dealt with and looked again, everything was working as expected.
I also have seen where doing this same thing but from a link I provide in another window, that calls the same enquiry window causes it to work. Weird! I can only think there might be two different methods being called, one with background and the other not? When I call it in my code I’m getting the foreground, when GP does it, it uses the background?
I’m guessing at all this, but thought it worth documenting the findings so far, I will come back to update this post if I find any root causes.
Now we have Visual Studio 2017 and again it is awesome! Drop what you are doing and start developing with it right now!
If you are a .NET Dynamics GP Addin developer you will find that the project templates are not available for Visual Studio 2017, at the time of writing this. See in the screen shot, only goes up to VS2015.
I wrote a post on how to install them into Visual studio 2015 a while back, when the previous version of GP did not support that VS2015, but that method cannot be used anymore for Visual Studio 2017. This is because of a new method of discovery that Visual Studio uses for project templates. This has been implemented by Microsoft for Visual Studio 2017, using manifest files to point to the project templates. I’m guessing this is part of making Visual Studio more quick and to perhaps work with marketplace better.
You will also notice that the install directory for Visual Studio has moved into a Visual Studio subdirectory, I guess that makes things tidy & makes sitting different versions together easier? My location for Enterprise project directories is now:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\ProjectTemplates
below you can see the .vstman manifest files that point to the templates.
The directory structure of the templates has changed a little too, having a 1033 or similar folder holding them and a another manifest file, “Windows.VSTDIR” above each of those folders.
To make things simple I have added a Visual Studio Extension into the Visual Studio Marketplace that addresses this problem, see here for details.
Searching on the Master Number field in the normal Sales Transactions smart list in Dynamics GP can cause an error to occur. In the following screenshot you can see the search, nothing odd there?
However on executing the search the following error occurs:
Unhandled script exception:
Bad power value
This is shown below, both the screenshots are of the same dialog, with the error scrolled down to read it.
What causes this? The error from an internet search seems to occur in reporting when formatting numbers into text, this was the clue I needed. If someone has configured the master number field to be formatted with a comma separator, then this will make the field unsearchable due to this error.
To correct the issue, check the format of the field. Click modify on the smart list results window, this will launch the SmartList Builder window. Locate the Master Number Field and click its display name to get the row selected. Then click the field options icon as shown in the screen shot below.
The field options window will open, uncheck any formatting in this window, in this case, take off the show thousands separator.
Save the options window and then the SmartList Builder window.
Attempting the same search again will now work normally with no exceptions.
Inspired from the forum post: Sales Transactions Smartlist - error searching for Master Number
If this helped let me know with a comment, it motivates me to blog more!
When developing Dynamics GP addins, the above error can occur for a number of reasons. It generally means what it says, the referenced assembly is looking for a resource it can’t find on the available search locations. If this is encountered whist developing a Dynamics GP addin while attempting to run the addin as an application outside of GP (say in debug from Visual Studio), then this error may well be encountered. What the developer may find odd is that it will work when ran from GP as an addin. Why is this so?
The “bridge dll” is the eventing route between GP and .NET applications (including addins) but it has other dependencies from the dexterity shared components. These are required to be present on the standard system environment paths searched when looking for dlls (search online for dll dependency search paths for more info).
When the addin is ran normally, as an addin by the Dynamics GP process, the dependencies are provided by Dynamics GP process, from the process’s application folder. When running a free standing GP app, from the debug folder of Visual Studio, then the dependencies must be made available to the application through putting the dlls in the .net application’s folder (or other path that will be searched).
By placing TNTLIB.dll and DDAPI.dll into the bin folder should solve the problem. Strictly speaking xdll32.dll and Bidi32.dll should be included too (search online for stand alone Dexterity applications). In Visual Studio this can be achieved consistently by including the files in the project and setting them to copy to output. However it may be preferable to only do this for debug builds, that should be possible with Visual Studio post build steps or manually.
The following are the files that should be included if running stand alone.
|File ||Description |
|Tntlib.dll ||Library used by other dlls and executables |
|Ddapi.dll ||Data Dictionary API –provides access to Dexterity dictionaries |
|Bidi32.dll ||Additional dependency for dexterity (My guess is: BiDirectional Convert Ansi To Oem code page, I think it converts extended languages that go left to right and right to left to oem code page characters and back again) |
|Xdll32.dll ||Dex gateway to other 32bit dlls |
| || |
Just as a reminder, we should already be familiar with the usual .NET dlls required for .NET addins that would normally be referenced:
|File ||Description |
|Microsoft.Dexterity.Shell.dll ||.NET managed shell |
|Microsoft.Dynamics.Framework. UI.Navigation.dll ||.NET navigation |
|Microsoft.Dynamics.Framework. UI.WinForms.Controls.dll ||.NET windows controls. |
Please comment if you found this useful – motivates me to keep blogging…