I'm upgrading a customization project from version 5.3.2936 to version 6.10.0755. I've run into an attribute: [PXNotPersistable] which, apparently, no longer exists. I don't know what this attribute does or if there is a replacement. It's used to decorate a PXSselectJoin BQL statement. Any help would be appreciated.
The PXNotPersistable attribute was completely removed from the Acumatica Framework mostly because it was not used anywhere inside Acumatica ERP solution.
Below is the implementation of PXNotPersistableAttribute:
public sealed class PXNotPersistableAttribute : PXCacheExtensionAttribute
{
protected override void AddHandlers(PXCache cache)
{
cache.RowPersisting += (sender, args) => args.Cancel = true;
}
}
As you might notice, the attribute was quite basic and didn't do much: only prevented modified records of the main data view DAC from beings saved to a database.
Say, you have a custom data view declared as follows for ver. 5.3:
[PXNotPersistable]
public PXSelectJoin<MyDacA,
LeftJoin<MyDacB, On<MyDacB.someField, Equal<MyDacA.someField>>>> DataView;
For ver. 6.1, PXNotPersistableAttribute can be simply replaced with the MyDacA_RowPersisting handler (since MyDacA is the main DAC for our data view and only changes made to this DAC will be saved to a database):
public void MyDacA_RowPersisting(PXCache sender, PXRowPersistingEventArgs e)
{
e.Cancel = true;
}
Related
I am trying to enable the custom field in Case when the Status is in Closed State. I am working on a customization for Acumatica version 20.114.0020 (2020 R1).
I have created a custom field usrIsNotBillable in CRCase DAC.
[PXDBBool]
[PXUIField(DisplayName="Confirmed Not Billable", Enabled = true)]
public virtual bool? UsrIsNotBillable { get; set; }
public abstract class usrIsNotBillable : PX.Data.BQL.BqlBool.Field<usrIsNotBillable> { }
It is totally working fine when the Case is in other states than Closed. But when the case is closed, every other property gets disabled. But I want this field to be set enabled. So, I override the Row Selected method for CRCaseMaint graph as below:
protected void CRCase_RowSelected(PXCache cache, PXRowSelectedEventArgs e, PXRowSelected InvokeBaseHandler)
{
InvokeBaseHandler?.Invoke(cache, e);
CRCase row = (CRCase) e.Row;
if (row == null) return;
Base.CaseCurrent.Cache.AllowUpdate = true;
Base.CaseCurrent.AllowUpdate = true;
PXUIFieldAttribute.SetEnabled<CRCaseExt.usrIsNotBillable>(cache, row, true);
}
If I use other DAC fields such as IsBillable like this:
PXUIFieldAttribute.SetEnabled<CRCase.isBillable>(cache, row, true);
It just works fine.
I checked other examples too and the implementation is similar to this. I am just not sure why it is not working in this case.
I have also checked if this screen has any existing workflows and it doesn't.
Any help would be appreciated.
Thanks.
Besides writing code to enable the field in RowSelected event, it is also important to add the field in Closed state in the Workflow.
However, if this is also not working deleting contents of CstDesigner of project does the job.
I've been tasked with adding the default vendor inventory ID to grids in multiple screens in Acumatica. The field does not need to be bound and is disabled. I've gotten it as far as showing the field correctly, but only on saved records. Adding a new line and even refreshing the grid will not display the ID, I have to close the screen or switch to another record and come back before the vendor ID will display, even clicking the save button and refreshing will not cause it show. The client is using this field as a reference point so it's important it shows as soon as they select an item.
Below is the code I have for the Kit Specification screen, I need to figure out a way to make it a little more reactive, at least show properly on a refresh. I have tried using Current<> in the where statement, but that just breaks it entirely and always shows nothing.
public class INKitSpecStkDetExt : PXCacheExtension<PX.Objects.IN.INKitSpecStkDet>
{
#region VendorInventoryCode
public abstract class vendorInventoryCode: IBqlField { }
[PXDBScalar(typeof(Search2<PO.POVendorInventory.vendorInventoryID,
InnerJoin<IN.InventoryItem,
On<PO.POVendorInventory.vendorID, Equal<IN.InventoryItem.preferredVendorID>, And<PO.POVendorInventory.inventoryID, Equal<IN.InventoryItem.inventoryID>>>>,
Where<IN.InventoryItem.inventoryID,Equal<IN.INKitSpecStkDet.compInventoryID>>,
OrderBy<Desc<PO.POVendorInventory.vendorInventoryID>>>))]
[PXString(40, IsUnicode = true)]
[PXUIField(DisplayName = "Vendor Inventory Code", Enabled=false)]
public string VendorInventoryCode{ get; set; }
#endregion
}
Once I have the code nailed down it will be used in several other places. Help very much appreciated! Frustrating to have it so close and not be able to cross the finish line...
Follow up based on feedback from HB_Acumatica, working code is below for reference:
public void INKitSpecStkDet_VendorInventoryCode_FieldSelecting(PXCache sender, PXFieldSelectingEventArgs e)
{
var row = e.Row as INKitSpecStkDet;
if (e.Row != null)
{
PO.POVendorInventory vendorInventory = PXSelectReadonly2<PO.POVendorInventory,
InnerJoin<IN.InventoryItem,
On<PO.POVendorInventory.vendorID, Equal<IN.InventoryItem.preferredVendorID>, And<PO.POVendorInventory.inventoryID, Equal<IN.InventoryItem.inventoryID>>>>,
Where<IN.InventoryItem.inventoryID, Equal<Required<IN.INKitSpecStkDet.compInventoryID>>>,
OrderBy<Desc<PO.POVendorInventory.vendorInventoryID>>>.Select(Base, row.CompInventoryID);
e.ReturnValue = vendorInventory != null ? vendorInventory.VendorInventoryID : null;
}
}
PXDBScalar attribute doesn't refresh by itself. Maybe explicitly calling RaiseFieldDefaulting method will refresh it:
object newValue = null;
base.Caches[typeof(INKitSpecStkDet)].RaiseFieldDefaulting<INKitSpecStkDetExt.vendorInventoryCode>(rowINKitSpecStkDet, out newValue);
Using PXFormula instead of PXDBScalar if possible will yield better automatic refresh behavior but has it's own set of limitation as well.
If you're looking for the simplest way that works in most contexts (except when no graph is used like in reports and generic inquiry) that would be the FieldSelecting event.
You can execute BQL and return any desired value from the event. It will be called each time the field is referenced so it should update by itself.
public void INKitSpecStkDet_VendorInventoryCode_FieldSelecting(PXCache sender, PXFieldSelectingEventArgs e)
{
PO.POVendorInventory vendorInventory = PXSelectReadonly2<Po.POVendorInventory […]>.Select(Base);
e.ReturnValue = vendorInventory != null ? vendorInventory.VendorInventoryCode : null;
}
In a cross platform Xamarin app built with the MvvmCross framework I'm using a ToggleButton Widget in an Android .axml layout. I've bound the Checked property to a View Model property using a converter using the following binding syntax:
Checked MarketBuySellViewModel.Direction, Converter=DirectionBool, ConverterParameter='Sell'
Everything works well. On the iOS side, it appears you can use UIButton as a ToggleButton by using the Selected property. This implies that the following binding should achieve what I want on iOS:
set.Bind (SellButton).For(b => b.Selected).To (vm => vm.MarketBuySellViewModel.Direction).WithConversion("DirectionBool", "Sell");
I don't get any binding errors in the application output but the binding itself doesn't seem to work. Clicking the button doesn't set the Direction property and setting the direction to a different value does not set the Selected property on the UIButton.
Do I need to create a Custom Binding or am I simply setting up the binding incorrectly?
I also tried using a UISegmentedControl to achieve the same effect. Is binding to this control supported at all in MvvmCross? I don't see any reference to it in the source code. Does this mean I need to create custom bindings for it too?
For the UIButton, I don't believe there's any included Selected binding built into MvvmCross. Because of this - and because Selected doesn't have a simple paired event SelectedChanged, then I believe Selected binding should work one-way (from ViewModel to View) but not two-way.
There is a binding for the On of a UISwitch control and that's the control I've seen used most in these situations.
If you wanted to add a custom 2-way binding for Selected then I guess you'd have to do this using the ValueChanged event (but would need to check that is correct).
To do so, you'd just build a target binding something like:
public class MvxUIButtonSelectedTargetBinding : MvxPropertyInfoTargetBinding<UIButton>
{
public MvxUIButtonSelectedTargetBinding(object target, PropertyInfo targetPropertyInfo)
: base(target, targetPropertyInfo)
{
var view = View;
view.ValueChanged += HandleValueChanged;
}
private void HandleValueChanged(object sender, System.EventArgs e)
{
var view = View;
if (view == null)
return;
FireValueChanged(view.Selected);
}
public override MvxBindingMode DefaultMode
{
get { return MvxBindingMode.TwoWay; }
}
protected override void Dispose(bool isDisposing)
{
base.Dispose(isDisposing);
if (isDisposing)
{
var view = View;
if (view != null)
{
view.ValueChanged -= HandleValueChanged;
}
}
}
}
and this could be registered in Setup in protected override void FillTargetFactories(IMvxTargetBindingFactoryRegistry registry) using something like:
registry.RegisterPropertyInfoBindingFactory(typeof(MvxUIButtonSelectedTargetBinding), typeof(UIButton),
"Selected");
Similarly, I don't believe anyone has added a two way UISegmentedControl binding yet - but would happily see one added.
Building a two way UISegmentedControl binding would be quite straight-forward - you'd just have to bind to the pair SelectedSegment and ValueChanged - with code similar to above.
Alternatively, you could switch to using a custom MySegmentedControl which had a nicer Value`ValueChanged` pair which would automatically work without a custom binding - e.g.:
public class MySegmentedControl : UISegmentedControl
{
// add more constructors if required
public int Value
{
get { return base.SelectedSegment; }
set { base.SelectedSegment = value; }
}
}
If any or all of these custom bindings are needed, then the Mvx project is happy to get these bindings added as issues or pull requests along with test/demo UIs in the https://github.com/slodge/MvvmCross-Tutorials/blob/master/ApiExamples/ApiExamples.Touch/Views/FirstView.cs project
Could be helpful to someone else, so i'm sharing my experience. I needed a two way binding for UISegmentedControl.SelectedSegment property to a ViewModel. The one way biding (ViewModel => View) works by default. I couldn't able to properly utilize the solution proposed by Stuart - to subclass the UISegmentedControl. I tried to ensure that the linker does not rip off the new custom control code, but this didn't help me a bit. So a perfectly viable solution is the one with MvxPropertyInfoTargetBinding. Here is the code working ok for me:
public class MvxUISegmentedControlSelectedSegmentTargetBinding : MvxPropertyInfoTargetBinding<UISegmentedControl>
{
public MvxUISegmentedControlSelectedSegmentTargetBinding(object target, PropertyInfo targetPropertyInfo)
: base(target, targetPropertyInfo)
{
this.View.ValueChanged += HandleValueChanged;
}
private void HandleValueChanged(object sender, System.EventArgs e)
{
var view = this.View;
if (view == null)
{
return;
}
FireValueChanged(view.SelectedSegment);
}
public override MvxBindingMode DefaultMode
{
get { return MvxBindingMode.TwoWay; }
}
protected override void Dispose(bool isDisposing)
{
base.Dispose(isDisposing);
if (isDisposing)
{
var view = this.View;
if (view != null)
{
view.ValueChanged -= HandleValueChanged;
}
}
}
}
public class Setup : MvxTouchSetup
{
...
protected override void FillTargetFactories(IMvxTargetBindingFactoryRegistry registry)
{
registry.RegisterPropertyInfoBindingFactory(typeof(MvxUISegmentedControlSelectedSegmentTargetBinding), typeof(UISegmentedControl), "SelectedSegment");
}
}
There seems to be something holding a reference to my custom button, MyButton (which inherits from UIButton), causing it not to be garbage collected unless I remove it from the superview. This, in turn, would cause the view controller that it is on to also not be finalized and collected.
In my example, I have my custom button but I also have a standard UIButton on the view controller which does not need to be removed from the superview in order to be collected. What's the difference? Looks pretty similar to me.
See this code. The irrelevant lines were removed for example's sake. Some things to note about the sample:
-MyButton is pretty empty. Just a constructor and nothing else overridden.
-Imagine MyViewController being on a UINavigationController
-LoadView() just creates the buttons, hooks up an event for each and adds it to the view
-Touching _button would push another MyViewController to the nav controller
-I'm doing some reference cleanup when popping view controllers off the nav controller in ViewDidAppear()
-In CleanUpRefs() you'll see that I have to remove _myButton from superview in order for all the objects to be garbage collected. _button, on the other hand does not need to be removed.
-I'm expecting the entire MyViewController to be collected, including all subviews, when popping from the nav controller but commenting out _myButton.RemoveFromSuperview() stops this from happening.
public class MyViewController : UIViewController
{
private UIButton _button;
private MyButton _myButton;
private MyViewController _nextController;
public override void LoadView()
{
base.LoadView();
_button = UIButton.FromType(UIButtonType.RoundedRect);
_button.TouchUpInside += PushNewController;
View.AddSubview(_button);
_myButton = new MyButton();
_myButton.TouchUpInside += MyButtonTouched;
View.AddSubview(_myButton);
}
private void PushNewController(object sender, EventArgs e)
{
_nextController = new MyViewController();
NavigationController.PushViewController(_nextController, true);
}
private void MyButtonTouched(object sender, EventArgs e)
{
Console.WriteLine("MyButton touched");
}
public void CleanUpRefs()
{
//_button.RemoveFromSuperview();
_myButton.RemoveFromSuperview();
// remove reference from hooking up event handler
_button.TouchUpInside -= PushNewController;
_myButton.TouchUpInside -= MyButtonTouched;
_button = null;
_myButton = null;
}
public override void ViewDidAppear(bool animated)
{
base.ViewDidAppear(animated);
if(_nextController != null)
{
_nextController.CleanUpRefs();
_nextController = null;
}
}
}
It seems as if there's something different with the fact that MyButton isn't a straight UIButton in that it is inherited. But then again, why would there be an extra reference count to it that's being removed by calling RemoveFromSuperview() especially when there's a UIButton just like it that doesn't need to be removed?
(I apologize for the really bad layout, stackoverflow seems to have problems laying out bullets right above code snippets)
Update: I filed a bug report with the MonoTouch team. You can download the sample project from there if you want to run it. Bug 92.
The reason for not garbage collecting in that scenario is just a bug in MonoTouch.
The upcoming MonoTouch release will contain a fix for this. If you are in a hurry, you can replace your /Developer/MonoTouch/usr/lib/mono/2.1/monotouch.dll with the copy I placed here:
http://tirania.org/tmp/monotouch.dll
I would make a backup, in case I did something wrong in my work-in-progress library.
I'm writing a custom module for DNN 5, and I need a "Manage" link to be on every control in the module. I created a new UserControl ("ManagerLink") that inherits from PortalModuleBase, put my link into that control, and dropped that control on ALL OF MY MAIN CONTROLS.
The problem is that ModuleId and TabId are always -1 in "ManagerLink" nested control. PortalId works just fine, and I can get a TabId by doing PortalSettings.ActiveTab.TabID.
Why can't I get ModuleId and TabId in from "ManagerLink" control, even though it inherits from PortalModuleBase?
Is there an alternative method to get ModuleId (equivalent of PortalSettings.ActiveTab.TabID)
UPDATE 2014:
Just saw another answer that's way better than the original (and accepted it).
If you're using DNN 6 and earlier, replace ModuleBase with PortalModuleBase
William Severance from DNN forum answered this one for me, I'll post the answer here as well.
Since the child control inherits from PortalModuleBase, I would do the
following in the Page_Load handler of
the parent control
Note: ManagerLink is assumed to be a reference to the child control
VB.NET:
With ManagerLink
.ModuleConfiguration = Me.ModuleConfiguration
.LocalResourceFile = Me.LocalResourceFile
End With
C#:
protected void Page_Load(System.Object sender, System.EventArgs e)
{
ManagerLink.ModuleConfiguration = this.ModuleConfiguration;
ManagerLink.LocalResourceFile = this.LocalResourceFile
}
The above allows the child control to use the parent's ModuleConfiguration (which will include ModuleId) and LocalResourceFile for any localization.
I just wanted to add my 2 cents here, using the answer of #roman-m and extending on it,
I was able to do it in the nested control itself like so:
//fires first in the sequence, calling initialise components
override protected void OnInit(EventArgs e)
{
InitializeComponent();
base.OnInit(e);
}
private void InitializeComponent()
{
this.Load += new System.EventHandler(this.Page_Load);
//this binds a handler to the parent's init event
this.Parent.Init += new EventHandler(this.Parent_Init);
}
//the handler gets called, at this point we can cast the parent as a module base
//and load the configuration and resource file into the nested control
private void Parent_Init(object sender, System.EventArgs e)
{
this.ModuleConfiguration = ((ModuleBase)this.Parent).ModuleConfiguration;
this.LocalResourceFile = ((ModuleBase)this.Parent).LocalResourceFile;
}
This means that in the Page_Load event of the nested control it will already have the configuration and local resource file on hand.
It also means you don't have to load the configuration and local resource file in on every parent control which uses the child control.
This will only work when the parent is of type ModuleBase of course
And to be even more specific, this works in version 7.00.06