none
How Do I Suppress An Event RRS feed

  • Question

  • Hello Community,

    I think this is a quick one, just cant seem to find the correct command.
    All help is appreciated.

    I have an event handler setup for a Data Grid View control, to trigger on both CellEnter And RowEnter events.
    The issues is that if a combination of these occur the handler will repeat itself.

    Obviously I would like the handler to just run the once regardless of which event triggers it.

    I am assuming there is a command to suppress an event argument once runtime enters the handler, muck like suppressing a keystroke (e.suppresskey...). I just cant seem to find it in the help or forums

    As Always. Thank you for help, Is greatly appreciated.

    Rob

    Monday, September 11, 2017 8:26 AM

Answers

  • Hello,

    You could use RemoveHandler. In this code sample, look at _CurrentCellDirtyStateChanged event in Form1. I use RemoveHandler for just that reason then use AddHandler to subscribe back to the event.


    Please remember to mark the replies as answers if they help and unmark them if they provide no help, this will help others who are looking for solutions to the same or similar problem. Contact via my Twitter (Karen Payne) or Facebook (Karen Payne) via my MSDN profile but will not answer coding question on either.
    VB Forums - moderator
    profile for Karen Payne on Stack Exchange, a network of free, community-driven Q&A sites

    • Proposed as answer by Cor Ligthert Monday, September 11, 2017 10:30 AM
    • Marked as answer by AussieHack Tuesday, September 12, 2017 12:13 AM
    Monday, September 11, 2017 8:30 AM
    Moderator

