SPListItem in FormsLib does not handle blank values - sharepoint

I have a FormsLib with a couple of xml files in there. When I pull up either InfoPath or the standard EditForm and clear out a value on the SPListItem (sync with the xml file) the old value comes back. If I add a space it works. I have tried it via the OM also and the result is the same.
So, for example, if I have a field with the value "Johan" and I pull up the form and clear out that value it still says "Johan" after the update.
Anyone else had any experience with this?

Yes. I have encountered this and the work around I came up with was to add a single space instead of clearing out the field entirely. In my experience though, it only happened if I made the changes in the EditForm. When done in InfoPath, it seemed to work.
Of course, after using " " as my empty value, I had to trim it whenever I needed to check if the field was indeed blank.

I have found an alterntive solution to this issue and I have blogged about it:
http://johanleino.wordpress.com/2009/08/24/node-demotion-does-not-work-with-blank-empty-values/

Related

DIfference between removing a column and making it hidden in Content Type

I have dealt with a customer recently where i suggested to hide some fields in content type to decrease loading time(I am not sure this might help him). But he asked me what would be the difference between removing the field from the specific Content Type and making it hidden, and the implications. Any share of knowledge/link is much appreciated.
Thank you :)
First, if I don't use a field, I'll definitely try to remove it. It's not a good habit to have some trash hidden field in Content Type. We often have some difficult to keep a clean structure with unique fields, content types... So when you have the opportunity so simplify this, just do it.
However, if your Customer want to keep the data in the column, hide the field is a solution.
I don't think there is more to say about these 2 options.
Edit : Sorry if it is a little bit confusing. By deleting, I mean remove the field in your list. This'll just remove the local column in the list not the column definition in the site settings.

Saving to multiple lists from 1 sharepoint 2007 list form

I have a request form I'm working on, wherein different departemnts need to be able to update it. To minimize overlap and lost changes I'd like to be able to submit data from the new form to different lists, but I cannot find a way to do this.
Does anyone have any experience trying to do anything similar?
If you're familiar with JQuery andSPServices I could envisage a way to do this.
In the EditForm.aspx, add the JQuery and SPServices libraries. using the $.(document).Ready function, I'd do a quick item update with the SPServices and just copy a column with the same data, so in effect no change looks to have taken place. I'd add in the edit comments something like "Pseduo checkout to [name], [date_time]".
Then allow the user to edit the form as normal but in the code you've added, you trap the PreSave Action and check that the person trying to do the save is the same as the last modified - if it is, save as normal, otherwise, return false on the PreSave and it will be denied. When you actually allow the save, set the edit comments to something sensible.
To complete this, check before doing the pseudo checkout, that the last comments don't contain the psuedo checkout phrase so that you can prevent anyone opening/editing the form whilst somebody else is in the middle of an edit.
This gives a cheap and relatievly easy to implement Check-In/Check-Out for a list. Not perfect of course but should work well in most scenarios (not in datasheet though, so you might need to prevent that type of edit).
If you have two lists would you not then have the problem of potentially two requests for the same thing?
Does none of the version control options for the list solve the problem of potentially multiple concurrent editors?
While SPService is certainly a solution, but you will have to build a UI of ur own.
Try writing a event receiver, which can copy over item to another list as soon as it is created.
It will be nice if you can tell why you really want to have a copy of item in another list
i.e. Auditing purpose etc. , you can get a perfect solution for this in Forum

Sharepoint Custom List with custom new forms not able to add to folders

I have a custom list which has customized edit and new forms which were required by the user.
I then tried to add a new item to a folder (folders have the text of the year e.g. 2010) and when I click save on the customized new form it saves correctly but always to the root of the list.
I am wondering if there is a fix or a work around for this as it is highly annoying.
Alternatively can anyone recommend a way to implement a field which will auto calculate + 1 year from creation date, which might be a possible alternative however it will have to take into account the following.
Where the current year runs october to september.
Thanks for any help this has been driving me mad trying to find a solution.
Can't help much without knowing what you based the custom form on, but for a new form the folder to save to usually shows up in the query string.
The form is a basic custom form list which I have then just modified parts to remove fields that are not required or need to be read only.
The original form worked perfectly and allowed items to be added to the list subfolders.
The new one has no additional code and is using the standard sharepoint DataFormWebPart to create the custom list form and so I have no back end code to insert the item etc, although I may have to resort to this...will I?
You need to be careful when modifying standard forms. I recommend you go back to a copy of the standard form and verify that that saves correctly. Remove the "unneeded" fields until it stops working.
Sometimes with this sort of customisation you need to use css rather than server side changes to modify the form so that the functionality remains in place after the component is hidden.
It is definitely not an issue with the removal of fields as I created a new copy of the original and then changed it to a custom field saved it and tried to add an item.
It went straight into the root.
I tried the original form and it saves to the sub folder correctly.
Okay only work around I have for this at moment (I am currently in discussion with MS) is this.
http://blogs.msdn.com/sharepointdesigner/archive/2007/06/13/using-javascript-to-manipulate-a-list-form-field.aspx
I used the method getTagFromIdentifierAndTitle(tagName, identifier, title)
This returned the element I was after and then I basically went to the row dom node and deleted it.
I am hoping to have a nicer method but at least it is a work around for now.

