Modal GP Add-in window launching Dex form causes backspace and tab weird characters - Microsoft Dynamics GP

I have found an issue when launching a Dexterity GP windows form from an addin form that is being shown modally. The launched Dexterity form generates funny characters when the backspace key is pressed and the Tab key does not work.

For example, use this code from a button click even on a new windows form that is being shown modally:

Microsoft.Dexterity.Applications.SmartListDictionary.VendorLookupForm window = Microsoft.Dexterity.Applications.SmartList.Forms.VendorLookup;

window.Open();
window.Procedures.CheckAdditionalSortCommands.Invoke(0);
window.Commands.AllVendors.Run();

Once the lookup launches, if the user presses the back-space key while they have focus on the “Find by …” box, then strange characters are inserted. We would expect instead for the text to be deleted, you can see in the screen shot, within the highlighted region an example of those characters. If the same actions are taken, only this time the origin form is a non-modal windows form, then the characters to the left of the caret are removed, as we would normally expect.

(Ignore the pixelated content in the Creditors screenshot below, done from privacy.)

 

It would seem to be the same as this post: "Invalid characters when when opening a dex form via a modal .net form" http://dyndeveloper.com/thread.aspx?Threadid=1656

I would love a work around or more information on why this happens as it means not being able to use any of the GP lookup windows from a modal windows form in an add-in, or finding a UI story that works without modal dialogs, something I’d rather not have to develop.

If you can offer any assistance, please comment on this post.

This has also been posted on the GP forums here: https://community.dynamics.com/gp/f/32/t/155082.aspx

Addendum

In our add-in, currently each lookup gets its own .NET duplicate of the built in lookup.

• We have to build bespoke for each type of field required
• This duplicate lacks some of the built in functionality that native lookups have (advanced searching/favourites/multicolumn/expand rows etc)
• For the users, the experience can be a bit janky too, with different lookups depending from where it was in GP they launched it
• There is a maintenance overhead with any code developed

For the above reasons it seemed like a good idea to wrap the native lookups in a .NET class, and not reinvent the wheel each time we need a lookup for a field we’ve not encountered before.  We have very, very many add in forms in .NET. Most of these forms involve selecting information from GP, examples such as  Sites/Debtors/Creditors/Item Numbers/Bin numbers etc. A few of those .NET forms are modal in nature, from David’s comments on this post I think it is time to review those forms and see if we can remove the modality.

Steve Endow kindly tweeted the way he tackles this. Perhaps I need to use GP lookups where it makes sense and develop an advanced search window of our own that is more generic and make certain that if that alternative window is used, that it adds value to the places where it is used vs the native lookups.

@TimWappat I use a custom .NET lookup w/dynamic search, similar to my VBA version http://t.co/0KZpmzqxDW pic.twitter.com/mw75tLjbvl

— Steve Endow (@steveendow) April 2, 2015