Problems with Web Part

Jan 10, 2011 at 9:41 PM

My SharePoint administrator installed the web part on our servers, and I brought the web part into my site and configured it for use.  When the administrator uses it, everything works fine.  When I use it, I get the following error message:

SearchButton_Click: Field2String: Index was outside the bounds of the array.
Source: AMFilteredSearch
StackTrace: at AngryManSoftware.WebParts.AMFilteredSearch.Field2String(String col, Int32 fieldType, SPListItem item) at AngryManSoftware.WebParts.AMFilteredSearch.SearchButton_Click(Object sender, EventArgs e)

and when I leave the web part I get an ugly Sharepoint message about an incorrect viewstate.  Changes are saved though.  The webpart shows up correctly, it just doesn't work for me.

Any guidance is appreciated!

Leslie

 

 

Jan 16, 2011 at 5:41 AM

Hi Leslie,

Apologies for the delay in replying - I've been away.

It sounds like a permissions issue (because you say it works for the site admin, but not for you), but I'm not sure why it's happening.

We need to narrow down the cause - maybe you could grab your site admin and look at the libraries that the part is configured to use. I would ask the following questions in order -

  1. Can you open up the document library  (or libraries) that the part is configured to use? And can you look at each of the defined views on that library without any errors (by which I mean "access denied" type of errors)?
  2. For the columns that have been configured in the web part - are these columns also visible in the default views of the libraries? Or any other views that work without throwing an error? If not, ask your site admin to create a view that includes these columns - does that view work for you?
  3. What are the types (e.g. single line of text, person, lookup etc) of each of the columns that have been configured for the web part?
  4. Try creating a new web part page and putting another copy of the web part on that page. Configure it for a different document library - does that also produce the error? Try it with only one or two simple columns configured - stick to single-line-of-text fields to start with. Does that work? If so, add another column of a similar type to one of the columns configured for the part that is causing the error - does that work?

