This project has moved and is read-only. For the latest updates, please go here.

SPLookupAddNew: Retaining entered values

Feb 20, 2010 at 11:41 PM

We've been using the SPLookupAddNew and it's working great, except users are getting frustrated when they have a lookup at the bottom of the form.  When they click Add New and then come back to the form, all of their previously entered data is wiped out.  I saw a few folks had talked about changing this...has this been resolved or is it on the radar screen?


Feb 21, 2010 at 2:20 AM
Edited Feb 21, 2010 at 2:21 AM

The only easy way to do this, I think would be to possibly get the SPLookupAddNew to open the second form in a popup (or similar medium), and refresh the choices of the original field when the popup closes; thus protecting the integrity of your original data entry. This (may) be something that could be used in conjunction with some jQuery and a web service, but I couldn't tell you if it's something that Marc has planned for the library or not. I'm overseeing the forums for him while he's on vacation, but this is a very interesting idea that I'll speak to him about when he returns.

Personally, I think there's a certain custom approach that could be taken to it. When I use SPLookupAddNew, more often than not it's a list with just a Title field (as I mainly use it on choices for META data fields in a doc library or list. In that application (where the form would only have a field or two), it'd be relatively easy to use some jQuery UI to open a modal form ( with that field, then update the options of the parent form once you've added your new choice. That said, if you're pulling from a list that has more than a few columns my solution is totally unrealistic as you'd have to build/render that form manually. I don't believe (Marc may know different) that there's any way to access just the form of a list without any of the SharePoint "templating" (without making a custom version of said form on the SharePoint side first).

Feb 21, 2010 at 3:13 AM

Thanks for the quick reply.  Unfortunately, the lists I'm using have more than just a few columns.  But you confirmed my train of thought, as a pop-up form was where I thought it would need to go also.  Marc does have a similar concept as a work item in returning the new item to the original form as the selected choice for the lookup, but I'm not sure what they were planning with the rest of the columns.

Feb 21, 2010 at 3:24 AM

Right; the actual part of getting the updated choice options into the field is relatively easy (many functions of SPServices have already accomplished that). The real challenge I see is the user interactivity part of it. In my mind, a jQuery "popup" (similar to how SPServices debug works) is a much better idea than having it open an actual window, as it's a lot easier to communicate with the client "window" to update the choices after submission. The hurdle is actually getting access to and rendering the form. Someone posted a similar question yesterday about using the Web Part Pages web service to access the form of a list, but I don't believe that the web service actually offers that capability. They were trying to render a form for a list within another page; essentially the same big issue as what we're looking for here.

My guess is that one of the things that has made SPServices so popular is the ease of integration, and how clean the library is. A requirement that you'd have to build an HTML form to use an enhanced SPLookupAddNew would go against that, so the question becomes- how do we automate the capture of the default SharePoint form to re-render it.

Mar 1, 2010 at 9:07 PM


As I replied to your comment over on the $().SPServices.SPLookupAddNew Wiki page, when I first wrote this function, I saw it as a tool mainly for Site Administrators to build up values. I think that many people are using it more as you are talking about, and I agree that it isn't perfect for these uses. I'm going to think about how best to extend it, or perhaps add another function which is more user-focused.

IMHO, if you are providing this capability to your users on multiple columns, then you probably will end up with some garbage data.  One of the best reasons to use Lookup columns in the first place is to ensure that you are getting normalized data into your metadata columns.


Mar 1, 2010 at 10:44 PM


I think maybe we aren't talking about the same thing with "multiple columns".  I've basically built a normalized "database" using the lists, and that's why I'm looking to extend the AddNew function so we don't get garbage data.  We're not using this for metadata.  It's to reference other lists with separate objects.  For example, when recording a loan we need to reference both a borrower and a lender, each from a different list.  That's what I meant by multiple columns.  When they add a new borrower, they are adding a whole form full of information (name, address, phone, etc.) not just a couple of fields.  It's actually working quite well except for this issue.

Sorry about the front page post...I thought I remembered a post about this issue from before and was hunting around for it when I saw that.

I'd be happy to help with whatever direction you would like to take this, as the users are really begging for this.  Just let me know. 

Mar 2, 2010 at 3:54 AM

Got it.  To me,  it's always best to implement something like it sounds like you are doing so that it represents the most common process flow, with enough options to cover the main divergences.  The SPLookupAddNew approach is going to let your users hop from place to place without that sort of process flow. My point on the garbage data was certainly focused on lookup data which is being used as metadata. It sounds like you are trying to link pretty beefy lists together (loans, borrowers, lenders, etc.).  I'm curious what your lookup columns actually contain?  Just the borrower numbers or something?


Mar 2, 2010 at 6:17 PM


I have similar deployments similar to what esenger is trying to do, and I think you're correct in your assessment that people are deploying the function more in user-accessed forms than for the admin side of the house. I'll give you one of my examples, in case it helps with your thoughts moving forward.

I have a list that tracks contracts for different customers. One of the meta data fields is the customer, which is a lookup to a customer list with SPLookupAddNew on the field. I took this approach as opposed to the choice with user fill in, so that once a user adds the new customer it's available from that point on in the dropdown. In my particular case, the access is quite restricted so I'm not as concerned with the risk of garbage data, but I do very much see your point. There's that risk that anyone with access can add values which may be incorrect or improperly formatted (that can then be reused in their garbage form by anyone else).


Mar 2, 2010 at 6:41 PM


Thanks for the example. That’s exactly how we are using it as well. Our “borrower” is the customer with all of the standard customer–type fields. It’s a very small shop and we are only going to have a few people entering data, so our risk of “garbage” data is minimal as well.


The lookup column for borrower is actually pulling the full name and not the ID (as that was more functional for the user). I’ve further customized the full name column to force uniqueness so they have to add a middle initial or something. I can get away with that as it’s a small list with about 100-200 names, but I recognize it’s not ideal. I’ve been playing around with an option to add additional fields to the information displayed when they click the drop down so I can stop doing that. Some combo of the Add New function with the Sharepoint Lookup Field with Picker shown here:


Mar 2, 2010 at 6:59 PM


I'm not sure if this is the solution you're looking for, but have you played around with SPDisplayRelatedInfo at all? You can use that to display other columns from the list driving the dropdown when the values change.



Mar 2, 2010 at 7:17 PM

I totally get your use cases, and i'm thinking about it.  It's fun watching the conversation.  ;=)


Mar 2, 2010 at 8:04 PM


I did look at SPDisplayRelatedInfo (which is very cool, by the way), but it didn’t really fit my business case. They need the info before they select the lookup value, not afterwards. Although I’m probably going to use it for other things.