RGB Slider probs

BlitzPlus Forums/BlitzPlus Beginners Area/RGB Slider probs

Vic 3 Babes(Posted 2007) [#1]
Can anyone help with the following - surely someone who's written a paint program knows the answer to this.

I'm updating a Blitz 2D program to Blitz+. The Blitz2D program allowed the user to pick a colour-tint for the grey-scale interface from a predefined list of colours. Now that I've got access to slider gadgets, I thought it would be nice to offer the user the ability to select their own tint by changing the red/green/blue percent with slider gadgets. Unfortunately, it doesn't work too well - I want the user to see the results as soon as they release the slider gadget - an interface example is reddrawn with the new rgb values.

Grabbing the slider bar and moving it works perfectly - but obviously I don't want to update the interface tint for every increment of the slider when they click and hold an arrow-button, or in the gap between the slider bar and the arrow-button. However, there doesn't seem to be a way to avoid it. Why doesn't clicking the arrow-buttons or gap thingy generate an event similar to the event generated when they grab the slider bar?

I've enclosed two versions of the code - the first one has a text gadget and is easier to follow. If you try the first, you will see that the text gadget is updated perfectly if you slide the slider-bar - but if you click and hold an arrow-button, or the gap, then the text gadget updates really slowly - but when you let go of the arrow-button - the text-gadget suddenly jumps to the correct value.

The second piece of code attempts to simulate what my program is doing, by CLSing a canvas with the current tint - where my program actually makes a call to tint_greyscale(), where writepixel is used to redraw the interface with the new tint.

Again, grabbing the slider-bar works perfectly - remember I don't want the tint to update until they let go of it - which makes redrawing easily fast enough. But if you hold the arrow-button down until the slider-bar reaches the end, from the middle - then 100 queued CLSes are performed - which is bad enough - but imagine watching 100 queued calls to tint_greyscale(), and seeing the example interface slowly changing colour :)

Anyone recommend a solution. If not, I'll have to give it up, and just put a bunch of predefined tints in a list box like those you can currently select from the menu.

Thanks.

Thanks for any help.


Vic 3 Babes(Posted 2007) [#2]
Doesn't matter because

a) I decided to use a Windows Colour Requester instead - worked so well that I decided to make even further enhancements.

and

b) Had to give up updating the program to run in BlitzPlus because of a Serious Random Seed bug which causes Rand to return values outside of the specified range. No point continuing.