Dynamics GP 2018 R2 displays full screen by default?

By Steve Endow

I recently installed Dynamics GP 2018 R2 on my laptop.  The install went smoothly and GP works fine.

But I noticed something odd, and annoying.  Every time I launched GP 2018 R2, the application window would open maximized.  Before the login prompt appeared, the GP application window would fill the screen.  I thought maybe it launched in full screen on the first launch, but then once I resized the window and restarted, it would remember the window size settings.

But that didn't work.  I resized the GP application window, closed it, then relaunched it.  Nope--it would relaunch in full screen again.  I tried Run As Administrator to see if that made a difference.  Nope.  It would always launch maximized.

This was noticeable because I have never seen this behavior in GP before.

So where would this behavior be controlled?  Very likely in the Dex.ini file, of course.

Sure enough, as soon as I scanned the Dex.ini file, I saw the setting.

The likely culprit:  WindowMax=TRUE.

I've never noticed this setting, and didn't know it existed until today.  So I changed the setting to FALSE and restarted GP.

Presto, Dynamics GP launched with a non-maximized window, just like normal.  Problem solved.

Just to make sure I wasn't imagining things, I checked my GP 2018 install, and I see that the Dex.ini has the WindowMax setting, but the default value is FALSE.  I checked a GP 2016 install, and the default value is also FALSE.

I'm not sure if the default value for GP 2018 R2 is WindowMax=TRUE, or if that flag is only set to true when you choose to install the Web Client components.

But if you see this behavior, and you want to change it, now you know!

Steve Endow is a Microsoft MVP in Los Angeles.  He is the owner of Precipio Services, which provides Dynamics GP integrations, customizations, and automation solutions.

You can also find him on Twitter, YouTube, and Google+

http://www.precipioservices.com

I'm a kid in the Microsoft Candy Store

It's a fantastic time to be working with Microsoft products.

(Thanks to David Gersten for the idea for this blog post!)

Let's start with Microsoft Azure.  Open this web page and read the list.

https://azure.microsoft.com/en-us/services/

Just look at that list.  It's pretty long, so you'll need to scroll down.  And scroll some more.  Keep scrolling.  And scrolling.

It's really, really, long

It's a crazy long list.  It's geek heaven.  It's consultant heaven.  So many amazing services to play with and learn and offer to customers.


Next, there is the Power Platform.

Build a Zero Code Web Service in Minutes With Microsoft Flow

The phone rings and you answer the call.  The caller is a manager from a medium sized business who uses the Microsoft Dynamics GP ERP system.  He explains that his company has a new contract with a distributor, and they need to have their product shipped by a 3PL warehouse.  That's the good news.

The challenge is that the 3PL warehouse needs to send the company shipment information.  Items shipped, quantities shipped, and shipment tracking numbers.  The company needs to update their orders in Dynamics GP so that they can generate invoices.

The 3PL uses a SaaS service that can provide this shipment information, but that SaaS service can only call a web service.

And this small business doesn't have a web service.  Or internal developers.  Or an internal IT staff.

What can we do to help this company?

Do we try to help them used the outdated and problematic native Dynamics GP Web Services, and see if we run into problems with authentication, SOAP, limited endpoints, and fixed functionality? Risky, with an uncertain outcome, and difficult to estimate the effort and cost.

Do we propose that they develop a custom modern web service that will be highly flexible and fast?  We can create a pretty accurate estimate of the effort for this project, but it is expensive for the customer, feels like overkill for a single endpoint, and will require a developer to maintain the code going forward.

Do we consider something like Azure Functions, which eliminates the need for infrastructure and developing a full web service, but still requires a developer?

Or is there another option?

What about Microsoft Flow?

No, really.  Not joking.

Can Microsoft Flow address the challenge of building a custom, modern, web service that will allow the customer to receive the shipment data from the 3PL's SaaS service?

Let's find out.

Here's a video presentation discussing Flow web services and walking through the creation of the sample Flow:

https://www.youtube.com/watch?v=gLLQM05K38w

If we break down the project, there are a few general requirements that we need to address:

1. Web service - We need a web service endpoint that the 3PL can call

2. Data storage - We need to store the incoming data, at least temporarily or for archiving or logging

3. ERP import - We need to eventually get the shipment data into the ERP system