Limited response to NumericUpDown updates

This is a discussion on Limited response to NumericUpDown updates within the C# Programming forums, part of the General Programming Boards category; Hello. I am having trouble with the NumericUpDown control in a program I am writing. On the ValueChanged event, the ...

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.

If I did your homework for you, then you might pass your class without learning how to write a program like this. Then you might graduate and get your degree without learning how to write a program like this. You might become a professional programmer without knowing how to write a program like this. Someday you might work on a project with me without knowing how to write a program like this. Then I would have to do you serious bodily harm. - Jack Klein

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.

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.

If I did your homework for you, then you might pass your class without learning how to write a program like this. Then you might graduate and get your degree without learning how to write a program like this. You might become a professional programmer without knowing how to write a program like this. Someday you might work on a project with me without knowing how to write a program like this. Then I would have to do you serious bodily harm. - Jack Klein

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.