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

Cascading DropDown Error in SharePoint 2013 MultiSelect Lookup on a Custom List

Mar 30, 2013 at 2:28 PM

I think I may have found a problem using the Cascading DropDown (the bread and butter of SPServices) when using SP 2013. I tried to provide as much information as I could about the problem (See linked PDF)

Let me know if I can do anything else to help debug this.

Apr 2, 2013 at 9:57 PM

The type of list shouldn't really matter. Are you sure that you have the columns set up the same way?

Apr 3, 2013 at 12:42 AM
Marc...I have double and triple checked everything and built many throw-away lists to make sure it wasn't a freak accident...but I can repeat it.

I know it sounds strange...but to me the key piece of evidence is that the DOM is rendering the same field in the two different lists...differently.

The only other variable is that the list "Mfr Specifications" does use ContentTypes.

If you want to remote into my computer and look around, you are more than welcome.

Let me know what else I can check.


Apr 3, 2013 at 12:55 AM
Hmm. Discovering the differences almost always leads to the answer. (I think I got that in a fortune cookie once.)

If one list is using Content Types, then the column in question is a Site Column. That Site Column is a lookup into the same list as in the Calendar, right?

What if you use the same Site Column in both places?

Apr 3, 2013 at 1:50 AM

OK let's make sure we are both on the same page.

I have 3 lists. "Mfr Specifications", "Maintenance Schedule", and "Templates"

Mfr Specifications has two fields (well more than that...but they are not important to this research):
-- Title (Static Name) has been renamed Model Nbr (Display Name). It is Single Text field.
-- PropType is a single value Lookup into the FLAT LIST called Types of Properties. where PropType is the Title in that list.

Maintenance Schedule has two fields (see disclaimer above):
-- PropType which is a Single Value Lookup into Types of Properties.
-- Model Nbrs which is MultiValue Lookup into Mfr Specifications. Where Model Nbr (Title) is the field being selected in the MultiPick possible values.

Mfr Specifications has Content Types (Ladder, Scanner, Forklifts, that loosely map to the PropTypes...but only in the logical sense...not in the physical.)
Maintenance Schedule has one Content Type (Event) by default.

These work fine.

Templates has two fields No Content Types.
-- PropType which is a Single Value Lookup into Types of Properties.
-- Model Nbrs which is MultiValue Lookup into Mfr Specifications. Where Model Nbr (Title) is the field being selected in the MultiPick Possible values.

This does not work.

So in reference to your statement..."the column in question is a Site Column"...yes and no.

Have I confused you yet?


P.S. to keep the project rolling...I created a fourth list (Work Templates) that looks just like Templates...only it is based on Calendar list and not a Custom List. I hide the Calendar fields and rewrote the DOM to say new template instead of new event. The Cascade works for Work Templates.

Apr 5, 2013 at 4:06 AM
So the fourth list "Types of Properties" has just one column (Title) and it is used as the source for the PropType columns in all three of the other lists?
I'm asking because I'm not sure what you mean by "FLAT LIST".

Apr 5, 2013 at 2:13 PM

"Types of Properties" actually has one other field --> a lookup into "Property Category" (which is a list with just a Title). However, it does not manage Content Types and is just a List of Values for lookup by other lists. Property Category and Property Type are just two levels of categorization...but both are very simple. Flat may have been a poor choice of words.

"Property Category" is used by all three lists.
"Types of Property" is used by all three lists.

Both PropCat and PropType columns are always a single choice drop down lookup.

It is when we then cascade into MultiSelect lookup columns that the problem occurs on "Mfr Specs -- [Title aka Model Nbr]" or on "Property -- [ Title aka Property Tag ]".

However, the "Maint Schedule" is a Calendar and both Mfr Specs and Property work as MultiSelect lookup columns on these forms...flawlessly.
Property only does a single select lookup into "Mfr Specs" based on the choices of Cat and Type...that works too.

The "Template" is a Custom List and "Mfr Specs (and I tried the Property column too)" does not work as a MultiSelect lookup column on these forms.

IDEA! What if the Model Nbr lookup was a Single Select and NOT a MultiSelect. So...I went into the Templates list and changed the MultiSelect lookup to a Single Select. I DID NOT CHANGE ANY CODE involving the SPServices call to the Cascade function.

Guess what...the Cascade NOW WORKS in Templates when it is a Single Select!!! Therefore it has to be a problem with the processing of the MultiSelect, because all of the field references are the same. In the original post I inked to a doc that had the line number where the code was failing. I still think that somehow the difference in the way SP2013 is rendering the MultiSelect is now different and somewhere in the SPServices, is is expecting the rendering the old way. What is interesting is that the Calendar list still seems to render the MultiSelect in a compatible manner.

I have attached PDFs to provide proof and some looks at the list settings and site collumns.


Apr 5, 2013 at 3:10 PM
OK, I'm going to have to try to reproduce something on my end. What you are doing has a bunch of moving parts and I think I need to come up with a very simple example where things break. If you can suggest what that might be, please let me know.

Apr 5, 2013 at 4:10 PM

I took the liberty of setting up a very simple example.

Attached is the PDF. Still breaks on the Multi Select.

I'm beginning to wonder if there could be something with my SP2013 install.

If you can do the same example and NOT break it...then we need should compare renderings of the HTML and SP version numbers.


Apr 5, 2013 at 6:21 PM
I was trying to use my email account to embed links and attach files -- seems that I must be in this forum to get the links correctly rendered....

...I am now in the Discussion board and inserting the link to the Simple Example of MultiSelect Breaking

It works in Preview...should be OK now.

BTW...How does one normally attach files to this forum?

Anyhow...A simple example still breaks on my computer...let me know what else I can do to help.

Apr 5, 2013 at 7:01 PM
ignore previous msg re: snail mail...was writing that when I decided to log into forum and do it that way...meant to hit delete and accidentally hit send.

Is there a way to delete a reply?
Apr 5, 2013 at 8:31 PM
You should be able to delete your own replies on the right side. I can do it, anyway. No worries, though.

Thanks for the info on this. I'll see what I can figure out.

Jun 20, 2013 at 1:49 PM

I am experiencing the same issue with Multi-Select options not working for the Cascading Dropdowns in SP2013. Was a cause/resolution found? I searched through your blog and did not find anything. I tried using the SPSServices.2013.1 library and still no dice. When I change the lookup values to a single select it works as expected. It is the same scenario as mentioned above.

Any help you can provide would be much appreciated.

Jun 21, 2013 at 1:48 PM

Can you please start a new thread and give specifics of your issue?

Jun 27, 2013 at 10:31 PM

The fix here is a quick one. If you'd like to give it a try, replace line 1439, which reads like this:

parentSelect.Obj.closest("span").find("button").each(function() {

with this:

parentSelect.Obj.closest("span").find("button, input[type='button']").each(function() {

Apparently someone at Microsoft decided to make a tiny tweak, switching from a button element to an input element. More compliant, but since they left the rest of the mess alone, inconsistent.

If you could try it out, that would be great. Leave any comments you might have on the work item I created: