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…
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.
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 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.