Been away from this issue for a while - thought I had it figured out before but must have tabled it. Anyway, datetime is the only type in SQL we allow nulls to handle when a date can be empty. So, I've set the bizobj to AllowNullValuesOnNewRow = False but in SetDefaultValues I set:



Me.CurrentRow("ExpirationDate") = DBNull.Value



I'm using the strataframe dt picker control.



So, this all seems to work fine for adding records, etc. The problem comes in that if I navigate from a record that has a date to one that is null OR I navigate from a row with a null to a record with a date the buffer is dirty. If I set a breakpoint in the IsDirtyChanged event I see it is the Set Alternate on Null code causing this:







The partial class code looks like this:







How do I handle date fields when the date is optional (not required) and I don't want navigation to dirty the buffer? I also don't want to store 1/1/1800 in the DB.

Here is what I wound up doing as a workaround and although its not ideal, it works for now:



In BO Mapper I set "Return Alternate on Null / Set Null on Alternate (value type)" and I put #1/1/1800# as the null replacement - this gets me the exact behavior I want as far as translating and handling nulls in the DB for dates. No more 1/1/1800 values stored in my database. Yay!



To prevent the dirty buffer syndrome when navigating between records with/without date values I set the BindingUpdateMode to OnValidation on the datetimepicker - of course, this means the control must lose focus in order to update the underlying data but I think this is a trade-off I can live with for now.



If you have any better ideas let me know.



Thanks, Randy

The OnValidation is actually the default for .NET binding... it prevents the controls from being so chatty with their underlying data source.  The only reason we switched to the OnPropertyChanged was because the MaintenanceFormToolstrip that we use... toolstrip buttons to not inherit from Control, so when you leave a control to click a toolstrip button (like Save), the focus is not moved from the textbox to the toolstrip button, so the Validating/Validate is not fired on the toolstrip.  It didn't work very well when the last piece of data you entere did not properly update back to the business object , so we defaulted it to OnPropertyChanged. 

Thus, if you're not using toolstrips, then OnValidation will work fine, otherwise, watch out for the date-time picker being the last thing you had focus on when you went to the toolstrip.

Hi Ben,

It's starting to make sense now... I'm still a newbie at this .NET stuff, however, I'm realizing this is an issue I'm familiar with from my years with VFP. VFP toolbars also do not cause the current control to lose focus and therefore, the bound object doesn't get it's value in the same way the OnValidating binding behaves. In VFP, the framework we used the save methods would call a custom WriteBuffer() method that essentially adds a "dummy" control on the fly, set focus to that (disabling any validation that may occur), perform the save and then remove the dummy control and set focus back to the previous active control. Although it seemed to be quite a hack, it works quite nicely. I wonder if there is a way to add something like this in Strataframe. Not a show stopper for now, but as we get into doing more apps, especially re-engineering several SQL based VFP apps we have where null dates are rampant, this could become more crucial.



Thanks,

Randy

Yes, creating an imaginary control to focus would work, but firstly, I think we'll focus on figuring out why the [Property]Changed event is firing when it shouldn't.

Works for me!



Thanks, Randy