- This topic is empty.
- Posts
-
-
Hi Jim,
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.
-
Thanks, – but the problem persists even with Ajax disabled.
-
Hi Jim,
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).
-
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.
-
Hi Jim,
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.
-
Just to be absolutely sure, I went back and tested with yet another newly-created list, and the problem persists even without Ajax.
-
Hi Jim,
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.
Tks,
-
, 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.
-
Hi Jim,
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.
PS
I was not on your server (too busy with Sony's servers )
-
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() +50
System.Web.UI.Control.LoadRecursive() +141
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.
-
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.
-
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.