All replies

  • Hello,

    You could use RemoveHandler. In this code sample, look at _CurrentCellDirtyStateChanged event in Form1. I use RemoveHandler for just that reason then use AddHandler to subscribe back to the event.


    Please remember to mark the replies as answers if they help and unmark them if they provide no help, this will help others who are looking for solutions to the same or similar problem. Contact via my Twitter (Karen Payne) or Facebook (Karen Payne) via my MSDN profile but will not answer coding question on either.
    VB Forums - moderator
    profile for Karen Payne on Stack Exchange, a network of free, community-driven Q&A sites

    • Proposed as answer by Cor Ligthert Monday, September 11, 2017 10:30 AM
    • Marked as answer by AussieHack Tuesday, September 12, 2017 12:13 AM
    Monday, September 11, 2017 8:30 AM
    Moderator
  • hmmm, so there is not a specific command to suppress event arguments then, please?
    Monday, September 11, 2017 8:42 AM
  • hmmm, so there is not a specific command to suppress event arguments then, please?

    No there is not, in C# the same applies but we would had used to unsubscribe

    -= CurrentCellDirtyStateChanged

    and

    += CurrentCellDirtyStateChanged

    To subscribe back again.

    If there were a way other than that (other than setting a form level variable) I would had indicated it.


    Please remember to mark the replies as answers if they help and unmark them if they provide no help, this will help others who are looking for solutions to the same or similar problem. Contact via my Twitter (Karen Payne) or Facebook (Karen Payne) via my MSDN profile but will not answer coding question on either.
    VB Forums - moderator
    profile for Karen Payne on Stack Exchange, a network of free, community-driven Q&A sites


    Monday, September 11, 2017 8:45 AM
    Moderator
  • Events are always thrown by the OS. In fact it is a message to programs which is sent as a kind of broadcast. 

    A program can handle those events. The rest Karen wrote.


    Success
    Cor

    Monday, September 11, 2017 10:30 AM
  • hmmm, so there is not a specific command to suppress event arguments then, please?

    You can use RemoveHandler then later AddHandler, but think about this:

    You have to determine when to do that. If you're going to do that then instead, in your event handler sub, test for that condition and bypass it (or just simply "Return" if the condition is met).


    "A problem well stated is a problem half solved.” - Charles F. Kettering

    Monday, September 11, 2017 11:23 AM
  • Thank you Frank, this is the workaround I am using now. I have a mouse down argument as the sub starts which as you suggest bypasses the event handler. It just seemed like a messy way to get it done... at the time.

    Also Thank you Karen the add and remove handler of-course works also. It just seems a little like overkill as I don't wish the handler removed, also to remove it just to put it back seems a little redundant.

    However this was while I was assuming there was a command to suppress the event like we can with KeyEventArgs.

    I Am still a little surprised there is not a command to do it, or that there isn't a RowIndexChanged Event for DataGridViews much like a ListBox, an index changed event would cover both required event triggers.

    It is what is it though I guess. Out of the two options, my situation, Its probably best that I keep the bypass option as Frank suggested. However the anwer to my question is clearly Karens reply so I have marked it a the viable answer

    Thankyou both very much for replies, as always I appreciate you time to respond and your valuable insight.

    Grats

    Rob

    Tuesday, September 12, 2017 12:35 AM
  • Thank you Frank, this is the workaround I am using now.

    It's not a workaround - it's the correct way to do it.

    With adding and removing the handler it is too easy to get out of step.  The code that does that is remote from the event handler.  If your test is in the event handler then the event is handled in accordance with the condition being tested at the time the event occurs, not the time at which the condition might have been last tested, or the handler last adjusted.

    Having enabling and disabling code scattered throughout the application makes subsequent maintenance much more difficult and error-prone.

    Also, including the test in the event handler makes debugging much simpler - you see when the condition occurs, and you see that it is getting 'ignored'.   Not doing anything when the event occurs is just as much a positive action as doing something, and that decision should be part of the event handling.

    Tuesday, September 12, 2017 3:50 AM
  • Thankyou Acamar for your insight, Is appreciated.

    With the benefit of hindsight I see that now, hence why I added The "...at the time" comment on the end.

    Please understand I was not implying that Franks answer was in some way a hack or incorrect. I Was just trying to explain how I got to the point I was at when I posed my query.

    If anything I was glad to see how I had set the handler up was in the end very close to what Frank had suggested.


    Just when I think I understand something I soon find out how little I actually do understand. Seems to be a reoccurring theme for me.
    • Edited by AussieHack Tuesday, September 12, 2017 10:27 PM
    Tuesday, September 12, 2017 10:16 PM
  • Please understand I was not implying that Franks answer was in some way a hack or incorrect.

    I never took it that way; I understood what you meant. :)

    *****

    Just as an addendum here, Microsoft even endorses doing this. I'd have to hunt for it now, but it's about timers and the threadpool and how easy it is for a System.Timers.Timer to end up in a race condition (for real - the .Elapsed event can be raised even after the timer has been disposed).

    Their suggested remedy for this re-entrance conundrum is to "set a flag in the event handler method" or words to that effect. Essentially, exactly what we're talking about here.

    Food for thought. :)


    "A problem well stated is a problem half solved.” - Charles F. Kettering

    Tuesday, September 12, 2017 10:27 PM
  • Actually I have been playing around with this last night.

    I have set the CellClick and RowEnter handler separate from the actual handler code now...

    I have setup an integer variable to track the current row index for the DataGridView.

    As the Row Click or Enter Handler triggers an argument checks to see if the Integer value has changed and then subsequently runs the sub with the relevant code. This way it only runs once and then only if necessary (on row index changes).

    Not to take away for the moderator contributions above I think this may be a little more efficient while still being inline with the "set a flag" concept


    • Edited by AussieHack Tuesday, September 12, 2017 11:14 PM
    Tuesday, September 12, 2017 11:09 PM
  • ... and then only if necessary (on row index changes).

    Rob,

    You can detect that using the .SelectionChanged event. I don't know if that's helpful or not but I thought I'd add it.


    "A problem well stated is a problem half solved.” - Charles F. Kettering

    Tuesday, September 12, 2017 11:23 PM
  • Going with the two suggestions, I don't believe one is better than the other when done properly. 

    Over 12 years of writing code for enterprise level Windows desktop applications I've only needed to do what I suggested no more than two times and have no issues with maintaining said code. Everything is within the event, nothing else to depend on in regards to flags.


    Please remember to mark the replies as answers if they help and unmark them if they provide no help, this will help others who are looking for solutions to the same or similar problem. Contact via my Twitter (Karen Payne) or Facebook (Karen Payne) via my MSDN profile but will not answer coding question on either.
    VB Forums - moderator
    profile for Karen Payne on Stack Exchange, a network of free, community-driven Q&A sites

    Tuesday, September 12, 2017 11:31 PM
    Moderator