DAX 4.0 Filter by Grid [Update]
Well take a look at this:
"bskiles has left a new comment on your post "Filter by Grid in DAX 4.0":
I [bskiles] was trying to figure out how to turn the "Filter by Grid" on in code, and I figured it out. Call the .task method on the form with a parameter of 2855 after the grid is selected. Anything that extends FormRun can make the call to .task(2855). Unfortunately, I can't trace it back up to FormRun since that's a system object.
I'm still interested in learning how it actually works so that I can set it up as a user setting per grid. "
It's a comment from my blog entry here: Filter by Grid - Older Post bskiles took the time and was able to find how to actually call the Filter by Grid from code! Very nice work! It's strange that it's such a hidden event / call? Anyway just wanted to report this find, thanks bskiles!
Find a job at: www.DynamicsAXJobs.com
"bskiles has left a new comment on your post "Filter by Grid in DAX 4.0":
I [bskiles] was trying to figure out how to turn the "Filter by Grid" on in code, and I figured it out. Call the .task method on the form with a parameter of 2855 after the grid is selected. Anything that extends FormRun can make the call to .task(2855). Unfortunately, I can't trace it back up to FormRun since that's a system object.
I'm still interested in learning how it actually works so that I can set it up as a user setting per grid. "
It's a comment from my blog entry here: Filter by Grid - Older Post bskiles took the time and was able to find how to actually call the Filter by Grid from code! Very nice work! It's strange that it's such a hidden event / call? Anyway just wanted to report this find, thanks bskiles!
Find a job at: www.DynamicsAXJobs.com
Labels: 2855, Dynamics AX, Filter, Filter By Grid, FormRun, task, X++
posted by brandon | 6:51 AM
10 Comments:
Nice find :)
Just tried this myself though and have tried a couple of different places for the call to .task(2855) and no joy :(
My scenario is a form launched when creating a new record (so just like creating a new sales order). In the forms run event, I call lookup on my main field to show it's search popup. In a live environment my users will always need the help of the filter to find the record they're after so this feature would be very nice to automate the filter rather than clicking the toolbar icon each time. (further ideas involve turning this on for all grids in the system or storing per user whether to have it on or off per grid like bskiles is hoping to do).
Any chance either yourself or bskiles could follow up with a short example? Thanks
Chris Rothery, UK
Sorry for the delay in responding, I got busy and didn't get a chance to follow up for a while.
Here is a quick example for the form PurchTable. I put the code at the end of the Run method. The grid "Grid" needs to be set to autodeclaration = true.
Grid.enter();
this.task(2855);
And that's it!
Unfortunately, that doesn't help much if you wish to implement this system-wide, which is what I would like to do.
SysSetupFormRun seems like the correct place to set this up. I've overriden the "Run" method. So far the code looks something like this:
void run() {
super();
// insert good code here!
// find a grid to enter!
this.task(2855);
}
There is a major problem with this code, though! In some cases the call to task causes Axapta to crash. For some users it happens for every form. I haven't yet found the root cause. If you manage to fix the crash problem, please share! I suspect that my code to find and enter a grid is failing.
Here's the full run method for PurchTable, just for some context.
void run()
{
super();
if (!advanced)
tabHeader.tab(2);
else
tabHeader.tab(1);
Grid.enter();
this.task(2855);
}
Sweet. Thanks :)
I initially had that PurchTable crash Dynamics on me so I broke it down to see which of the two lines was causing the grief (and hopefully why).
When the form loads as 'simple', the grid is not visible but the Grid.enter() shows it in a skeleton form (just the outline). If this happens, the this.task... line crashes AX. This might be a pointer as to why it sometimes crashes elsewhere.
So far (in 20 mins of playing!), the following run method is stable however I leave the form:
void run()
{
super();
if (!advanced)
tabHeader.tab(2);
else
{
tabHeader.tab(1);
Grid.enter();
this.task(2855);
}
}
(extra code also required though when the overview tab becomes the current tab as changing from simple to advanced doesn't show the filter).
One of my longterm goals is to get the filter to show on an automatic lookup grid. If I manage that or anything else in this area I'll post back.
I'm definitely interested in hearing anything you learn on this crazy behavior. It's just amazing that we can make such a simple call that can either crash AX or make the users think we are awesome.
I'll continue to explore and post my progress.
New and Improved!
Here is the source code for my latest attempt. I simply turn on the "filter by grid" for the first visible grid on the form. Someone could probably spend some time to make it a configurable option per form, but that's left as an exercise to the person who would like to do that. I've not received a crash in my testing thus far.
I've modified the SysSetupFormRun class. I overrode the method Run and added two other methods to find the top-level grid. FindGrid has some room for improvement. I'd hoped to use a FormBuildControl and the IsContainer method to handle iteration, but couldn't figure that one out. The documentation is a bit sparse. I'm interested in seeing any improvements people make to this bit of code.
Upon preview, it appears that my nice indentation is stripped out. I really did indent my code in a sane way!
public void run()
{
super();
if (this.FindTopmostGrid()) {
this.task(2855);
}
}
private boolean FindTopmostGrid()
{
FormControl fc;
int i;
;
for (i=1;i<=this.design().controlCount();i++) {
fc = this.design().controlNum(i);
if (this.FindGrid(fc)) {
return true;
}
}
return false;
}
private boolean FindGrid(FormControl fc)
{
FormGridControl fgrc;
FormGroupControl fgc;
FormTabControl ftc;
FormTabPageControl ftpc;
str controlStr;
int i;
;
// check to see what kind of control it is
controlStr = fc.toString();
if (string::contains(controlStr, "FormGridControl")) {
if (fc.visible()) {
fgrc = fc;
fgrc.enter();
return true;
}
} else if (string::contains(controlStr, "FormGroupControl")) {
fgc = fc;
for (i=1;i<=fgc.controlCount();i++) {
if (this.FindGrid(fgc.controlNum(i))) {
return true;
}
}
} else if (string::contains(controlStr, "FormTabControl")) {
ftc = fc;
for (i=1;i<=ftc.controlCount();i++) {
if (this.FindGrid(ftc.controlNum(i))) {
return true;
}
}
} else if (string::contains(controlStr, "FormTabPageControl")) {
ftpc = fc;
for (i=1;i<=ftpc.controlCount();i++) {
if (this.FindGrid(ftpc.controlNum(i))) {
return true;
}
}
}
return false;
}
Well, back to the drawing board. The entire Thy:Service and Maintenance module does NOT work with this code. Also, some bits of the project module don't. Most other things seem find, though.
Hi, I found this topic from Google and I'm little bit late...but still I have a question. Do you think it's possible to change which filter type is used by default? I'd like to use 'contains' type by default. Thanks for answering.
just a comment about the Filter by Grid feature. it seems to cause a performance problem on those grids which have significant amount of data. the grid seems to refresh several times when you move from one row to another.
Has anyone noticed this performance hit?
Glad i found this post! Maybe someone knows how to code to turn filter by grid on in lookup form which automatically pops out in certain column?
Post a Comment
<< Home