This is a reposting of an article Patrick Roth originally wrote on my Developing for Dynamics GP blog.
I’ve seen several questions over the years on Smartlist of the “Why doesn’t it?” variety such as:
Why does Smartlist export to Excel so slowly?
Because Smartlist exports row by row and sets each cell individually.
Why does Smartlist automatically try to display the default Smartlist when the node is selected (such as Customers)?
It was designed that way because a GP Smartlist is easy to stop. Smartlist Builder created Smartlists aren’t easy to stop because they are running a big SQL query before they can start to fill. A Dexterity based Smartlist doesn’t work that way.
Why doesn’t the splitter control between the Smartlist object & favorites panel and the data panel work?
Because there isn’t one. The black line you see is merely the treeview control (the left control) and the listview control (the control on the right where data shows) touching each other.
When I expand my Smartlist window to see more information, the Smartlist object field also grows taking up too much room.
Yes it does, doesn’t it? But that is why you have a nice big 24″ monitor for. Don’t you? Don’t look at me, I passed on a 24″ monitor and kept my old 19″ widescreen that looks nice and that I like a lot.
But this is one area where we can do something about how our Smartlist window displays.
The first thing we should look at is why controls on a window behave as they do.
This is a fairly broad question and it depends on the types of fields on the window. However for our purposes of this window, there is a property on the window called Resizeable. This can be set to:
False: No fields change size
True – Automatic: Dexterity determines how the fields resize
True – Per Field: Each field has settings to determine how it should resize
In this window, the setting is “True – Per Field” which means it is already set as we need it. We just need to change the behavior of a few fields and how they resize themselves as the window is resized.
If Modifier, each field has a Resize-Horizontal and Resize-Vertical property that defines how the field will resize if the window is resized both horizontally and vertically.
If a field is set to one of the different “Grow” settings, then the field will grow proportionately to how much the window grows in that direction.
In the ASI_Explorer window in Modifier, the field ASI_ExplorerTreeView (the tree that holds the Smartlists and Favorites) has the setting for Resize-Horizontal set to “Stay Left-Grow”. Meaning “Stay anchored to the left side but grow as the window grows”. We don’t want that, we want it to stay there and stay the same size. So by using Modifier to change the property to “Stay Left”, the field will no longer grow.
For the ASI_ExplorerListView (and ‘(L) ObjectString’ above it), these are set to “Stay Right-Grow” because they should resize. They are set to “Stay Right” because it is expected that the ASI_ExplorerTreeView field will also grow. Since the ASI_ExplorerTreeView field will no longer will grow, we need to change the property to just “Grow” otherwise we’ll end up with a big gap between the fields as the ASI_ExplorerListView field moves to the right.
That really is it, just changing this property on 3 fields solves the issue.
After granting myself security to the modified form in the Modified/Alternate Forms and Reports window and displaying the Inventory Purchase Receipts Smartlist, I can easily see every column in the out-of-the-box Smartlist.
You can very clearly see above that the Smartlist Objects & Favorite control on the left is a fixed size allowing the maximum amount of area for the important Smartlist data to show.
I’ve attached a package file of this modification to this post. It was created in 10.0 but I would guess it’ll work fine in 9.0 and likely GP 2010 when it releases.
// Copyright © Microsoft Corporation. All Rights Reserved.
// This code and any code in attachments to this blog
// post is released under the terms of the
// Microsoft Public License (MS-PL, http://opensource.org/licenses/ms-pl.html.)
This article was originally posted on the Developing for Dynamics GP Blog and has been reposted on http://www.winthropdc.com/blog.