Smartlist: Only the data area should grow

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.

Regards,

Patrick
Developer Support

// 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, https://opensource.org/licenses/ms-pl.html.)

SmartList.package

Comments

• Anonymous
  April 30, 2010
  Fantastic tip! Thanks for the package file too. We missed you at Convergence. MG.-

• Anonymous
  May 01, 2010
  So why doesn't MBS actually fix all of the above listed limitations?  Put a splitter control in smartlist.  Fix the way it exports rows on a row by row basis (You know when I can take 20,000 rows and output them in under 10 seconds to excel you should be able to as well, it's really not that hard.)

• Anonymous
  May 02, 2010
  Because there isn't currently a splitter control.  You'd have to make one for this one feature which, while annoying, isn't a show stopper. "You know when I can take 20,000 rows and output them in under 10 seconds to excel you should be able to as well, it's really not that hard" How did you do that exactly?  Pulling data from another app from within excel isn't the the same as automating excel in the other direction. But I have some ideas on this as well.

• Anonymous
  May 02, 2010
  How about using Excel Report builder which then creates the data in Excel with a dynamic link back to the source data? This is much better than the static (and immediately out of date) data from SmartList. David

• Anonymous
  May 02, 2010
  David, You'll note that Matt said that he already could export 20000 rows to excel in 10 seconds.  So my guess is that this is via just an excel query on the fly or an Excel Builder report (which is the same thing).

• Anonymous
  May 03, 2010
  The comment has been removed

• Anonymous
  May 03, 2010
  "what appears to be happening is that Dynamics GP is acting as the middle man between your data (from the database) and excel" Not exactly - the data is in the smartlist window already. "..job much faster then dexterity can." Not Dexterity's fault specifically- the slowness comes from the COM automation. "Interact with the excel API programattically" Well, that is what dexterity is doing now.  But cell by cell.  Yes that is the slow way as you'll see in one of my upcoming blog articles.

• Anonymous
  May 03, 2010
  Gotcha, yeah thats better stated, the slowness comes from the COM automation.  You should cut that out of the fix and just instantiate an instance of excel and send it the necessary commands + sql query string and have it pull the data.  Be much faster then setting things cell by cell. BTW, where is the dynamics gp 2010 CD download on partnersource?  GA is May 1, but yet nothing is available to download.  Same goes for the eConnect 2010 SDK, that download is nowhere to be found and it's past the GA date.

• Anonymous
  May 03, 2010
  For non-SLB smartlist there isn't a SQL Query string.  Dexterity loops through the tables and then displays the data. But there are still solutions. For GP 2010, looks like published today but takes a bit to refresh externally. here are the links i have, didn't test them. https://mbs.microsoft.com/partnersource/support/selfsupport/productreleases/MDGP2010_Release_Download https://mbs.microsoft.com/customersource/downloads/servicepacks/MDGP2010_Release_Download

• Anonymous
  May 03, 2010
  This is Fantastic Santosh Surti

• Anonymous
  May 04, 2010
  The comment has been removed

• Anonymous
  May 04, 2010
  Posting from DynamicAccounting.net http://msdynamicsgp.blogspot.com/2010/05/smart-list-tree-view-space.html

• Anonymous
  August 08, 2012
  I can't get the package to work with GP 2010...is there another fix, or is the control somewhere we can get to?

• Anonymous
  August 08, 2012
  Hi Abra Do you have the latest build of the Support Debugging Tool installed? Use Configuration Export/Import to import the settings file. Then log into Dynamics again and the triggers should be enabled. Use the Automatic Debugger Mode Status window to confirm the triggers are active. Once installed it should remember size and position of the window. Then use the menu choice to adjust the pane ratios. David