Limited response to NumericUpDown updates

Hello. I am having trouble with the NumericUpDown control in a program I am writing. On the ValueChanged event, the program performs a somewhat processor intensive operation, so that when the control is changed rapidly (e.g. by scrolling), the operation occurs several times in succession and the program is slowed considerably. However, it is only necessary that the operation be completed for the final value.

Is there any way I can get the control to ignore changes to its value if the value changes again in a very short time span? I attempted to use separate threads that were created when the value changed, waited a few milliseconds, and then carried out the operation if the value had remained constant, but as you can probably imagine this method was finicky at best and seemed unnecessarily messy regardless.

I've been trying to solve this problem for some time, so any assistance would be greatly appreciated.

How about this? Seems to work in my simple tests:

Code:

---

    public partial class Form1 : Form
    {
        private System.Timers.Timer _Timer;

        public Form1()
        {
            InitializeComponent();

            _Timer = new System.Timers.Timer() { AutoReset = false, Interval = 2000 };
            _Timer.Elapsed += new System.Timers.ElapsedEventHandler(_Timer_Elapsed);
        }

        private void _Timer_Elapsed(object sender, System.Timers.ElapsedEventArgs e)
        {
            // Do processor-intensive operation here
        }

        private void numericUpDown1_ValueChanged(object sender, EventArgs e)
        {
            _Timer.Stop();
            _Timer.Start();
        }
    }

---

I have it waiting 2 seconds, but you can set Interval to whatever you feel is appropriate.

Wonderful -- works like a charm. Thank you.

Have you thought about using the Validated or the LostFocus event instead of ValueChanged?

The behavior of those events doesn't feel right in context. Thank you for the suggestions, however.

Quote:

---

Originally Posted by roconnell

The behavior of those events doesn't feel right in context. Thank you for the suggestions, however.

---

I think LostFocus is much closer than ValueChanged... When I design dialogs they typically don't do anything on their own (besides validation), just return a delegate which does the corresponding calculation at the caller's behest.

Quote:

---

Originally Posted by brewbuck

I think LostFocus is much closer than ValueChanged.

---

I agree. If you want to do something every time the value changes, use ValueChanged. If you want to do something with the final value, use LostFocus or Validated (if you've turned on validation for that control).

After thinking about it, I sort of like the use of a Timer here. It allows the user to keep focus on the spinner and still raise the desired event. Still, it feels like a hackish way to write a UI.

Perhaps I should explain further. The program is (partly) a tile editor for a game, and the spinner is used to select the index of the tileset to be used to draw the current screen. When its value is changed, the image which contains the tileset has to be divided up before it can be used -- this is the "processor intensive operation." For one tileset, it takes a fraction of a second to do this, but this quickly adds up if it tries to do it for each tileset unnecessarily. It doesn't simply complete the operation for each tileset ahead of time because there are so many tilesets that this would use several hundred megabytes of memory.

The user will expect the tileset to be changed instantly if they, for example, just push the up or down arrow once or twice. This is why I do not want it to have to lose focus to change. Part of it is that I am replicating much of the functionality of the editor that comes with the game, which acts in this way, but does not have the advantage of allowing the user to type in a number if they know which one they want.

I agree that it seems hackish, but it works exactly how I want it to, and if there is no better solution, I am going to stick to it.

Sounds like your approach is incorrect. Load certain tilesets into memory and partition them so they are setup as single images. Alternatively you can load all tilesets into memory, split the up into tiles, and write the results to disk and flush the memory. Your application can then use these temporary tile sets at runtime and remove them when the app is closed. You can also use a most recently used list.

1. Only load what has been requested
2. If an image is requested move it to the top of the most recently used list
3. If the list is over some specified limit lop off the bottom of it until the list is back within limits or lop off the heavy hitters at the bottom of the list. The bottom of the list represents the least recently used images so these images can be removed.

This is a simple on-demand load system that uses an MRU list as its cache.

I have considered caching the tiles as individual images, and I may revisit this issue and implement such a system in the future. However, at the moment, I am more focused on other sections of the application.