- This topic is empty.
- 06/02/2011 at 9:07 am #4791
The issue you experience is more likely due to your environment. We've had a very few cases when that happened and the solution was to disable the Ajax on the web part.
Please try it and let me know how that goes.
- 06/02/2011 at 9:39 am #6858
Thanks, – but the problem persists even with Ajax disabled.
- 06/02/2011 at 12:10 pm #6859
If you have a test env please create a page add teh list form on it and try it again.
Ideally would be to do that in a different env (or at least on a different site).
- 06/02/2011 at 12:21 pm #6861
That is what I did. Every time a new test is done, I start with a newly-created custom list, just to eliminate the possibility of any residual effects from repeated re-configuration.
- 06/02/2011 at 12:25 pm #6866
Thanks for reminding me. I've seen cases where the web parts (in general not only QWP) still remember bad configuration even changing some settings. Therefore I'd suggest you to delete the existing web part and add it again on the page.
- 06/02/2011 at 12:31 pm #6867
Just to be absolutely sure, I went back and tested with yet another newly-created list, and the problem persists even without Ajax.
- 06/03/2011 at 9:50 am #6703
Could you pelase do another test?
Create a new page and drop a new qListForm on the page and try it again.
Doesn't matter if the list you try to update is an existing list just be sure that you drop a new qListForm on the page.
- 06/03/2011 at 10:05 am #6704
, pardon me for being dubious (and sounding like a smart-aleck) but unless you have been on my server and made changes, I can't see what yet another test will accomplish. I have done exactly what you say at least three times already. If there is something you are looking for on this (logs or whatever), just let me know and I will contact our SP administrator team to acquire that information.
- 06/03/2011 at 11:09 am #6705
I didn't want to push you for more testing but I just wanted to be sure that you dropped a new qListForm web part on the page.
There is a great free tool for visualizing/searching the SP log, it's called ULS LOgViewer (http://ulsviewer.codeplex.com/) and it could help to see
if there is something logged.
I was not on your server (too busy with Sony's servers )
- 06/03/2011 at 12:19 pm #3892
I have opened a case but wanted to make the user community aware.
In Quest Web Parts for Sharepoint 5.4.1, when a Quest qListForm webpart is used with a custom list that includes a person field, and the person field is configured with the “Use People Editor” property, the aspx page become unmaintainable.
The problem occurs when going back in to edit the qListForm configuration. ezEdit goes to an error page with the following:
[NullReferenceException: Object reference not set to an instance of an object.]
WA.Common.UserFieldControl.OnLoad(EventArgs e) +134
System.Web.UI.Control.LoadRecursive() +141 …
One way to get the form back is to delete the person field from the list. Then, ezEdit will give you an error message because it cannot find the person field, but at least you can get to the XML to remove the reference.
- 06/03/2011 at 12:19 pm #6706
Gotcha – yes, that has been my practice on all my attempts. Thanks for the tip on the log tools – going to check that out now.
- 06/06/2011 at 1:24 am #4788
Quest's response to my Case on this issue is that this is a known issue that 5.5 will fix, which is due for release on 6/15.
You must be logged in to reply to this topic.