Microsoft Dynamics NAV 2009 Programming Cookbook

Build better business applications with NAV

• Write NAV programs to do everything from finding data in a table to integration with an instant messenger client
• Develop your own .NET code to perform tasks that NAV cannot handle on its own
• Work with SQL Server to create better integration between NAV and other systems
• Learn to use the new features of the NAV 2009 Role Tailored Client
• Easy-to-read recipes with detailed explanations and images
• Maximize your learning with short tutorials that tell you exactly what you need to know without all of the fluff

If you have programmed with Windows or used a Windows-based operating system for any length of time you will see that it is really an all-encompassing OS, at least for our needs. Unlike with other types of software development, we don’t need to interact with device drivers or create three dimensional graphics for our users. Most of what we need to do involves integrating with the file system; that is searching for files or folders and running external applications.

Occasionally, we may need to go a little deeper. There may be instances where we need to check the user’s environment, query the registry, or check for specific administrator permissions. These can all be performed within NAV, although many require a little outside help from a built-in or custom automation control.

As Windows is such a large piece of software, it already contains ways for us to do these things. As a result, the recipes in this article are not very lengthy or complicated, but that does not make them any less useful. They explore the basics of what you can do with the OS and it is up to you to decide when and how to make the best use of them.

It is important to note that many of these recipes will require additional coding to make them work with the RoleTailored client. This is because the code is actually executing on a server, not your own computer as it does with the Classic client.

Using HYPERLINK to open external files

Many times you may need to open files external to the NAV program. NAV has a built-in function that interacts with the file system to open the file with the appropriate application.

How to do it…

1. Create a new codeunit from Object Designer.
2. Add the following global variable:
   NameTypeSelectionInteger
3. Add the following code to the OnRun trigger:

   Selection := STRMENU(‘Image,Website’);
   IF Selection = 1 THEN
   HYPERLINK(‘C:UsersPublic
   PicturesSample PicturesPenguins.jpg’)
   ELSE
   HYPERLINK(‘HTTP://www.mibuso.com’);

4. Save and close the codeunit.

How it works…

When you run the codeunit you will be presented with a simple selection menu that asks you to choose between an image and a website. Depending on your choice we will use the HYPERLINK command to load a specific file. This command takes in a single string which points to a location and loads that pointer using the default program on the current machine.

If you choose Image then the Penguins image that ships with Microsoft Windows 7 will load in the default program you have set to open pictures, usually Windows Photo Viewer.

If you choose Website then the Mibuso website will open in your default internet browser, typically Internet Explorer.

There’s more…

With the RoleTailored client, it is best to use HYPERLINK with shared drives and folders. This is because the actual HYPERLINK command is running on the NAV service tier, not on the local computer or client. It has no idea about the user’s system. This example is for the Classic client (thus the link to a file on the C: drive), but changing the parameter to a shared file on your network should work just fine.

See also

• Using SHELL to run external applications
• Browsing for a file
• Checking file and folder access permissions

Working with environment variables

Environment variables are a set of named values that can affect the way processes and applications run on a computer. NAV has a built-in function to reference these variables and lets you change the way it functions.

How to do it…

1. Create a new codeunit from Object Designer.
2. Add the following code to the OnRun trigger:

   MESSAGE(‘ OS: %1Temp: %2WinDir: %3’, ENVIRON(‘OS’),
   ENVIRON(‘TEMP’), ENVIRON(‘WINDIR’));

3. Save and close the codeunit.

How it works…

The ENVIRON function takes in a single string and returns a string. Our codeunit uses the ENVIRON function to return three common environment variables: the name of the operating system, the path to the temporary folder for the current user, and the path to the Windows installation directory.

In Windows 7, in order to see all of the options available to the ENVIRON command, simply right-click on My Computer and go to Properties.

Click on Advanced system settings, the Advanced tab, and then on the Environment Variables button. You will find them in the System variables section of the window.

There’s more…

This recipe is not compatible with the RoleTailored client. The code running on the NAV service tier does not know anything about the client operating system. There is, however, a way around this. We need a way to force code to be executed on the client-side instead of the server-side.

ENVIRON for the RoleTailored client

We can force our code to execute on the client-side by creating an Automation. Start by creating a new project in Visual Studio with the following code:

using System.Management;
using System.Runtime.InteropServices;

namespace RemoteSystemInfo
{
[ClassInterface(ClassInterfaceType.AutoDual)]
[ProgId(“RemoteSystemInfo”)]
[ComVisible(true)]
public class RemoteSystemInfo
{
public string GetSysInfo(string domain, string machine,
string username, string password, string variable)
{
ManagementObjectSearcher query = null;
ManagementObjectCollection queryCollection = null;
ConnectionOptions opt = new ConnectionOptions();
opt.Impersonation = ImpersonationLevel.Impersonate;
opt.EnablePrivileges = true;
opt.Username = username;
opt.Password = password;

   try
{
ManagementPath p = new ManagementPath(@”” +
machine + @”rootcimv2″);
ManagementScope msc = new ManagementScope(p, opt);
SelectQuery q = new SelectQuery(“Win32_Environment”);
query = new ManagementObjectSearcher(msc, q, null);
queryCollection = query.Get();

    foreach (ManagementBaseObject envVar in queryCollection)
{
if (envVar[“Name”].ToString() == variable)
{
return envVar[“VariableValue”].ToString();
}
}
}
catch (ManagementException e)
{
throw new ManagementException(“Management Exception:
” + e.Message);
}
catch (System.UnauthorizedAccessException e)
{
throw new ManagementException(“Access Exception:
” + e.Message);
}
return “”;
}
}
}

When using the Automation in your NAV objects you must do the following:

CREATE(MyAutomation, FALSE, TRUE);

The third parameter tells the system to create the instance of the Automation on the client (TRUE) and not the server (FALSE). As the code executes on the client machine it can query the environment variables and easily return the correct result. Just pass the appropriate values to the GetSysInfo function.

See also

• Using SHELL

Using SHELL to run external applications

Just as external files can be opened from within NAV, so can external programs. This recipe will show you how to launch one of such applications.

How to do it…

1. Create a new codeunit from Object Designer.
2. Add the following code to the OnRun trigger:

   SHELL(ENVIRON(‘WINDIR’) + ‘notepad.exe’);

3. Save and close the codeunit.

How it works…

The SHELL command takes in a required string parameter representing the application to launch. There is an optional second parameter that will be passed as an argument to the application to be launched (not used here). This argument could represent a file to open or other flags incorporated into the program.

See also

• Querying the registry