- This topic is empty.
- Posts
-
-
Quest Support is reporting that they are unable to reproduce this error. Any of you that have an interest in this issue and you are running Sharepoint 2007, I would be interested in hearing if you can reproduce.
I am waiting to hear back from Quest Support regarding the steps they took.
Thanks!
Jim
-
(Sharepoint 2007)
Here is one more issue that I have logged as a case.
On a qListForm, add a numeric field and a few other fields including at least one that does a post-back.
Now test the form and follow these steps in sequence:- enter non-numeric data into the numeric field- make a change to the auto-postback field.
When the page posts back, the screen collapses so that you are left with nothing but the button bar(s).
I have only tested this with both the top and bottom button bars enabled, in case that makes a difference, but I doubt it.
The bad thing about this one is, my customer is now requesting that we just change all the columns to alphnumeric to avoid the problem. It is poor to have give up the benefit of numeric field validation. If anyone has found another way to avoid this issue, I would love to hear it! Thanks!
-
Hi Jim,
I followed exactly your steps to repro the issue using the latest Quet Web Parts 5.4 (recently released) and I couldn't.
On the screenshot below the field Weight is the type of Number and as soon as you leave the form a validation occurs. If the validation fails the forms events Save and PostBack are cancelled.
Hitting Save won't do anything as well as changing the Language field that has Auto PostBack enabled.
What is the version of the QWP are you using?
Thanks,
-
Thanks for trying, –
I had a call with Quest before the holidays and they were finally able to reproduce it, and I think it was with 5.4, but I am not positive. My version is currently 5.2.
I think I was able to reproduce the issue with a virtual PC installation of 5.4 before I left for vacation but I also am not positive about that. I will retry when I get back to work next week.
I am intrigued by where you mention "…if the validation fails… postback [is] cancelled". I know that save wouldn't happen, but I have not seen where postback is omitted. Is that something that has to be configured or am I misunderstanding?
Thanks again!
– Jim
-
Hi Jim,
Please try it again using 5.4 (latest) and let me know.
When I said validation I was talking about the validation of the field Weight that expects a numeric value.
If you enter an invalid numeric expression in the Weight field and try to hit Save the Save action doesn't happen because the Weight field validation fails.
-
Ummm. OK, no, I couldn't reproduce the problem in 5.4 I didn't get that far.
To make a long story short (after my initial loftier efforts) I simply created a basic custom list with *no* changes to the list – no columns added, etc. I can create items with that basic list. Then I do the basic dance of "replacing" the default webpart with the qListForm webpart, and when I try to save, I get the following:
-
OK, a colleague was able to test in 5.4 and the problem is still happening. Let me reiterate the steps once again in case I left something out. I should point out that we are working with Custom Lists, here, not document libraries, in case that makes a difference.
Also, my test used a yes/no field rather than a drop-down, so you probably want to try reproducing with a yes/no field just in case there is something special there (but I doubt it).
Using your example screenshot above (assuming you have a custom list and not a document library):
- add a yes/no column to your list; let's say it is called "Picker".
- ezEdit your Create form, and add Picker to the bottom of the webpart.
- Enable auto postback on Picker.
- Now add a new item to your list. Fill in the fields above Picker – perhaps skip over your drop-down field for now, and enter alpha characters in the Weight field.
- Now click the yes/no field, triggering the postback.
In our install of 5.4, on postback, all the fields disappear and the upper and lower button bars "collapse together" and look like the following:
-
Hi Jim,
Could you please export the list and the web part and provide them to me?
I tried different scenarios in my env. but I haven't see the crash you got.
Thanks,
-
Thanks, – sorry for the delay. For some reason I didn't get notified of your reply to my post; just happened to be back in here and noticed it and another reply on one of my other posts.
Fortunately, the page error I reported above (1/5@1:13pm) is isolated to my virtual PC server environment. My colleagues have not had the same issue installing 5.4 and using it. My subsequent post (1/6@4:02pm) mentions that we were indeed able to reproduce the numeric field validation problem, though. If you have access to the case management system, the attachments are there on #868109. If not, let me know and I will send them (let me know to where). Keep in mind, though, that it has already been acknowledged as a bug, so someone at Quest is already investigating it – just in case you don't want to be doing redundant work .
-
Hi Jim,
Would you mind to give me the support case number so I can check the notes?
Thanks,
-
Ok, I got it.
Thanks,
-
868109
-
Hi Jim,
Thank you for providing the case#. I checked the case and I saw that a work item has been opened to address the issue with the ID ST143504 and also I saw that you are on 5.2 version. Since then we've release 2 more versions (5.3 and 5.4). You may want to check the release notes for both 5.3 and 5.4 versions and search for your case # and/or the id provided above. If you find it I'd suggest to upgrade to the latest version.
-
Thanks , – but what I'm saying is that the problem still occurs in 5.4. We have reproduced it.
When I had my call with Quest, of my three cases, one was reported fixed in 5.4, and that was the end of that one. Quest opened a bug on the other two (including this one) because it is not fixed in 5.4.
-
You must be logged in to reply to this topic.