Is it safe to show a MessageBox from the DataGridView RowValidating event handler?

Posted on 2007-07-20
Last Modified: 2008-01-09
Is it safe to show a MessageBox from the DataGridView RowValidating event handler?

Some time back, I faced a situation where showing a MessageBox from the RowValidating event handler triggered another occurence of the RowValidating event handler.

My question is:
1. Does showing a MessageBox from the RowValidating event handler have any side effects ?
2. If Yes, how to code the RowValidating event handler to deal properly with those side effects (showing the MessageBox is a requirement for me).

Question by:rajesh_khater
    LVL 3

    Expert Comment

    It should be safe I guess. Keep in mind thought that pressing the OK button using the keyboard will raise an KeyUp event in the MessageBox' parent. At least, in my experience. Maybe your troubles have something to do with this?
    LVL 7

    Expert Comment

    Showing the messagebox in the validating event shouldn't cause any problems.
    Most of the problems come from what you do in response of the answer to the messagebox...
    An important rule:
    Never change the row or cell in the validating event! In general never change focus from within validating events. On top of that - don't change the content of the row in the validating event if you consider the input valid - only do that when you use the cancel = true. Cancelling will keep you inside the row (unless you changed the default behaviour for the validation (on form level change the value of the AutoValidate property) thus avoiding unnecessary events being fired.

    Hope this helped,
    LVL 34

    Assisted Solution

    I see that, whilst I was typing, illusio has already made - far more succinctly than me - the general point that I support whole-heartedly.  But, as I'd tried to give a bit more background, I've decided still to post.  Hope you don't mind Peter ;-)

    I don't think that displaying a MessageBox in a RowValidating event would, OF ITSELF, cause re-firing of that event.  Program flow would simply move from the event's sub to the (modal) messagebox and then straight back to the next succeeding line in the event's sub.  But such an event's sub is unlikely only to show a MessageBox and it is fairly easy to see how code within that sub could itself cause re-firing.  This is because "focus" is an intermediate state when that event fires.  

    It fires when the row concerned is being left.  That row is only "being left" because it is going somewhere else.  The first message that the system receives is that focus is to move to somewhere else - e.g. it is the user's click on the next row s/he wants to process, not anything s/he does in the row that s/he is finished with, that starts the sequence.  So the new location for focus is remembered.  But before that can happen, the old row needs to be left.  That is remembered, too.  Is anything necessary before it can be left?  If it causes validation, yes.  So the system then raises the RowValidating event.

    If you actually follow the process through - e.g. writing debug output - you will see that the RowLeave event is fired before the RowValidating event but that doesn't really invalidate the above description because the RowValidating event has an e.cancel argument which, if set to True, is going to roll-back the focus changes.  And in any event there is clearly some "mis-reporting" (or at least reporting that does not mean what it appears to mean) because, in following through the sort of scenario outlined below, it is perfectly possible to get debug output like this

    Row enter 0
    Row leave 0
    Row validating 0
    Row leave 0
    Row validating 0

    That is, two "leaves" without an intervening "enter".

    Now, if we stick another focus change into the equation at this point, it can cause problems.  A MessageBox, per se, is OK because it's modal so that, although focus moves to it it also moves immediately back again.  If you like (although I am not sure if this is technically quite how it is handled) there is an immediate (in program flow terms) matching push/pop so far as the "focus stack" is concerned.  But if there is some other focus change - e.g. to a yet different row, or to some control outside the dataviewgrid - what appears to happen is that it starts the process again.  That is, the system gets a message that focus is to move to yet somewhere else.  So that "yet somewhere else" is remembered.  But to go somewhere else, it has to leave where it is at the moment: where's that?  Although, strictly, it is currently "in limbo" - between two rows - the system cannot seem to cope with that.  So it goes back to the "old" row.  That needs to be left.  Is anything necessary before it can be left?  If it causes validation, yes.  So the system then raises the RowValidating event.  But now it's for the second time.

    Let me stress that I do not actually know the inner workings of the system in this respect.  But the above description is entirely consistent with what I have observed - both generally and in specific tests - of how it behaves.

    So I think the answer to your first question is No: showing a MessageBox does not, OF ITSELF, have any side effects.  But there may be side effects from other aspects of the code - perhaps, but not necessarily, relying on any response from a MessageBox - in the event.

    That being so, any avoidance of such side effects (your question 2) would really depend on what, specifically, was causing them.  But, as a general approach to this sort of problem, you might consider a form level Boolean variable - e.g.

        Private DoingValidation As Boolean = False

    And then encapsulating your code in the RowValidating event like this

        If DoingValidation Then Exit Sub
        DoingValidation = True
        'your code
        DoingValidation = False

    LVL 1

    Author Comment

    Well. showing a MessageBox in itself may change event flow. Just see my other question :
    LVL 34

    Expert Comment

    Yes.  It may.  My description above was very specific to the situation in this question.  A button is a single control that has, or has not, focus.  A textbox is a single control that has, or has not, focus.  A datagridview appears to me to be a complex set of controls within which the internal focus can shift from control to control.  Empirically, the behaviour can be observed to be different.  Why, in precise technical terms, that should prove to be so I am, as I said, not qualified to say.  But I do not see that anything in your other question invalidates anything that I said above.

    LVL 7

    Accepted Solution

    It seems the item for rajesh khater and this one are very similar. ( I've posted a more extensive answer for rajesh's problem over there - info).

    The messagebox will not cause any problem in most of the scenario's but there are indeed a few in which it will cause a problem. If your focus moves towards another control that upon entering must fire the validating (or leaving) event immediately because it moves the focus by itself - then you enter the scenario where the focus shifts inside (not entirely but still close enough) the validating cycle.

    Don't put a validating on a button - it's nasty and not realy necessary - you already have the click where you can what you need.

    Kind regards,

    Write Comment

    Please enter a first name

    Please enter a last name

    We will never share this with anyone.

    Featured Post

    How your wiki can always stay up-to-date

    Quip doubles as a “living” wiki and a project management tool that evolves with your organization. As you finish projects in Quip, the work remains, easily accessible to all team members, new and old.
    - Increase transparency
    - Onboard new hires faster
    - Access from mobile/offline

    Since .Net 2.0, Visual Basic has made it easy to create a splash screen and set it via the "Splash Screen" drop down in the Project Properties.  A splash screen set in this manner is automatically created, displayed and closed by the framework itsel…
    Entity Framework is a powerful tool to help you interact with the DataBase but still doesn't help much when we have a Stored Procedure that returns more than one resultset. The solution takes some of out-of-the-box thinking; read on!
    It is a freely distributed piece of software for such tasks as photo retouching, image composition and image authoring. It works on many operating systems, in many languages.
    how to add IIS SMTP to handle application/Scanner relays into office 365.

    761 members asked questions and received personalized solutions in the past 7 days.

    Join the community of 500,000 technology professionals and ask your questions.

    Join & Ask a Question

    Need Help in Real-Time?

    Connect with top rated Experts

    10 Experts available now in Live!

    Get 1:1 Help Now