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 in or referenced by the application being edited. With some extra effort, IntelliSense can complete statements too.
Back to Dexterity though, one of the discussion points that seems to prevail around the implementation of IntelliSense is the fact that Dexterity does not support the typical telescopic reference (or scope) for objects, attributes, and properties and that makes sense, because in practical sense Dexterity is not an object-oriented programming (OOP) language. So, for example, you cannot have a construct similar to rmCustomerMaster.CustomerNumber.Value inside of Dexterity as you would if you were using Visual Studio Tools for example.
But then came Microsoft SQL Server 2008 to prove everyone wrong. TSQL – Microsoft SQL Server’s programming language – is not an object oriented programming language, hence, it does not allow for contructs in the form of telescopic references as available in any Visual Studio language. However, Microsoft SQL Server 2008 IntelliSense is able to provide enough context for objects like variables, parameter information for most language functions, and then column information for tables, and I am sure if Microsoft had put a little more effort into the the technology, they would have been able to provide parameters for stored procedures.
Now, I intentionally included the word “entirely” couple paragraphs aback when describing Dex’s OOP capabilities, the reason being, while Dexterity is not a true OOP environment, it does support object-based development, this is, the ability to create state machines and properties with the use of traditional forms and composite fields. Take for example, the implementation of the Purchase Order Processing module in Microsoft Dynamics GP. This would be one place where IntelliSense could prove very usefull as it would narrow the scope of the Me instantiations created based on composite fields.
I can only hope that this feature be considered — seriously! — for future releases of Dexterity. If it could be done in Microsoft SQL Server, I am sure it can be done for Dexterity. Let me know what you think about the subject.
Until next post!
Mariano Gomez, MVP
Maximum Global Business, LLC