I have a recalc function on one of my client scripts that's deployed on Sales Orders. By definition, the recalc client event should only fire "after a sublist change, but only if the sublist change causes the total to change"; however, I've found that this is not the case. Simply clicking on a line item and then clicking the blue "OK" button is causing my recalc function to fire. Simply selecting an item and subsequently clicking "OK" does not cause any totals to change, thus it shouldn't be causing the recalc function to fire, correct? Why is this happening and how do I fix it?
The behavior you are describing is intended by NetSuite - their "change" and your "change" don't necessarily mean the same thing. Even though you didn't necessarily change anything on the line, NS's UI is dumb to that and knows that you could have, so they recalc anyway.
Unfortunately, I don't think there is a way for you to get around this.
I assume you have a script running on recalc that takes too long and you'd like to speed things up, so perhaps there's a way to look at that script instead and refactor it to perform better?
If you are just checking if the line item changes. You can use a line init function that stores the existing line item id in global variable. Then on validate line, get the line item and check it against the global variable.
Related
Is there a field that exposes WHEN a work item is assigned to its current iteration?
Seems like a pretty basic thing one might like to know, but I can't seem to find it anywhere. Can someone point me in the right direction?
There is No field that exposes when a work item is assigned to its iteration.
If you want to see this value, you can go to the page of the work item.
And then click "History". What you need to find is the record of the latest iteration update.
Of course, you can also get this value through the REST API:
GET https://dev.azure.com/{organization}/{project}/_apis/wit/workItems/{id}/updates
But just like getting it by website, you need to spend some time looking for this value, and you can't apply it to queries.
If you really need a field that exposes when a work item is assigned to its iteration. You can create a new process that inherits from your current process and change the process of your project. Click this document for detailed steps.
And then, add a new field to show the latest updates of iteration. Click this document for detailed steps.
This way you can treat the iteration change time as a real field. However, the defect is that when you make changes to an iteration, you need to manually change the value of this field.
I've created a QTreeWidget that displays data that's pulled from 3rd party API calls.
I want the data to be fresh when the user either clicks on or uses the arrow keys to navigate to any QTreeWidgetItem. This means making an API call each time the user clicks or uses an arrow key. Importantly: If the user clicks on the same item a second time, I would like the item to display fresh data (in other words, make another API call and populate with new data, aka refresh)
So far, I've tried:
connecting both itemSelectionChanged and itemClicked to the same update function. This works, but it means that for every click on a new QTreeWidgetItem, I get two calls to the update function (one from itemClicked and the other from itemSelectionChanged), and therefore two API calls that do the exact same thing. Not ideal.
Only handling itemClicked, but then using an event filter to look for Key_Up or Key_Down and then manually emitting an itemClicked. The problem with this is that the key event is handled before the selection is changed, so when using the arrow keys, I'm always getting data for the last QTreeWidgetItem selected, not the current QTreeWidgetItem.
I thought about creating a very short timer or a flag and starting/setting at the start of the update function. If the timer is running or the flag is set, don't run the function (the idea being that the first slot would run, but the second would not because the flag is set/timer is running), but that seems both sloppy and prone to race conditions.
Unfortunately, using a QTreeView with a QAbstractItemModel is not an option.
With that, is there any way to handle both a repeated click on the same item and arrow keys to select new items without double-calling the same update function?
As #ekhumoro pointed out, this can be done by handling both itemClicked and itemSelectionChanged, but introducing some logic so that both functions don't run at the same time.
When a user clicks on the widget, an itemClicked signal is fired. When the user changes selection, the itemSelectionChanged signal is fired. In my case, then, I've created two slots (functions): update (a slot for itemSelectionChanged) and updateFromClick (a slot for itemClicked). updateFromClick checks to see if the selection has changed (this means you always have to store and keep track of the current selection). If, in updateFromClick, I see that the selection has changed, then I do nothing, as update will have been called from itemSelectionChanged. If, in updateFromClick, I see that the selection has not changed, I know that itemSelectionChanged has not been fired, so I call the update function explicitly from updateFromClick.
Again, this is just a long-winded version of #ekhumoro's comment that I'm putting here so the question doesn't go unanswered.
so we are facing this weird issue. There is a Customer list on the form which is of the type List/Record. On the basis of Customer selected in this list, I clear the transaction list on the child form using nlapiRemoveLineItem() call . Everything works well TILL the customer is selected properly in the customer list.
Now, lets say I just type customer name abc & it gets autopopulated without selecting it as such, in this case, the nlapiRemoveLineItem() on the other list fails miserably and simply adds new items in this list.
What is really happening here ? Can anyone help ?
Javascript runs asynchronously, which means if you call an event like loading the customer, the browser won't wait for the result to come back before it executes the next command, in this case the nlapiRemoveLineItem.
So the sequence of events that is happening goes:
Set the customer
Remove line items
Customer is loaded
Line items from customer are populated
And what you want is:
Set the customer
Customer is loaded
Line items from customer are populated
Remove line items
To achieve this you could either use a promise library like q (best way), make a while loop to wait for the customer to come back, or do it the lazy way and do a setTimeout and execute the line removal around the time you expect the customer to come back.
I'm working on a Lotusscript at the moment which places a menu of actions on the $Inbox (and thereby any folders derived from that design). This action menu has several items with "Hide action if formula is true" selected. The logic behind all of this works perfectly, however I now have the need to re-evaluate these formulas if the user performs certain actions within the folder (eg: if the action is hidden because a certain flag has been set, and that flag is changed I would then like to re-evaluate the formula so the action now appears). I can't seem to find any way to reload a folder or re-evaluate these formulas. Does anyone know of a way to do this?
There is a RefreshHideFormulas method for the NotesUIDocument, but not for a view. You may be able to call the ReloadWindow() method of NotesUIWorkspace, though, so that's worth a try.
As an alternative, triggering an agent that calls the #Command RefreshHideFormulas may also work for you:
Here is some code (borrowed from http://ideajam.net/ideajam/p/ij.nsf/0/3BBA7E25A972ABD88625759600445A50?OpenDocument)
1) Create an #Formula Agent called "RefreshActions", Agent List Trigger with the following code:
#SetTargetFrame("YourFrame");
#UpdateFormulaContext;
#Command([RefreshHideFormulas]);
2) In your Lotusscript, where you want to insert a "refresh frame" call, add this:
Dim agent As NotesAgent
Set agent = db.Getagent("RefreshActions")
Call agent.Run()
You can use property "Evaluate actions for every document change" found in view properties, [i] tab. Every selection (click, arrows) of document will trigger reevaluating hide whens for actions. Maybe it will work after refreshing view by some action.
I have a fairly straightforward and common use case. A panel, in which resides a repeat control. The repeat control gets its content from a view lookup by key. Below that repeat control is another panel. This panel has a data binding to a new notesdocument. The panel has a couple of fields on it for the new document and a submit button.
It all works, however after submit (presumably in the "postSaveDocument()" event) I want to call back up to the repeat control and have it re-perform its lookup and refresh its content.
I'm looking to understand syntactically, how I can reference the repeat control and its properties and methods from elsewhere on the document -- and secondarily (though I can look this up once I get the first part figured out) what the refresh() method would be for that that repeat control.
Ideally, I think its something like: xp:page.repeatcontrolname.refresh() -- though I know that isn't right.
I'm sure once I see an example, it will apply to a myriad of other things.
Update :
I discovered that the repeated elements were actually refreshing but I wasn't seeing a new entry added to the list. The reason, ultimately, turned out to be that to add another entry to the repeat list I needed a new "control" -- but I'd checked that box (on the repeat control) that said "Create Controls at Page Creation". It was preventing my XPage from creating another entry for the new document to display!
This article explains the syntax for doing what you describe:
http://avatar.red-pill.mobi/tim/blog.nsf/d6plinks/TTRY-84B6VP
I have a feeling that this one captures the actual use case.
http://www-10.lotus.com/ldd/ddwiki.nsf/dx/Create_and_display_responses
The key setting that people tend to miss is "ignoreRequestParams".
Andrew,
The 'XSP.PartialRefreshGet' call was broken in Domino release 8.5.3 which results in the '_c9 is undefined' error.
Have a look at the article posted by Tommy Valand:
http://dontpanic82.blogspot.com.au/2012/03/patch-for-bug-in-xsppartialrefreshget.html
Basically to work around the problem a second argument is required to be passed to the call, for example:
XSP.partialRefreshGet("#{id:ExistingDevicesList}", "")