Disable handler until code complete.

[sgrya1]

I don't know how to put a title to this.

I made a plugin a for a program that has a Datagridview. Lengthy code runs when selecting cells.

When I click between cells a little faster than the program likes it crashes the program it is plugged into.

I created an invisible modal form to cover the controls and prevent clicks while it is executing but it doesn't seem to work.

Is there anything anyone can suggest? Is the code being broken somehow by a second click or is it added to a command stack?

[techgnome]

w/o seeing the code, it's hard to tell. It could be anything. To solve it, you could try removing the handler of the click event, or you could try simply disabling the control so that the user can't then click on it.

-tg

[sgrya1]

Disabling the control.

So I'm 100% sure I've tried that before but it seems to be working fine now. Can't think of what the problem was and why I switched to such a messy alternative. And one that doesn't even appear to work.
Thank you.

[sgrya1]

I've just worked out why I thought I had tried this.

My problem is now with combobox .enter or .click.
Temporarily disabling the control while code executes boots me out of it, so I can't go into edit mode.
Is there an alternative I could use for this one?

And is there a call stack? One that should theoretically allow code to complete instead of aborting it?

Edit: I shouldn't be able to Enter the cell twice in rapid succession.
Maybe I need some time to think about why this one has also been causing problems.

[Shaggy Hiker]

What you are wanting to happen is normally the default behavior, so something is a bit odd.

If you trigger some event handler, that will normally be ALL the UI is capable of doing. A second action might (or might not) trigger a subsequent event, but that subsequent event won't interrupt running code. Those events just post messages to the message queue, and the UI won't process messages off the queue until it is free to do so. A control won't even know that you clicked on it if the UI is too busy to process the mouse click message. That's why long running processes need to be moved to a background thread so that the UI can remain free to respond to user actions.

What you are describing is that one user action can interrupt a process. If that process isn't on a different thread, that shouldn't even be possible. If the process IS on a different thread, then the problem you are running into has to do with thread safety, which is a different matter.

So, something isn't making sense.

[sgrya1]

I wonder if has something to do with the program I am plugging into (AutoCAD).
I'm trying to think of a way to see if it is actually aborting code a double click.

[techgnome]

As much as I hate to sound like an echo chamber...

w/o seeing the code, it's hard to tell. It could be anything.

Maybe if you post the - relevant - code you're using, we can help... otherwise we're all just shooting in the dark here.

-tg

[Shaggy Hiker]

And that's fun, by the way, but you tend to hit things you don't mean to hit.