The "From Date" and "To Date" fields have been added to the "Process" screen, automatically populating the date range from the current date minus three days. This is working as expected.
When we select a specific date range, it resets to the default dates and retrieves data only within the default date range. Below is the screen shots for DAC and Events.
Could any one please suggest a solution
Best answer by darylbowman
Here’s an example of a data view and data view delegate. For complex filtering conditions, it can be helpful to use a data view delegate to simplify the logic a bit. This is optional. It can be written into the data view as well. This is also written in F-BQL.
[PXFilterable]
public SelectFrom<DAC>.
LeftJoin<OtherDAC>.
On<DAC.FK.Something>.
OrderBy<DAC.date.Asc>.
ProcessingView.FilteredBy<Filter> Lines;
protected virtual IEnumerable lines()
{
var select = new SelectFrom<DAC>.
LeftJoin<OtherDAC>.
On<DAC.FK.Something>.
OrderBy<DAC.date.Asc>.
View(this);
// Begin filtering
select.WhereAnd<Where<DAC.fieldOne.StartsWith<example>>>();
var filter = Filter.Current;
if (filter is object)
{
if (filter.Date.HasValue)
select.WhereAnd<Where<DAC.date.IsGreaterEqual<Filter.startDateTime.FromCurrent>>>();
if (filter.EndDateTime.HasValue)
select.WhereAnd<Where<DAC.date.IsLessEqual<Filter.endDateTime.FromCurrent>>>();
if (filter.Action == "D")
{
select.WhereAnd<Where<DAC.fieldTwo.IsEqual<True>>>();
}
}
if (filter.LimitResults ?? false)
return select.SelectWindowed(0, 200);
else
return select.Select();
}
+13Are you saying the date fields actually change their values?
yes, For example, when we select the date range from March 1st to March 15th, the data is only retrieved for the default date range (March 29th to April 1st).
+13Ok, but you’re making it sound like the date values are not being reverted. They’re just not being respected, correct?
In that case, I would bet a large sum you forgot to set CommitChanges = true on the date filter fields.
+13I don't see your data view. How are you using the filter?
+13That's your problem. You need to write the conditions into the data view like you would normally.
I can post an example in a few hours.
+13Here’s an example of a data view and data view delegate. For complex filtering conditions, it can be helpful to use a data view delegate to simplify the logic a bit. This is optional. It can be written into the data view as well. This is also written in F-BQL.
[PXFilterable]
public SelectFrom<DAC>.
LeftJoin<OtherDAC>.
On<DAC.FK.Something>.
OrderBy<DAC.date.Asc>.
ProcessingView.FilteredBy<Filter> Lines;
protected virtual IEnumerable lines()
{
var select = new SelectFrom<DAC>.
LeftJoin<OtherDAC>.
On<DAC.FK.Something>.
OrderBy<DAC.date.Asc>.
View(this);
// Begin filtering
select.WhereAnd<Where<DAC.fieldOne.StartsWith<example>>>();
var filter = Filter.Current;
if (filter is object)
{
if (filter.Date.HasValue)
select.WhereAnd<Where<DAC.date.IsGreaterEqual<Filter.startDateTime.FromCurrent>>>();
if (filter.EndDateTime.HasValue)
select.WhereAnd<Where<DAC.date.IsLessEqual<Filter.endDateTime.FromCurrent>>>();
if (filter.Action == "D")
{
select.WhereAnd<Where<DAC.fieldTwo.IsEqual<True>>>();
}
}
if (filter.LimitResults ?? false)
return select.SelectWindowed(0, 200);
else
return select.Select();
}
+1Hello
There are a few things you should definitely avoid when working with LongOperations — or, in your case, with processing screens that run asynchronously on a different thread.
So let’s go through them one by one, without getting a headache.
When you want to add default values to fields in Acumatica, never use the constructor or RowSelected for that. You already have an event called FieldDefaulting, and it works perfectly for this purpose. It assigns a value to the field once when it loads.
For your filter, you can either:
Keep individual FieldDefaulting events for each field in a graph, or
(My preferred way) Create a custom attribute that inherits from PXEventSubscriberAttribute and implements IPXFieldDefaulting. Then, write your logic inside that and attach the attribute directly to your field in the Filter DAC.
This second option is great if you plan to reuse the same DAC in other graphs, or the same defaulting for other fields, so you don't repeat code.
If you're using the Acuminator extension for Visual Studio, you might have already seen a warning — PX1008. In short, it means you should not use this in asynchronous processes like this.Filter.Current.
Why? Because you're referencing the current instance of the C# class (this), which may not behave predictably in async processing. Instead, make your PrepareAndExportRecords method static and pass all necessary data into it explicitly. That way, you'll also clearly see where you're depending on this.
Since you already have FieldDefaulting events, you no longer need to assign values to the filter fields manually.
If your filter is only used for simple data filtering and you won’t need the filter values later in code, you can just modify the view’s BQL query and use the delegate view as
However, if you plan to use your filter later in complex C# logic (outside of BQL), I recommend moving your delegate assignment from the constructor to the RowSelected event of your filter DAC. Just before setting the process delegate, capture the filter like this:
public virtual void _(Events.RowSelected<ShopifyFiltersync> e)
{
ShopifyFiltersync filter = Filter.Current;
GetShopifyOrderDetails.SetProcessDelegate((List<NAWShopifySetup> list) =>
PrepareAndExportRecords(filter, list));
}Follow these steps and I’m sure your problem will be solved.
Feel free to ask anything else — I'm happy to help!
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
