Typical customer invoice scenario:
ObservableCollection in a viewmodel that holds LineItems. The view lists the LineItems with a calculated LineTotal shown at the end of each line. The, there's a GrandTotal shown at the bottom of the page.
If the user makes a change to Qty, to update other items on the page, I use an EventToCommand trigger on a TextBox that is bound to the Qty. When the command is invoked, I manually recalculate line totals and invoice totals to reflect changes.
Is there a better way to reflect changes made by the user to the Qty boxes? A way to force "rebinding" to refresh the page? Is there anything in Fody or Catel that handles this?
Got It! I still use the EventtoCommand to fire a command in the viewmodel which calls base.RaisePropertyChanged("CurrentInvoice"). Then, anything bound to CurrentInvoice will be refreshed.
If there are nested viewmodels, send a message to the level of the property and then call base.RaisePropertyChanged("PropertyName").
Related
In theory what I want to achive is pretty simple:
You choose an item from a sap.m.select which is a category.
This effects which items can be selected in a second sap.m.select that contain items that still need to be requested from a backend system.
On choosing one of the items in the second sap.m.select, a backend request for the full information of the choosen item should be triggert.
This works so far as long is I change the item in the second sap.m.select manually.
But if I choose a category this applys a Filter to the model that is the source for the second sap.m.select.
The problem is: there is no change triggert when the filter is done an thus the current item of the second changed (because one item can only have one category).
I already tried a few things, starting with manually fireing the change event of the second select as soon as I it filter. But all solutions so far did not achieve what I had planned.
(in the example of the manuall fired event after the model for the second select is filtered, the selected item of the second sap.m.select is not yet set. I need that item to know which item to query)
I only have some hacky solutions remaining, like some delay for firing the change event or modifing the handler of the change event to check the model, and the filter, for the first entry and query this in case the selected item of my sap.m.select is not yet set.
But is there nothing like an onBindingUpdated handler or something like this?
How do I cause APEX to refresh a chart (graph) after I change the value in a text box/select list/etc that is used as a parameter in the chart's pl/sql statement?
I'd like it to look as professional as possible and minimize the portion of the page that must be refreshed (i.e., "ajax-like", which is the standard in 2018).
Create a dynamic action on the text box/select list/etc that is changed with event "change"
Create a true action and select pl/sql and write
Begin
null;
end;
In page items to submit select your items
Create a second true action after the first and select Refresh. Then select region as affected element and select your chart. Remember that the option 'Fire on initialization' must be set to NO
See Approach B, below, for the optimal solution.
Approach A
The simplest option (that is less professional) is to modify every text box/select list/etc of interest to submit the page when the value of the text box/select list/etc changes. As an example, for the select list, go to its settings->page action on selection and change the setting to submit page.
There are two main downsides to that approach:
Most of the page will refresh, which is jarring to your user, and
If you're using a plugin, or the type of item that you're using doesn't support that approach, then you're out of luck.
Approach B
A more complex solution that yields a more professional result follows. This solution involves dynamic actions, which I will probably not fully explain here. However, the information should be enough for the user to figure it out.
Let us suppose that you have two things: (1) a select list whose value is used as a parameter in a (2) chart's sql source statement.
To get the chart to update every time you make a new choice via the select list, you need to:
Create a dynamic action for the select list of interest. You do this by clicking on the select list, going to the dynamic action tab (the lightning bolt); right-click on the item; click select dynamic action; give it a name and set the event to change and make the selection type an item and set the item to the name of the select list you're watching.
Create a true action for that dynamic action that executes pl/sql code (you can do this by modifying the show action that was created by default in 1.). Set the pl/sql code to null;. Then under items to submit, specify the name of the select list of interest.
Create a second true action that refreshes the region that contains the chart.
You'll need to make sure that the sequence assigned to 2. is a smaller number than the sequence assigned to 3.. This should happen by default, but it's an area you can get tripped up.
Inapplicable Approach C
In Apex 5.something, they added a feature called Cascading List of Values. This feature allows you to specify that one item depends on another item for its values. For example, if you have a select list that allows the user to choose a department, and then you have a second select list that allows you to choose an employee from the chosen department (which presumably obtains its values from a query involving the value chosen in the first select list), you can tell APEX to refresh the second select list whenever you update the first.
You do this by editing the second select list. Under its settings goto list of values->cascading LOV parent item(s). Add the first select list as a "reverse" dependent (aka, "parent"). This will ensure that any time the first select list is updated, the second select list is also updated.
For better or for worse, charts do not have the cascading LOV parent item(s) setting. Thus, this solution does not apply to this question.
A computed field in a tree view is not updating after returning from editing values for the line using a form view pop-up. (after the child has been saved/returning from the pop-up, but before the parent record is saved)
To give an example: add a new computed field to Sales Order Lines and then add the computed field into the Sale Order's 'ORDER LINES' tab (which itself is a tree view within the Sale Order Form). Then adjust the Sale Order Form so that editing of the Sale Order Lines is done via a form (i.e. pop-up) (rather than editing the lines within the tree, disable editable='bottom')
After testing it appears that the computed fields method is being run within the form view, the value should be updating.
The display on the line (tree view) should display the new value after returning from the pop-up, however it is not (still displays old value). (this does correctly update after the parent is saved)
This is working for other existing fields (e.g. price) which is displaying the new value on the line (tree view) after editing that value within the pop-up (before the parent is saved).
Why is the computed field showing the old value?
Try to add #api.depends('any_field_name') above compute function, it should solve your issue.
Odoo has bug about computed fields described in this issue that it doesn't computes computed fields without dependencies.
Let me know if my solution will work for you.
It appears that because the computed field was not on the form view (pop-up), even though the compute function was executing, the value on the line view after returning from the form was not updating (before a parent save).
After I added the computed field (invisible=1) to the form view (pop-up), the line view was successfully updated on return.
I do not know why, but am guessing that this is to do with cache or api. It may be possible that the line values are being updated by value returns from the form view (unsure about this), and therefore if the field in question is not on the form view then it is not being returned, and the line is remaining with the previous value.
I develop small database which gets bigger every day and I've got a situation with Before Update Event on one field.
Let's say I have main form which has subform based on the table (PONSt). The subform has one specific field (PONSt_PDV) which data depends on the other table (APP_PDV). When user updates that field (PONSt_PDV) directly in combo box, Before Update events is triggered and some calculations are done. That works perfectly!
The second situation (which is the reason for this question) is when user double clicks that combo box to open pop up form which contains the data from the other table (APP_PDV). In that pop up form user can edit, add or delete it's data and everything works great. There is a button on that pop up form which is used to get data (ID) from that table (APP_PDV), store it to the first table's field (PONSt_PDV), close the pop up form and get back to the first form (sub form on the first form, to be exact). After that, I want to recalculate other fields (in the first table PONSt) depending on the change in field (PONSt_PDV), but Before Update (or After Update) event in that case doesn't trigger at all.
What I'm doing wrong? Is there something that I can't see? Thanks!
This might be simple but I am new to Oracle. I am using Oracle 10g and have a form that lists our information from a linked table in a tabular Layout. The last column of data is a "list Item" item type that has the Element list of Enabled (T) and Disabled (F).
What I need is when a user changes this dropdown, to disabled, I want ONLY that row to have some of the columns be disabled and not the entire column.
This is also assuming on load of the form, it will disable and enable rows of data depending on what values are being pulled from the EnabledDisabled column in the database.
Thanks for the help!
Option 1: use the ENABLED item property.
Unfortunately Oracle Forms does not allow changing the ENABLED property of an item at the item instance level.
What you can do, however, is enable or disable the whole item when the user enters a record - use the WHEN-NEW-RECORD-INSTANCE trigger - depending on the value of the current record's value for the list item, the trigger would set the ENABLED property to PROPERTY_TRUE or PROPERTY_FALSE.
Of course, your list item would also have the same code in its WHEN-LIST-CHANGED trigger.
The downside to this approach is that the whole column will "look" disabled to the user, and they will not be able to select a different record using those disabled items.
Option 2: use the INSERT_ALLOWED and UPDATE_ALLOWED properties.
You can set these properties at the item instance level using SET_ITEM_INSTANCE_PROPERTY. You would set them in the block's POST-QUERY trigger, as well as in the list item's WHEN-LIST-CHANGED trigger.
This would not, however, change how the items look on the screen. To solve this, you could also set a visual attribute at the item instance level (e.g. change the items to use a dark gray background or something).
More comments.