Is there a way to handle the DropDownSelectedIndexChanged for list item new form.
Let say I have a custom list named Temp having Title, Products (which is a DropDownList) and Color Shade (which is a TextBox).
When I create a list item I want to select a product from DropDownList and on the selected index changed I want to write the
business logic such as fetching the row from Color Shade list and bind the data to TextBox of Color Shade. Now I can say ok so that
a list item will be created. Is it possible using VS 2008 sharepoint object model.
you could add a custom control to your masterpage which resursively traverses your control tree (start from this.Page) to find your dropdown and attaches the event handler (which itself is defined in your custom control). Also set the AutoPostBack property to true on the dropdown once you found it.
In terms of getting a reference do your textbox within your eventhandler, you could also apply the same approach of traversing the control tree.
note, you need to ensure that event handler is attached before eventhandlers are run.
Jaap
I am not sure if I understand what you mean.
An alternative approach, and probably less work, would be to use javascript (I would recommend using the jQuery library) to automatically populate your textbox when the selection of the dropdown changes. Everything would be done clientside.
Jaap
There are some third party components that do this sort of thing as custom column types, but if you're developing from scratch you'll probably find it a lot easier doing a custom form. If you do a fully custom version of newform.aspx, you'll still be using the standard new item menu.
If you try to modify the standard controls you'll run into issues like security errors if the submitted value wasn't in the original list.
If you don't want to write your own saving code, hiding the standard new form with css and modifying the values with javascript from your custom control can work quite well.
Related
My scenario:
The xpage ( document content ) has a complex structure. I have a 1st button which opens this xpage, having in the postNewDocument:
Contr.replaceItemValue("txt_codformularmain","01") // I use this field as a flag.
Now, there is another button which compose the same xpage ... but in this case, I do want the xpage to be different, in other words to have some additional / showed fields.
I could add another code at the postNewDocument, like this:
Contr.replaceItemValue("txt_codformularmain2","01")
Later on, in some views I will filter the listed documents by this 2 fields: some views will be listing the documents where txt_codformularmain=01, other views for txt_codformularmain2=01, and so on.
All the fields are on the same form element. ( I could create easily 2 different xpages, with 2 document contents, but in the form Properties at onOpen and onWebAccess settings, I can add only one xpage )
But, I think it isn't the best approach for this. Because in both cases, postNewDocument takes place, and both fields are having the value 01.
In classic lotus notes programming, I had used only one field ( flag ) and for every different button, inside the button's code I just changed the field value: 01, 02, and so on, before the newDocument had been composed.
Should I use another/ a better approach?
I might go for creating a new form with the fields needed there, and creating a new XPage binded to that form...
dominoDocument.isNewNote() will tell you if it's a new document or not. You can compute visibility based on that.
If it's based on a field value, then again set the visibility based on what the value should be for the panel to be visible - instead of getComponent().getValue() use dominoDocument.getItemValueString() assuming it's a Text field for best practice. In the onblur event of the control that's bound to the field you're checking against, trigger a partial refresh. You will need to amend the default partial refresh settings if there is validation on the page.
Once you're comfortable with that technique, start thinking about using a dataContext to hold whether or not an area should be visible, and referencing that dataContext variable in the rendered property. The benefits of this are not only performance, but youo can give a better variable name to the dataContext to make it clearer when supporting the application what the logic is behind it being visible. For someone supporting the Notes Client app, for example, it's unclear without hunting what state "01" or "02" means. Descriptors like "newDoc", "published", etc have an advantage there.
Another method of optimisation would be to use a Dynamic Content control.
But it sounds like your XPage is going to be complex enough without adding more complexity at this stage.
In my SharePoint List, I have an "Employee" column that is a User type field. I would like to add some custom Business Logic to the processing of this field.
Currently, when the user adds a row, I check to see if the user is an Employee or a Manager and then change the behavior on this column accordingly. I do this by statically rendering the field in my custom "ListForm Rendering Template", just before my custom ListFieldIterator. I simply use a standard SharePoint FormField (and FormLabel) control. In the markup of the FormField control, I specify the FieldName (Employee) and an event handler for the Load event. In this Load event, I will check to see if the current user is an Employee or Manager (using two different SharePoint groups). If the user is an Employee I set the value of the field to the current user (this part works perfectly). I also want to change the field so it can't be modified. I thought I might be able to just change the ControlMode on the field (in the code of the OnLoad Event Handler) to Display, but for some reason this has no effect. The field still renders with the full, people picker editor. Am I not changing the fields control mode soon enough? Or is this simply not the correct approach? The other logic I want to put in is if the user is a Manager, I would like to allow that user to select the person from a list (SharePoint group) of Employees. It may be easier to just use the people picker and limit the selectable users to that group. (I think I can do this with the SelectionGroup property.) Although, it would be better if I could just provide a dropdownlist of users, which I could possibly do with a hidden dropdownlist that I would show and event handlers that I could use (handle event selectedindexchanged) to pull the value selected and populate the (now hidden) Employee (user) field. Does this approach make sense? Assuming all that will work, the real difficulty I am having is with changing the ControlMode (rendering) on the field (when the user is an employee) to a label or some kind of read only control, which is how that field renders when viewing the row, which is why I think if I can just trick the control into thinking it is in Display mode then it should work perfectly!
I am still learning SharePoint, but I am very proficient in ASP .Net. This is why I would like to keep my customizations in this Custom Rendering Template, using code behind and leverage my existing skill set as much as properly.
Any thoughts, opinions or advice? Does anyone know why I can't get the column to switch the "Control Mode"?
I do not think that I fully understand your scenario. Some code samples could help.
But anyway it sounds like you want some heavy customizations of the user field. In that case you might want to have a look at creating a custom field with all its advantages and disadvantages. Have a look at MSDN: http://msdn.microsoft.com/en-us/library/gg132914.aspx
Another option might be - in case you do not want to re-use this column in many list definitions - that you can get away with your custom rendering template and create a custom create/edit form where you implement the specific edit behaviour for the field (plain ASP.NET with some SharePoint controls). Here is a nice walk-through on how to grab a custom edit form from SharePoint designer: http://community.bamboosolutions.com/blogs/sharepoint-2010/archive/2011/05/12/sharepoint-2010-cookbook-how-to-create-a-customized-list-edit-form-for-development-in-visual-studio-2010.aspx
I hope this helps. Kr., Bernd.
I have a SharePoint list that has MANY columns in it. The default AddForm and EditForm rendering is very cumbersome for the users. Most of these fields hold simple Number (integer) values. The default rendering for those two forms (using the ListFieldIterator I suppose) render the columns one by one vertically down the page. My thought was to design an input form with three basic "zones" (left/middle/right) and use a Custom Field for all of these "Number" fields. The Custom Field would contain two custom variable properties "Zone" and "Order". (Zone could contain middle/right and order would be the "order" in that zone the field would appear, the "left" zone would be for the fields that are not these "Number" fields, things like Date, Customer, etc. etc.) I would design the page with an HTML table and 6 Columns (1 for the "label" and one for the "TextBox" for each of the three "zones"). Then I could put a control (something similar to the "ListFieldIterator"). The control in the first zone would render the "static" fields, the zones in the other two zones would render the appropriate Custom Fields (based on the Custom Variable Property "Zone" and "Order").
Does this make sense? For the life of me, I can't figure out how to do this. I had thought about "giving up" and just using my ASP .Net skillset and creating FormViews and GridViews bound to the proper (ListView) DataSources. That has even proved challenging.
Does anyone have any ideas on how I could accomplish this? (InfoPath isn't an option and I want to stay with the "Custom Field" idea so the fields aren't laid out statically and can be moved around or even new ones added by the "administrator" of the Application (SharePoint List).
Any guidance is MUCH appreciated. I have been working on this all week and just seem "stuck".
Thanks,
Shayne
------ A Better explanation of my "application" and what I want to do-----
I have a SharePoint List that has about 60 fields in it. If I pushed this application out using the default Add/Edit SharePoint List Forms (and Rendering Templates), the users would hate it. The default forms use a rendering template that basically lays out all the list fields, one per (HTML) Row. Within that Row there are two (HTML) columns. The first one contains the "Label" for the field, and the second (HTML) column is the actual editor for the "FormField" (Text Box or whatever). Because of the number of fields in the list, the user would have to scroll several pages just to get to the bottom.
This list has about 10 "static fields" that I want to lay out on the left side of the page and then about 50 that are simply "task" fields. These store an integer and track "how many of these tasks did I do today". (This is a "port" of an MS Access application.) Depending on the "Add" page the user selects (I have a "parent" content type that contains every field and then a "child" content type for each "group" of users that will be using this form that contains just the fields/tasks that group tracks) the proper fields are rendered on the page. The problem is they are all rendered vertically and there is too much scrolling. These users (and admins) will NOT have access to SharePoint Designer or InfoPath. So, the "layout" for these fields must be iterator/repeater style (the users shouldn't have to get Development involved just to add a new "task" field to their application!).
The solution I had come up with is to use a Custom Field Type with two Custom Property Variables for each of these "task" fields. The Custom Property Variables (Zone and Order) would allow the administrators of the "application" to control where they want these fields to appear on the Add and Edit forms. The Zone Property can contain one of two values: "1st Task Column" (middle of the form) or "2nd Task Column" (right part of the form). (The "left" column of the forms would be used for those 10 or so "static" fields that all groups/depts/content types share.)The Order would just contain the order to sort the fields in, within their "zone". Obviously, the "zone" would indicate where on the form the field would appear (middle or right). I thought I might be able to use three Divs and render the appropriate List Columns in the appropriate DIVS. Or, following the default rendering template, instad of DIVs I could possibly use 6 (HTML) Columns instead of 2.
I quickly figured out how to make a new Field Type with Custom Properties (I used the Property Schema element in the XML definition, even though Microsoft says NOT to use that in SharePoint 2010, it was just so easy and I couldn't figure out how to add them otherwise. Now I know how to add them the "right" way, I just don't know if it is worth changing them.)
For the last few days, I have tried to figure out how to actually render these "zones". Remember, I want the users of this application to be able to add new fields dynamically, so I can't put any static field references in these forms. I have read about the Rendering Templates and the ListFieldIterator (and the new Content Iterator), but I can't seem to pull it all together and create an actual solution. The part that is throwing me off is how to query and render three different "sets" of fields at once (since the rendering is going to happen from "top to bottom").
Any help is very much appreciated!
Shayne
If InfoPath it out and you want to stay within the SharePoint infrastructure for forms, then the term you need to search for is DataFormWebPart. You may have heard of DataViewWebPart before, well this is the form equivalent. Just like the DVWP, this does lots and lots of XSLT to make its magic happen.
The trick is can you implement your grid/zone idea within the context of the DFWP's XSL. That I can't tell you but hopefully this is a starting point.
Defiantly Info Path is the solution here are some tutorials:
Video: http://channel9.msdn.com/blogs/laurhar/infopath-2010-customize-a-sharepoint-list-form
http://p2p.wrox.com/content/articles/customizing-sharepoint-2010-list-forms-infopath-2010
http://blog.libinuko.com/2010/03/21/sharepoint-2010-howto-start-customize-list-form-neweditview-using-infopath-designer-2010/
if you don't want to use InfoPath I would recomment JavaScript/jQuery you have just to modify (Edit) the page then inject some jQuery code to do what you want. Here are some articles about similar topics:
http://akanoongo.blogspot.com/2008/04/how-to-hide-fields-in-sharepoint-list.html
http://spground0.blogspot.com/2011/03/sharepoint-2010-custom-list-form-issues.html
http://ghamson.wordpress.com/2011/01/19/using-jquery-to-attach-regular-expression-validation-to-a-sharepoint-list-form-field-sp2010-ps2010-projectserver-in/
The only way you can achieve this type of custom form designing within the SharePoint framework is to apply it through post-rendering techniques using client-side code. And solutions like this tend to add considerably to page-load.
Simply changing the render template is not enough if you want it to be a dynamic and codeless experience for end users to author.
I can think of only one solution which comes close to fitting all criteria. It's "free", can be password protected, and also allows tab groups, rules and many other settings.
Dynamic Forms For SharePoint - http://spjsblog.com/dffs
I'm trying to figure out a clean way to hide a custom field type from the list of available columns when a user goes to add a new column to a list. I only want this field type to show up when a given feature has been activated (the feature could be site, web, or web app scoped for my purposes).
One theory (haven't had a chance to try implementing this yet) is that I could set all the ShowOnListAuthoringPages (and similar) properties to "false" in the fldtypes_myfield.xml file, then programmatically set this value to true when a given feature is activated.
In XML file, please set
<Field Name="UserCreatable">FALSE</Field>
I't work with me
Are you sure that you are able to see the Publishing Fields Type in the List Create Column Only with Publishing Infrastructure feature activated. I have a MOSS 2007 Server and I Create a Site Collection based on the Team Site (In this Publishing Infrastructure was not active) but still I was able to see the Rich HTML Fields in the Create Site Column Page. I doubt Publishing Infrastructure controls this function. Your option is good one for this, I would say.
Custom Field Types Features are per definition Farm Scoped, since Custom Field Types have to be deployed farm wide.
You cannot "hide" them from users. A field in a list is based on a field type (bool, user etc.). You CAN hide fields, not the base types. So if a user wishes to create an entirely new (site) column, he or she 'll be able to see that field type.
So, it does look like the only way to do really hide the field times is with attributes in the fldtypes_myfield.xml file. There are a series of properties that affect it's visibility described in this MSDN page. In my particular case I ended up just using the UserCreatable property and marking it as false. This pretty much means the field type won't show up in the UI anywhere, so you'll need to make a feature or some kind of list/library template that you deploy that makes use of the type. I guess this is an area we can hope for improvement on in SP 2010 (perhaps along with a scoping mechanism for event receivers so they don't have to be "global" in the farm).
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.