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.

Comments (3) -

  • Hi Tim

    This is a known issue. The solution is simple and makes sense.

    You cannot open a non-modal window from a modal window.  If you have a modal window, it is because you want to control program flow and complete your window before continuing. Opening a non-modal window (such as the lookup) allows other windows to be opened from the lookup and the modality (if there is such a word) to be lost.

    Don't open non-modal windows from modal windows and the problem goes away.

    David

    PS: I doubt this will be "fixed" or changed in the future because as far as MS is concerned.... you are doing it wrong. Smile
  • Many thanks David, straddling the DEX <-> .NET chasm it sometimes can be difficult to remember to look at it from the host application's perspective when one is wrapped up in solving the issues with a block of code.
  • Hi Tim,

    As the one who posted the initial post on dyndevelopers and having had Dave exactly explain the same thing to me I can confirm there is no work around.

    Initially a mod used .net based ADO lookups which were slow and so I decided to replace them with Dex lookup windows as the performance was miles ahead and that is when I ran into this issue.

    I had planned on re-doing my .net lookups using the vst table methods to see if performance is on par with the dex lookups but I decided to stick with my dex lookups and not open my dataentry form modally....I just check that the dataentry form has being filled before allowing my sales document to post.

Add comment

Loading