If none of that throws any light on the issue, post a detailed description of the libraries and columns that have been configured for the web part, and also try to give us a detailed description of the permissions that you have on the site (I'm assuming that site admin has full permissions to everything).

Ron

Jan 17, 2011 at 3:21 PM
Edited Jan 17, 2011 at 5:03 PM

Hi Ron,

 

Thank you for responding. Here are the answers:

 

1.  Yes, I can open and modify any of the document libraries, and I can look at any of the views on any of the libraries.

2.  The columns are defined in the default view.

3.  Document Type = Choice, Attributes = Lookup

4.  I attempted to create a new web part page with a different document library. When I modify the AM search web part to use the document library, and tell it which column to use, I get this error: Error in OnPreRender, msg is Object reference not set to an instance of an object. Then, I have to close the SharePoint window altogether. When I re-open it, the Search box appears with the formatting and column assignments that I have given it on the web part page. If I limit the search part columns to the choice column that can have only one value, it seems to work. If I try to add the lookup search column that can have multiple values (separated by ;), then I get the array indexing error. Also, when I modify the web part page, I get the following error: SyncChanges: Attempted to perform an unauthorized operation. But if I close the browser window and re-open it, my changes are saved.

 

**When I use only one column in the search we part, and it can have only one value, the search now appears to work, despite the errors when configuring the web part.

 

After further testing, I added the second search column, and it seems to work OK as long as it is a single value. I have a “topics” column with multiple choices because in addition to free text searching, I wanted to give my users terms to search by, because if I can’t predict what they are going to enter free text, then I can’t guarantee that my documents are properly classified to be returned in the search result, but it looks like I may have to re-think my search.

 

Hope this gives you more detail about the issue.

 

Leslie

Jan 17, 2011 at 5:03 PM
Edited Jan 17, 2011 at 6:37 PM

Follow up ... I have continued to work with the web part today, and I have a couple of more questions:

1. Does the web part allow one to use site columns included in a document library?  I tried, and no checkboxes appeared in the search part. When I changed the document library to use library specific columns, the checkbox options re-appeared.  Since I have multiple document libraries that can use the same columns, site columns are a better alternative than document library specific columns, but I can use the document library specific columns if necessary.

2.  If I check items in the search, but leave the search box empty, the search runs and returns the correct document(s), but when I click on the document link I find that the URL in the link repeats the SharePoint server root address. (So I have two https://... addresses within the URL.   If I provide a search term in the search box, the results returned look and act like normal SharePoint search results and the links work properly.   If I put a "space" into the search box, the correct document(s) is/are returned, and the link is correct.

Any ideas?

Thanks so much!

Leslie

Jan 19, 2011 at 10:51 AM

Hi Leslie,

 

So it sounds like your original issue was with a multiple value column - that certainly isn't supported (I haven't even tried to figure out how to show an option with more than one value - so I know that won't work!).

A second issue is around site columns. The columns which can be configured are limited to those that can be deleted from the document library - that's how I distinguish system columns (such as "Created" etc) from the ad-hoc library-specific columns that the web part was written for (if a column is important enough that it's part of the content type, then it can be made a managed column and the "advanced search" can be configured to offer it as a scope for searching - the web part was written for those cases where people didn't want to go cap-in-hand to the SharePoint administrator and ask for theirlittle columns to be given special treatment!).

However, I don't *think* this should affect the use of site columns - you can add a site column to a library and just as happily delete it again, if it's not there as part of the content type of the library. Having said that - I haven't tested the web part with site columns so when I get a chance I will do so and let you know what I find.

Now - your last issue is about the link address when there is no search term given. I haven't seen this behaviour in testing, but I'll take your word for it (I'm assuming you are using the latest version by the way - you are, aren't you?). One thing that strikes me straight away is that you refer to the link address as being a secure html address (https as opposed to http) - which implies that your configuration is non-standard (to me, "non-standard" simply means "it's different from my development/testing environments"!). I'll have a look and confirm that I'm not seeing this behaviour, and if you can confirm that you are using the latest version of the web part for me that would be good.

As for your "search strategy" - having a column with multiple "topics" - I would have a think about how often those topics appear in the body of the document. If they're there, then aren't you users likely to use them as search terms anyway? The main use of these columns is to reduce the number of search results shown so that the users see the most relevant ones. So maybe you need to rethink your use of "topic" (which is a fantastic name for a generic catch-all column and one I've used myself many times) and try to separate out what information the users are searching for from what type of information they are trying to find. You might have a column called "Type of Document" for example, which could be anything from "Policy", "Procedure", "Form", "Template" to "image", "pdf" etc. And you might have another column that indicates Business Unit, or Location, or any other type of information that allows users to look for things more relevant to the themselves (i.e. indicating proximity, either geographically or functionally).

Ron

Jan 19, 2011 at 11:15 AM

Just had a quick look and tested out the use of site columns. They work, but they cause the behaviour with the link URL having the site collection URL prepended (i.e. you see the "http:" part of the root site collection twice). Is this the same behaviour as you are seeing? I.e. that this only occurs if you're using site columns?

And with "no checkboxes appearing" - the items shown as options in the list of checkboxes (and this is very important) do not get populated from the options in any choice field. They are calculated based on whatever the documents in the document library have had that column set to. If you create a column in an existing library then unless you set the values for that column for each document, those fields will all be blank. The web part collects all the unique column values in it's configured columns and presents those as checkboxes to the user. If there are no column values set, there won't be any choices shown regardless of whether the column is a choice field or a single line of text or whatever.

Let me know if any of this random waffling is helping you Leslie :)

Cheers

Ron

Jan 19, 2011 at 2:34 PM

Now - your last issue is about the link address when there is no search term given. I haven't seen this behaviour in testing, but I'll take your word for it (I'm assuming you are using the latest version by the way - you are, aren't you?). One thing that strikes me straight away is that you refer to the link address as being a secure html address (https as opposed to http) - which implies that your configuration is non-standard (to me, "non-standard" simply means "it's different from my development/testing environments"!). I'll have a look and confirm that I'm not seeing this behaviour, and if you can confirm that you are using the latest version of the web part for me that would be good.

My administrator downloaded and installed the part during December, so as far as I know, it is the correct version.  I cannot see any version information when I pull the part from the library. Is there version information available to the administrator? If so, let me know, and I'll confirm with him that it is the latest version.

 It is in this scenario where I see the prepending you describe in the next sentence. I am seeing the https: part of the root site collection twice. There are two search columns, and if I check one or two columns, I get a link to the document that shows only the document name, but the address in the locator has the prepended address. It’s almost like the <a href is in the wrong place in the display of the document result in this instance, IOW <a href=”siteroot/siteroot/documentname>documentname</a> instead of <a href=”siteroot/documentname”>siteroot/documentname</a> If I check no columns, the search part correctly informs me that there are no search terms, nothing to do.

One other thought ... I had an existing document library (for testing).  I just added the webpart to the existing page for the document library. Is there any reason that I MUST create a new webparts page and bring in the document library and the search web part? 

Just had a quick look and tested out the use of site columns. They work, but they cause the behaviour with the link URL having the site collection URL prepended (i.e. you see the "http:" part of the root site collection twice). Is this the same behaviour as you are seeing? I.e. that this only occurs if you're using site columns?

When I tried to use site columns, that’s when I saw no checkboxes. So I never got any search results to confirm whether there is prepending here.

And with "no checkboxes appearing" - the items shown as options in the list of checkboxes (and this is very important) do not get populated from the options in any choice field. They are calculated based on whatever the documents in the document library have had that column set to. If you create a column in an existing library then unless you set the values for that column for each document, those fields will all be blank. The web part collects all the unique column values in it's configured columns and presents those as checkboxes to the user. If there are no column values set, there won't be any choices shown regardless of whether the column is a choice field or a single line of text or whatever.

When the “no checkboxes” occurred, I guessed that documents in the libraries had to have values, and so made sure to set them. I am working with only five documents now in my testing setup, so I know that they are set. The only snag in this is that when I saw no checkboxes, THEN I populated the values in the documents, and still no checkboxes. Does the order in which I do it matter? IOW, when the web part “builds” does it build on what is available in the library at the time it is installed, and not change after that? Or should it update on the fly if I add a new column (site or library) to search by? It’s possible that I didn’t uninstall and reinstall the webpart AFTER populating the document library site column values, so I could try that again. 

As for your "search strategy" - having a column with multiple "topics" - I would have a think about how often those topics appear in the body of the document. If they're there, then aren't you users likely to use them as search terms anyway? The main use of these columns is to reduce the number of search results shown so that the users see the most relevant ones. So maybe you need to rethink your use of "topic" (which is a fantastic name for a generic catch-all column and one I've used myself many times) and try to separate out what information the users are searching for from what type of information they are trying to find. You might have a column called "Type of Document" for example, which could be anything from "Policy", "Procedure", "Form", "Template" to "image", "pdf" etc. And you might have another column that indicates Business Unit, or Location, or any other type of information that allows users to look for things more relevant to the themselves (i.e. indicating proximity, either geographically or functionally).

After revising it and getting some search results, I don’t think this is going to be a problem. If I need to refine further, I can add additional columns of single values instead of having one column with multiple values.

Thanks so much for your careful responses!

Leslie

Jan 19, 2011 at 8:59 PM

Hi Leslie,

December=correct version, so that's fine. The root URL appearing twice is a bug which I'll have to try to find over the weekend (I'll reply again when there's a fixed version available).

You don't need to create the web part after you've populated the columns, but you do need to go into the "modify web part" menu and click "Apply" - that should do it.

There are also some other useful (I think) options you should investigate too - showing a link to the library in addition to a link to the document, showing the matched column choices (for when the user selects mutltiple column values in a column - so they know which one matched) and filtering the library view by the matched column values (so the library view is automatically filtered to show all documents that also match the same column values).

Ron

Feb 14, 2011 at 5:34 PM

Hi Ron,

Haven't heard back about the root URL appearing twice problem. Wondering if you have had a chance to look at this?  Everything else is working fine. Thanks!

Leslie