This project has moved. For the latest updates, please go here.

One list I got the form working the way I wanted - other lists columns do NOT show up

Feb 6 at 5:46 AM
On one list I got the form working the way I wanted, but watching your excellent videos, attending your SharePoint Saturday in Reston, and reading your documentation.

But after, on other lists I get no columns. What am I doing wrong?

When trying to understand why, one of the lists started to behave nicely. I have no idea why. Got the form setup.

But whatever triggered the form to work didn’t on other lists. Each list, including test simple list does show columns.
Feb 6 at 11:54 AM
I created a new Edit view with SharePoint Designer -- I didn't do anything with the view other than making it the default view (same ASPX). And now the columns show up. Seeing the new view, SPEasyForms must trigger a new inventory.

FYI: On the SPEasyForms menu, there is an undocumented button that is shown when the fields were not there, I think is labelled "Disp", with the columns the button is no longer on the menu. When it was there, the file; a manifest of sorts had all the fields listed.

Hope this helps someone else.
Feb 7 at 4:02 PM
I did change the tag line on my blog. Now to be totally truthful, I didn't entirely change it because of your suggestion. I'm planning on standing up a second blog about general SharePoint developer topics and I'm going to use 'Working Man's SharePoint' there ;)

RE 1:

In general, SPEasyForms works on Out of Box new, edit, and display forms. I do get the list's field collection by calling the list schema web service, which is what you're seeing when you hit the Diag button. But, I don't use that to determine what fields are on the form, because I've never found a way to consistently tell what fields are on the forms through the schema. As a result, I determine what fields are in the form by loading the edit form in my JavaScript and parsing it for fields. I do that by going to:


Where the GUID is the list id. ListForm.aspx should redirect me to whatever form is configured to be the edit form for that list and content type (PageType=6 is the edit form). So the first question is, if you manually navigate to that url with your list id, where do you end up? Does it look like you expect? i.e. an edit form with all of the expected fields shown?

If the answer is no, then you need to investigate why. Could be an InfoPath form for instance, or a significantly customized SharePoint designer form. If it doesn't look like an OOB form, then I probably cannot parse it.

If it's yes, it does look like an OOB edit form, then we need to dig a bit deeper. For me to have much chance of figuring it out, I'd need to see the source HTML of the resulting edit form, namely the table with a class of ms-formtable.

So in general, there are 3 possibilities:
  1. I can't get to the edit form using the above URL.
  2. The edit form isn't displaying the fields you want it to for some reason.
  3. I'm failing to parse the edit form to find the fields for some reason.
On the lists shown in your attachments, it appears that I cannot parse any fields out of the edit form for some reason.

RE: Adding new fields to the list

There is a clear cache button, which you need to hit after adding new fields to a list. Closing and reopening the browser should also work. If you're clearing the cache and you still don't see new fields, the problem is probably related to #1. For instance, SharePoint designer generated forms generate static XSL for the form with the fields that existed in the list at the time the form was created. If you add a field after creating these forms, you need to manually update the XSL, or regenerate the forms from scratch. So if you're adding fields and clearing the cache, but it's an SPD generated form, SPEasyForms still won't see the new fields as something you can edit until you update the SPD forms.

RE: The Diag button

This button only appears when you run in verbose mode (i.e. hit the verbose button). It basically dumps the HTML 5 browser cache I'm using, so it provides a great deal of diagnostic information about how SPEasyForms sees your current list and site. I added it so I could ask for it when trying to diagnose problems from users, so its really for me in my support role which is why its undocumented. Also, the fields actually appear twice in the diagnostic dump. Here is a very stripped down version:

 "title": "Contacts",
 "fields": {
     "Title": {
         "internalName": "Title",
         "displayName": "Last Name",
         "spFieldType": "SPFieldText",
         "value": ""
 "template": "105",
 "feature": "{00BFEA71-7E6D-4186-9BA8-C047AC750105}",
 "baseType": "0",
 "defaultUrl": "/sites/speasyforms/Lists/Contacts/AllItems.aspx",
 "schema": {
     "Title": {
         "name": "Title",
         "staticName": "Title",
         "id": "{fa564e0f-0c70-4ab9-b863-0177e6ddd247}",
         "displayName": "Last Name",
         "type": "Text",
         "subtype": "",
         "required": "required"
     }    },
 "listId": "{43904aa8-b8e1-4cfc-8c19-b4173db75c53}"

The fields that are shown under the "fields" label are the actual fields that are parsed from the edit form as described above. The ones under "schema" are the fields returned from the list schema web service. So even if something appears in the "schema", it won't show up as something you can configure in SPEasyForms unless it also shows up under "fields". So on the lists where no fields showed up in the default form (i.e. your attachment), I would assume the "fields" part of the diag dump is empty, indicating that I didn't get any fields from the edit form for whatever reason.

Marked as answer by mcsheaj on 2/16/2017 at 7:07 AM