After a number of questions about translation recently, I have decided to focus on Dexterity's multi-lingual and translation capabilities for the next couple of weeks.

The posts in the series include:

• 11-Feb: Dexterity: Designed for Translation
   
• 13-Feb: Writing Translatable Dexterity…

I have heard many times how it's nearly close to impossible to implement IntelliSense in Microsoft Dexterity. For those of you not familiar with the term, IntelliSense is to software development what autocompletion is to Microsoft Dynamics GP data entry or Office Excel for that matter.

Similar to other autocompletion systems, IntelliSense is a convenient way to access descriptions of functions, particularly their parameter lists. It speeds up software development by reducing the amount of name memorization needed and keyboard input required. It also allows for less reference to external documentation as interactive documentation on many symbols (i.e. variables and functions) in the active scope appears dynamically in the form of tooltips while programming.

IntelliSense works by accessing an automatically generated in-memory database of classes (not [entirely] supported in Dexterity), variable names and other constructs defined…

Yesterday I presented some arguments for IntelliSense implementation in Dexterity. If you are an ISV or application developer who spends a lot of time developing Microsoft Dexterity applications and working in the Dexterity environment, you may certainly appreciate the benefits of having intellisense embedded in the sanScript language. Take this sample muck up of…

Back in 1998, when I was working with Sequel Technology (the Western Australian partner for Great Plains), we were implementing Great Plains Dynamics 4.0 for a couple of sites and were using add-on products for Service Management and Job Costing.

My business partner at the time (who did the sales) understood that Dexterity applications could be easily customised and so promised some changes to the customer.  What he (and I) did not understand at the time were the limitations Dexterity has for working across dictionaries. 

We did have some "with name" commands which could open forms, call procedures and run reports. We also had the execute() function which could be used to run Dexterity sanScript in the context of the 3rd party dictionary.  What we did not have was cross dictionary triggers.

Based on putting a number of ideas together I came up with a method of…

From the Translating Dexterity Applications Series. 

During the course of this series we have discussed how you can change terminology, or even the entire language of a Dexterity application.  We have discussed flipping the windows for languages that read from right to left.  We have also discussed using languages which have different character sets.

Languages such as French, Spanish and German etc. can use extended character such as ç è é ê Ö.

Languages such as Hebrew, Arabic, Thai and Vietnamese can use an entire extended alphabet, but they are all still single byte languages. A single byte language only needs an 8 bit value (0-255) to represent a character. Use of these character sets while handled by Dexterity is still not supported by Microsoft.

So what about Chinese, Japanese or Korean characters? These languages are double byte languages that require 16 bits (0-65535) to represent a…

This is a quick and easy way to add items to the AutoComplete list for a field.  I'm talking specifically about the autocomplete property on a field. 

In this case, the customer didn't want to use the lookup window to select an existing item number, they wanted it to be in the autocomplete list.  The problem is that in order for it to get into the autocomplete list, you have to select or type it at least one time.  They wanted all of the items in the autocomplete list…

From time to time the question comes up in newsgroups, informal conversations between developers, and surprise phone calls. The questions come in many flavors:

• What is the DEX_ROW_ID?
• Why do all Dynamics GP's SQL Server tables have a DEX_ROW_ID?
• How is the DEX_ROW_ID related to IDENTITY columns in SQL Server tables?
• Can I build reports using the DEX_ROW_ID column?

To start unreeling these questions it is best to start with two key concepts: active and passive record locks.

Active Locks

An active lock allows other users to read a table record, but not make any changes or delete the record. Active locking ensures that the user who has the active lock is the only user who can make changes or delete the record. If other users try to delete or change the record, a table-sharing error will occur. An active lock is applied each time a record is read using the Dexterity change or edit table statements with the lock keyword included.

Passive Locks

A passive lock allows other users to access the record. Other users can delete the record or make changes to it. Passive locking ensures that other users accessing the record can be made aware that the record has been deleted or that the contents of the record have changed. A passive lock is applied each time a record is read using the change or edit table statement.

What is the DEX_ROW_ID?

As part of Dexterity's table definition requirements, active locking must be enabled on a per-table basis by marking the Allow Active…

Hi all I ran into a very interesting issue today, which I would like to share with you…