LOL....I will have to remeber the term "ghetto bound" ... I liked this!

I bound (ghetto bound anyway) the field to the ASP.NET calendar control.... works fine, don't waste any time on this.

Keith Chisarik

One thing I generally do on dates is break it apart and use combos...this way the user can't flub it up.  I would have to play with this for a few minutes to tell you where to place your code to prevent the error.  But you might think about using a combo for a date then on the update parse the 3 values to update the DateTime field.  You can also have 3 individual columns in your table then have a custom field that returns the date in your BO.  6 one half dozen the other

Another question:



Where/how might I trap the user putting the word "Bob" for instance in a SF web textbox that is bound to a date field? I have tried trapping for this in quite a few places and it seems like I cannot get ahead of the error the framework raises.

Keith Chisarik

No problem   I am glad you found your trouble spot.

I did know it in theory, but I havent done much web programming and I missed your call to AndAlso (Not Me.IsPostBack) in the Sample App code. I was recalling my fill on the postback and since the postback passed no parameters....... well you know the rest.



I feel silly but now my add is working, as well as the save without explicitly setting all the BO field values.



THANK YOU!!!!!

Keith Chisarik

First of all, do this.  Run the sample web application to see if you have the same results.  I don't think that you will.  If this is the case, we need to look at how your application is setup and why binding seems to be functioning differently within your application.

Next, as for the editing the wrong record, I think that there is something wrong with your postback code that is repositioning the record.  For example, if you add a new record, it will navigate to the new record and stop.  So if the record position is moving, something has to be moving it.  This logic is no different than WinForms.

If you have code in your Page_Load event, are you testing on Page.IsPostBack.  This is just one idea of where things could be coming from.  When you are dealing with a Web app, you have to take into consideration post backs when placing navigation code and so forth.  I know that you know this, but I am just reiterating some common things that I have seen in the past.

I must have something fundamentally wrong. Last week I had the issue where the SAVE command on the BO was not storing the proper values based on their current (modified) values, I had to manually set the value of each BO field to the correct current control value. I assumed it was due to the fact that I was using the non-SF loginview control, but that is not the case, this behavior also happens for SF bound controls directly on my form.



Now I have another problem which I feel might be related to a larger issue I have in my application, when I issue BO.add(), the form controls correctly all blank out so I assumed I was on a new record, this is not the case. Any changes to the values of the bound controls when saved are actually saved to the record I was on before I called BO.add(), not the newly added record.



Any thoughts?

Keith Chisarik