[Anonymous]

Hi Steve,

  Would you mind to provide more details about your configuration (OS, SP version, list configuration, qListForm configuration) so I can try it?

Thanks,

[Anonymous]

Quest Web Parts for SharePoint 5.5

Client OS: Windows XP

Server OS: Windows 2003 R2 SP2

Application: Internet Explorer 7.0

Make a custom list with a Title column. Make another custom list and add a Lookup column to the Title column in that first list. On the Edit page for the second list, edit the page and add qListForm to replace the out-of-the-box form. In the display fields, edit the lookup column to be calculated value to itself using the %columnName% formula suggested at the bottom of the form when you make a field be calculated. This seals the column from editing, even on the Edit item page. Then create an item in that list. Then test the edit form by editing, saving, and closing. You will lose the data that was in the lookup column.

[Anonymous]

Hi Steve,

  Than you for the details.I was able to see the issue in my env.

Please contact Quest support and open a case (please mention my name so I get the case).

I'm going to record the issue and I'll provide the reference number to you.

The issue will be addressed in future releases.

If your goal is make that field read only there is a workaround.

Use Form Component Behavior and Disabled When condition for this lookup field and set the condition as following

<Or><IsNotNull><FieldRef Name="Country" /></IsNotNull><IsNull><FieldRef Name="Country" /></IsNull></Or>

"Country" is the lookup column in my second list.

The idea is to make the condition always true so the field will be always read only.

Please let me know if you have any questions.

Thanks,

[Anonymous]

I already entered this as case 958831 and wanted to alert developers in the community to be aware of this and hopefully avoid disruptive loss of data. Plus, I hoped to surface workarounds like the one you describe. Thank you for your replies and suggestion.

[Anonymous]

Thanks for letting me know the case#, I see the case now.

I contacted the support engineers and the case will be assigned to me.

The workaround is quite easy to implement. If you think about something else please post it so other people trake advantage of it.

If you think that the answers I provided are helpful please mark the question as answered/helpful.

[Anonymous]

I am evaluating Quest Web Parts for SharePoint 5.5 for possible upgrade from our current production version of 5.2. I am using the qListForm web part. On the EditForm.aspx page, I have configured a lookup column to be calculated value instead of regular field. This is to block users from changing this column’s value on the EditForm.aspx page. Then I set the calculated value to be itself. But when the item is saved, the lookup column’s value is being blanked out to null. Our current version of 5.2 does not do this and retains the lookup column’s protected value as desired. This bug may have been introduced in 5.3, 5.4, 5.4.1 or may be new to 5.5. We use calculated lookup values on EditForm.aspx very frequently and cannot even consider an upgrade until this is corrected.

[Anonymous]

Hi Steve,

I updated the case notes and you'll be provided the internal number where I recorded the issue.

[Author]

Posts