Converting Date to String in BPM Widget

Warning: This may be more of a complaint than anything else.

I want to convert a date field to a string value in a BPM widget. Fortunately, there is conversion function just waiting for me to use, just double click the function in the tree view and, viola, the function and format is placed into the editor…

Dang, that’s sweet! Now, all I have to do is add my date field to the formulas, right? Not so fast, bub…

Hmm, that does not appear to be working as expected. But this appears to work…
image

Perhaps the field I am referencing isn’t a date formatted field? Nope, that’s not it.
image

Certainly I could do this with a bit of custom C# code, but why should I have to?

What am I missing here?

Michael

click on the PODueDate in the Directive Variables tree

Then add the .ToString... after it.

Also, the format param is not what you think. Search C# documentation for ToString(format) to get a list of valid format values

EDIT:

Whoops I was thinking of something else on the format value. "MM-dd-yyyy" should work

Hey, Michael. Your issue is actually that you’re trying to use .ToString([format]) on a DateTime? variable, which is distinctly different from a DateTime variable.

If you know the field will contain a non-null value, you can cast this to a DateTime first using the following: ((DateTime)ttRcvDtlRow.PODueDate).ToString("MM-dd-yyyy")

Otherwise, you’ll want to account for the null in some other way… something like (DateTime)(ttRcvDtlRow.PODueDate ?? BpmFunc.Today()).ToString("MM-dd-yyyy") …or something.

I hope this helps!
-Joseph

1 Like

Joesph,

Thanks for chiming in on this, and it does help.

I had solved this by converting the DateTime value to a string and parsing out the date:

ttRcvDtlRow.PODueDate.ToString().Substring(0, (ttRcvDtlRow.PODueDate.ToString().Length - 12)).Trim()

But your solution is more elegant than my crappy workaround. I have a widget that handles the NULL instances, so I can use your first solution.

After a bit more experience with C#, the nuances of DateTime vs DateTime? may make more sense. And I get that the possibility of a NULL value is significant. Were I writing a function to convert date values to strings, however, I would consider handling this possibility one way or the other. Furthermore, were I Epicor attempting to make a UI for mere mortals to use, I would write a BPMFunction that handled this more elegantly and produced something approximating human-readable error messages.

I’ll stop complaining now.

Michael Thompson

I entirely agree. It would be nice if Epicor expanded their BpmFunc class to be more useful in interacting with datatypes it uses throughout the application, particularly nullable datatypes that require similar workarounds. Then, all of the pre-built function stubs could pop in some version of BpmFunc.ConvertSomething. In my opinion, I think the people who use the stubs are likely the people that want most of it done for them, and the people who know C# and want full control won’t use the stubs.