In dgrid 0.3 widgetArgs is replaced with editorArgs which can't be specified as function any more. I need to show options in combobox by querying at runtime from server. When editor gets created at that time I don't have options available. Earlier I used to specify widgetrArgs as function and with every dbclick editor gets created with option passed to constructor through widgetargs but now 0.3 onward editor will be created only once then how to refresh options at runtime.
Thanks,
Sandeep
You could connect a jsonrest store to your combobox. The store would populate the values as & when required.
Related
I am currently storing a key value pair in Office.context.documents.settings using the following function:
Office.context.document.settings.set(name, value);
Once the key-value pair is stored , I am relaunching the add-in and trying to fetch the value using the following function -
Office.context.document.settings.get(name);
But the function is returning null instead of the proper value. Does the value stored in document settings persist across multiple sessions of an application or does it get refreshed once we close the application?
Your question doesn't have a lot of detail but there are two common errors when working with settings:
Failure to Load Settings
Prior to reading a given setting, you need to populate the settings object. This is done using refreshAsync():
Office.context.document.settings.refreshAsync(function(){
Office.context.document.settings.get(name);
});
Side-loaded Add-ins
When you side-load an add-in, Office generates a random ID and assigns it to your add-in. If you remove and re-side-load the add-in, it will generate a new ID. You'll also get two distinct IDs if you side-load the same add-on on two different machines.
This will affect how settings function since settings are keyed by the Add-in ID when they are stored or recalled from a document. For details on how this works (and how to get around it), see Issue with Office.context.document.settings.get.
The setting isn't being saved because you did not call saveAsync. The set method only saves the setting in memory, not to the file. To save to the file you must first call set, then call:
Office.context.document.settings.saveAsync(callback);
Then when you reload the add-in you will be able to retrieve the settings with get. Here's the documentation page for the saveAsync method: https://dev.office.com/reference/add-ins/shared/settings.saveasync
-Michael, PM for add-ins
In lotus notes 6.5.6 i want to do this:
select one document in a view and then i run an agent that show me a view(with picklist method) and I want the cursor should reach on a specific view entry based on and original's selected document field. it's possible ?
i know this is possible with prompt method specifying the 'default' parameter but i can't use this method because i have to propose a view and not a list of values.... it's possible to do this ? I want to see all entry in the view so i can't use SingleCategory
Unfortunately this is not possible, not even in Version 9 (that is a little newer than your Version from 2008).
You might be successfull by using the API to send keystrokes, but as you do not have an event that fires when the Picklist- Window opens it is very unlikely that you could place the keystroke- sending code anywhere.
Basically what I want to do is create a form whilst within another form and pass values from the earlier form to the second. Complicated I know but here is what I got.
#Do(#Command([Compose];"LPK"); #SetField("PR_Make"; PR_Make))
The fields in both forms have the same name and this code is called when first document is attempted to be saved.
I think instead of editing the field on the second form it just saves a field as itself instead. Any help appreciated.
The best and common way is to enable form property "Formulas inherit values from selected document" in second form "LPK".
Add a default value formula to second form's fields you want to inherit and put just the name of field itself in. For your example default value formula it would be
PR_Make
Make sure you save document first and then create the new document.
Knut Hermann's answwer is the 'standard' way of achieving such things but there are other methods- eg you can use environment variables ..
Something like:
#Environment("PR_Make") := PR_Make;
#Command([Compose];"LPK");
Then set the default value for PR_Make in your new form as ..
#Environment("PR_Make")
FYI Environment variables are written to the user's Notes.ini file and so remain even after Notes has been closed and re-opened. #Environemt doens't work too well with Web applications as it uses the server's notes.ini.
An alternative would be to use profile documents:
#SetProfileField( "PRDefaults"; "PR_Make" ; PR_Make;#Username);
#Command([Compose];"LPK");
.. in the default field for PR_Make on new form :
#GetProfileField( "PRDefaults"; "PR_Make"; #Username);
Profile documents are stored as a kind of hidden document in the Notes database and persist with the database. The last parameter sets a further subdivision by username so each user gets their own profile doc - a bit like a personal profile for "PRDefaults". You can miss this last parameter #Username out, to have one profile doc per database but there's a risk of two people trying to use it at the same time and clashing.
Profile docs also work with web applications.
I want to be able to get the data and sort it in-memory. I am able to get JSON data using dojox.data.JsonRestStore. Now my question is how do I store it in memory and do in-memry sorting when I click on Dojo Datagrid headers. From what I have searched so far, it is not possible to sort the datagrid in-memory/client-side as it will request the sorted data from my Rest Service. As it is custom rest service, I am not able to sort the data on server side (or is it possible?).
Thanks in advance.
Arun
Outside of XPages, you should be able to set an attribute of the grid to do this -- clientSort: true
However, this doesn't seem to take effect within XPages. I tried the following, with no success:
Adding a clientSort attribute with a value of true to the grid control (via the Dojo tab). The attribute showed up in the right place in the page source, but had no effect. (Programmatically checking the property returned a value of undefined.
Setting [grid].clientSort = true on the onClientLoad event of the page. When checked programmatically, the property would show that it is now set to true, but it had no effect.
I even tried adding it to a grid created programmatically (without the Dojo Data Grid control) and it had no effect.
It appears that either XPages is wiping out the attribute or that it just doesn't work within XPages with a remote data source. (My first two attempts used a REST service. My third attempt used a remote XML data source.)
I still think it's worth attempting to see whether it works with a local data source (like a read-write item store), but I have not had a chance to try that yet.
I'm not a Notes programmer, however, for my sins, have been working on some Notes features for an in-house project recently. I need to enable/disable editing of a field depending on circumstances. It seems to me to be a fairly standard feature, I need, but I can't find any information on how to do this anywhere.
In form setup (and other field's onchange) code, something like the following:
if some requirement = true then
textField.enable = true
else
textField.enable = false
end if
I've seen other places where there's a workaround of conditionally hiding paragraphs based on some code, having 2 paragraphs with opposite hiding conditions, one with an editable field, the other with a computed field. However, I don't know enough about Notes to see how this is implemented (I can see it done on other forms, but there seem to be some 'magic' steps within Notes which I either can't see or don't get).
[EDIT]
The reply from Kerr seems to be what I'm looking for, but I still can't find out where the InputEnabled property is located. Should have said in the initial question, I'm using Notes 7.0.3.
In fairness, it doesn't matter what the circumstances are for when to enable/disable the field, it's just some boolean condition that is set, in my case only on form loading so I don't even have to worry about this changing dynamically while the form is displayed.
I've got a few issues with Notes, my largest bugbear being that it's so tied so tightly to the Designer UI, which is utter shite. I can do this sort of thing programmatically in most GUI languages (C#, Java, Delphi, even VB), but I need to open property boxes in Notes and set them correctly.
This would be OK as an optional method, but forcing you to go this way means you can only work as well as the IDE lets you in this case, and the IDE here seems to actively work against you. You can't open multiple functions/scripts, you can't swap from one script to another without going back to the menus on the left, you can't easily search the codebase for occurrences of variables/fields (and believe me, this is a major failing for me because either Notes or the internal codebase in my case seems to make a lot of use of global variables!), you can only work with fields through the property boxes that get displayed, you can't edit code in Designer while debugging through the main Notes client.
While the Java side of the coding is better than LotusScript, it's still fairly crappy (why can't you debug INTO Java code?? Why do you need to re-import JAR files for each Java class, does each class have a different CLASSPATH???). Possibly this was improved in Notes 8, I hear it's based on Eclipse. Does anyone know whether this is true or not?
It would help to hear more specifics about the 'circumstances', but the most common way to handle this is to use a hide when formula on the field you want to enable/disable.
Technically you are not enabling or disabling the field, just hiding it, but usually that works just as well.
Since there are few events to work with in Notes, developers commonly use the document refresh as the 'event' to cause the field to hide or show.
Let's assume you have two fields called TriggerField and Subject. Say also you want to disable the Subject based on a value in the TriggerField. The easiest way to do so is to set the TriggerField as a Dialog List type and check the "Refresh fields on keyword change" option. This means when the value of the dialog list changes, the entire document will get refreshed.
Then in your hide when formula for the Subject field, you specify your criteria for when to show or hide that field. Anytime field values change, followed by a refresh of the document (i.e. form), that hide when formula will be re-evaluated.
There are other ways, depending on your circumstances, to solve this problem. If you want to let the user refresh the form themselves, put a button on the form that calls the #Command([ViewRefreshFields]) command. You can add any other formulas to that button before the refresh command if you want to make other changes to the form at the same time.
Another option is to make a certain field display-only. Then create a button that runs LotusScript to allow users to change that display-only field. In the script you can propmt the user for a value, set the display-only field, and then call for a document refresh.
In ND7 and up if you want to just disable the field for input, write an appropriate formula in the InputEnabled section of the field you want to disable.
So I have two fields one called Trigger, a checkbox with the value "On" and another Subject that is a text field. When Trigger is checked I want the value Subject to be enabled.
I simply put the following formula in the Input Enabled element of the field Subject:
Trigger = "On"
I also want this to be recalculated whenever the value of Trigger changes so I select the "Refresh fields on keyword change" option on the Trigger field.
If you're stuck in an older version you need to to hide paragraphs appropriately.