So, I´ve got an issue that someone might have solved (or so I hope). I have a datetime field that I use in a contenttype (on a listtemplate) that has its own editform.
Here´s a walkthrough of what happens:
Adding a value to the datetime column and saving the updated value shows up (as expected).
Updating the datetime column and adding null (emptying out the value) via the editform. The value isn´t updated but instead showing the old value.
I did some experimenting with this and I came to the conclusion that if I add an eventreceiver and try to update the value there it doesn´t even enter the eventreceiver as a blank string (I had an idea that the value is as a blank string and sharepoint can´t parse that to a null datetime) which leads me to think that there´s an issue with the fieldcontrol that causes this. I also found this article on MSDN which seems to be around the same issue. And also, the datetime field in the contenttype isn´t required.
Any ideas or suggestions?
UPDATE:
Apparently this only happens when I use a custom editform. When I use one of built in listtemplates this works like a charm.
I've had similar issues with this in the past. It is indeed a known bug. One work around is to set the field to the min or max value of the type and check for this value wherever needed and do the appropriate conversions. Depending on your setup and use, you could create a trigger to convert min/max values to null and thus minimize the code required to handle such a work around.
After some deep investiongation I have found that the root of this problem is related to the fact that I was using XML node propagation between the columns in the list and the actual xml file. I had prevoiusly been struggling with this regarding stardard text fields and thought that I had taken care of the issue..apparently not. DateTime fields apparently will not get sent to the eventreceiver afterproperties if it is null as thus my code will not pick it up as a null value. I had to take case of that and add them to afterproperties if I can´t find them in afterproperties. I will make a blogpost series about these issues and post the links to this post shortly.
UPDATE:
I have now completed a blogpost about how I solved this issue. Feel free to check it out:
http://johanleino.wordpress.com/2009/08/24/node-demotion-does-not-work-with-blank-empty-values/
Related
I’ve created new Segmented Keys in ACUMATICA for use in a specific module. I would like to assign the Dimension name dynamically but I noticed it works only with hard code or name like [PXDimension(“VENDOR”)]
Also, I have some limitation to create an IF Conditional inside the customized field… it does not recognize the IF clause (see the image).
I would appreciate any suggestion how to solve this issue.
I haven't seen how your original attempt at PXDimension looked, but I'm going to take a guess and assume you tried to reference a new custom field contained in a setup table, something like:
[PXDimension(typeof(XXMySetup.usrMyCustomField))]
If that's indeed what you tried to do, one very important thing to do is to ensure that you have a view for your table in your graph, otherwise the attribute will not find the table and record in your cache. For instance:
public PXSetup<XXMySetup> XXMySetup;
Without this view declared in the graph, the dimension attribute will not work as expected. It would be nice if a clear exception was thrown in this case - I made the same mistake recently and it would have been helpful.
I ran across a problem for which I found no documented solution, but inadvertently found the solution myself. So I wanted to document this here for others who may encounter the same problem.
I was using a CAML query within SPServices to retrieve list items, then referencing "ows_{fieldname}" as usual to retrieve the field value for each list item. The field value was reported as "undefined" for all items. I quintuple-checked that I was specifying the proper name of the field and that my query was properly constructed.
I eventually discovered that the fields I was trying to reference were not displayed in the default view of the list. As soon as I changed the list properties to include the fields in the default view, the proper field values were returned within my javascript.
I don't know how much of Sharepoint's underpinnings work, but I was very surprised at my finding because it implies that the SPServices GetListItems method gets its data from the list's default view, not the actual underlying list. I realize I could be wrong in this interpretation, but I imagine others could run into this same problem.
The default, although unreliable, way GetListItems works is that it's suppose to returns all fields displayed on the default list view if you don't specify ViewFields on input. This is unreliable. Although you got it working - now - someone could come along later and change the default view thus breaking your sweet customization. Bummer. :)
I suggest always listing the ViewFields you are interested in on the GetListItems method. This ensures that your will get them if they are set. That's right. You could still get rows with an undefined field. This happens mostly on fields of type Lookup that are not set on a row.
Hope this helps you understand what is going on. Over the years I have created my own wrappers around SPServices to ensure I get back a reference to all fields requested, even if they are not in the response by Sharepoint.
When using SPServices' GetListItems method, be sure that any fields that you reference from the list are included in the list's default view, otherwise an undefined value will be returned.
I'm using MPXJ to import EV fields from MS Project 2007. When importing .mpp file, all EV fields returned null. I then saved the file in XML formt... now I get only ACWP, the remaining fields are still null.
Of course, I'm sure that the file has actual EVM values, I can seem them in MS Project.
Can you please help? Thank you in advance.
Moe
So far I haven't been able to locate the various Earned Value fields in the MPP file. I suspect that MS Project may be calculating these values dynamically, hence I can't read them using MPXJ. In future I may be able to add Earned Value calculation to MPXJ.. but that's probably a long way off!
first of all I'm totally new to FAST but I already have a couple of issues I need to solve, so I'm sorry if my questions are very basic =)
Well, the problem is that I have a field in the FAST index which in the source document is something like "ABC 12345" (please note the intentional whitespaces) but when stored in the index is in the form "ABC 123456" (please note that now there is a single space).
If I retrieve all the document values then this specific value is OK (with all the whitespaces), my only problem is with the way the value is stored in the index since I need to retrieve and display it to my user just like it appears in the original document, and I don't want to go to the full document just for this value, I want the value that I already have in the index. I think I need to update one of the FAST XML configuration files but I don't have enough documentation at hand in order to decide where to perform the change, index_profile.xml? in the XMLMapper file?
I've found the answer by myself. I'm using a XMLMapper for my collection, all I had to do was to add the ignore-whitespace attribute to the Mapping element and then set this attribute value to "false". This solved the problem and the raw data now when retrieved from the index contains the expected inner whitespaces.
Thanks.
I am doing a workflow for a document library. I put a OnWorkflowItemChanged, and I want to get the value of the column which is changed. I use the workflowProperties.Item["name"] and use the afterProperties. But when I use the workflowProperties.Item["column name"], I still got the original value. When I use the afterProperties, it's NULL.
Then I make another workflow that is the same as above for a list. I can use the workflowProperties.Item["column name"] to get the new value in OnWorkflowItemChanged.
Has anyone come across this problem before? Can you give me some help?
The question seems to mix up Item with ExtendedProperties. As to why a difference is seen on a List/Document Lib, it might have something to do with versionining or perhaps the internal serialization is different. Anyway, some of my experience is outline below. I hope it may be of use:
Use the GUID (as a Guid object, not a string) to access the Before / After ExtendedProperties field. Using the Display Name in the ExtendedProperties will not work. The documentation on it is wrong. You can use SPList.Fields to go from Display Name to Column ID (Guid).
I bind all "Before" to MyWhatever_PreviousProperties and all "After" to MyWhatever_Properties, only accessing MyWhatever_[Previous]Properties after the appropriate event(s)).