ExpressionEngine: which hooks to use to rewrite field contents on save and edit?

Not having much luck with this query in the ExpressionEngine forums and it's time-sensitive, so I figured I'd see if there's any EE-junkies hanging around Stack Overflow.
I'm working on an EE extension and I need to know what hooks to use to parse a custom field's contents when it's first saved, parse it before being displayed to be edited, and parse it when the edited contents are saved once more. My problem is I'm new to EE extension development, and I'm having trouble figuring out which in the long list of hooks I need to use. Best I can tell:
submit_new_entry_end is what I need to tie into when the entry is first created
publish_form_entry_data is what I need to tie into for parsing before the user edits the entry
And I must be overlooking the hook that will let me edit the entry data before it is saved back to the database. Anyone have some advice?
Thanks!
With trial and error, I finally answered my own question. The hooks that you want in order to parse a custom field's contents on save and reparse them before the entry is displayed are:
submit_new_entry_start (called whenever an entry is submitted; "new" appears to be meaningless)
publish_form_entry_data (I had this one right)

Saving a document to SharePoint brings up "Web File Properties" dialog with incorrect metadata

Situation:
A custom "Master Document" content type inherits from Document
The "Master Document" content type has five additional choice fields
There are five custom "Document Template" content types that inherit from the "Master Document" content type
Each of the "Document Template" content types uses a different Word document template (.dot) file
Each of the "Document Template" content types have been added to a document library
Problem:
I click on a document in the library
Document opens up in Word 2003 for me to edit
I make some changes and save
A box pops up called "Web File Properties". The window contains all of my custom metadata properties and the ContentType field. The ContentType field is set correctly to the current content type. The other fields are reset to their default values. This same window can apparently be opened by going to File -> Properties
This window by itself would be fine except for two reasons:
It includes the ContentType column
All of my custom metadata properties are visible but are reset to their default values instead of whatever values were previously selected. This means, every time the user wants to save the document, they have to remember what properties were tagged and set them back.
Question:
Can I disable this Web File Properties box?
If no... can I get the fields that show up to be populated to their correct values?
If no... is there a way to disable my fields from displaying in this window?
If no... is this a SharePoint page that I can modify?
***Edit with some more information***
It looks like this only happens in Office 2003 and looks like it affects Choice fields. If I create the same column as a Lookup field, it seems to work.
Edit again
Looks like if the lookup field is a multi-select field then it will not show up in the Web File Properties box at all (single select lookups still work).
edit 10/14/2009
Link to the KB Article mentioned below by Brenda:
http://support.microsoft.com/kb/971500/
This is more of a workaround rather than an answer but I figured I might as well put it here in case it helps someone else.
It seems as if these issues with the Web File Properties box is specific to Office 2003. The issues I reported above seem to be fixed in Office 2007.
If you want to get it working in 2003 and you have choice/lookup fields in your Document content type, here is the summary:
Single select Choice fields DO NOT work
Multi select Choice fields DO work
Single select Lookup fields DO work
Multi select Lookup fields DO NOT work
FYI - I want to CORRECT my previous post. The fix DID FIX my problem after I deleted my internet cache. Works PERFECT now. Here is the KB you need: KB971500 I can email you the fix if you can't find it. The notes in the document do not describe the problem exactly as I would have, but it was the fix for my case.
bhartson#lbrealty.com
We have the EXACT problem. I've opened a case with Microsoft back in February and they were able to finally duplicate my problem.
I have been kept informed and told that my fix would be available with the JUNE cumulative upates. I just received a specific hotfix from my Microsoft rep and applied it and it still did NOT fix my problem. I am hoping he gave me the wrong one and has the real one to send me.
Thanks for your post. I'm may try some of your suggestions above but I just want Microsoft to fix this. We can't upgrade to Office2007!
Thanks.
man, this was really killing me, I spent an entire day recreating document libraries and all sorts of content-types and variations of my excel template before I figured this was a bug... At least MS has a little hotfix request thing now... they're going to send it to me I guess :\
I didn't test this in excel/office 2003 and really botched a presentation of our little workflow... embarassing... always test with the app & environment people are going to use!!!
thanks for the KB article number

Resources