Lots of small color \"swatches\"

I have been trying to noodle out a method for doing the following:

I have 254 color choices (0 and 255 are fixed, unchangeable). I wish to display the number of the color with a small sample of the color. If the user wishes to change the color, they merely click the color swatch to invoke a callback that allows them to set a new RGB value.

I have toyed with using a text box (%rs) and setting the background color, changing it dynamically as needed. I have also thought about creating a graphic object (16x16 or 32x32) of the appropriate color and detecting when the user clicks on that swatch coordinate. This seems to be a more complex solution, but perhaps it is not. It is something I've never tried.

I had looked at using the make_icon or make_bitmap functions, but I cannot replicate the precise RGB values that should be represented. Am I missing some other function that might be useful?

There may be other options I have not considered. And that's why I'm asking you!

Thanks in advance, Bill

P.S. As an aside: This function is linked to AutoCAD and how it operates.

If in doubt, I usually resort to a %gr area and in the callback, determine the mouse coordinates and then figure back what that means.

The problem with 254 is that it factorizes to 2 and 127, and 127 is prime.. so it's 2 rows and 127 columns or vice versa. 250 is a better number of swatches as that can be 10x25.

It is possible to use 2 %gr areas, one for 'primary' colours and one for the rest, which with judicious arrangements (say a square and a column) could look quite nice.

What I have found by experience is that saturated colours look good on screen, but more pastel shade are better on a print. Saturated colours on a print sometimes lead to incomplete toner fusing (laser) or wet and stretched paper (inkjet).

Eddie

One approach is to access the 'Color Dialog Box' and then get the nearest colour to the one selected by the user.

I can find some details if this is of interest.

https://docs.microsoft.com/en-us/windows/win32/dlgbox/color-dialog-box

Eddie, I was thinking more of a 16x16 array of swatches., and I would ignore trying to change 0 and 255.

Paul, I'll also look at the color chooser; thanks for the link. It is definitely of interest to me, perhaps others. And, it is something my users have likely run across in the past!

Bill

See CHOOSE_COLOUR@.

GET_NEAREST_COLOUR@ and GET_MATCHED_COLOUR@ are probably not relevant to your needs.

Bill,

I'd still use %gr.

Eddie

Paul, thanks for the hint! I'd missed that one! I'll use that to allow the colour selection.

Eddie, I'll give the %gr a shot!

Bill

I've done some %gr testing and have some really good outcomes!

First the %gr will work great, and using a %ud along with it give me great flexibility. I can write a handler that is 'swatch independent' by passing along the uid parameter (%`gr) with each drawn entity.

I can also 'link' the choose_colour@() routine to the swatch in this way. Because I'll have the uid parameter, I can directly re-draw the swatch with a new color when the user changes it as well as use the uid as an index into the array that saves the color information. I couldn't see any other way to change a %gr color, so if someone wants to weigh in on other methods of changing the color of a %gr object, feel free.

I do have a question, maybe for Paul? If I have multiple %gr in different child windows, but they share a parent window, do the uid's need to be unique? I'm thinking that they do need to be.

Bill, Looks like your GUI is pretty advanced, would be nice if you post how it looks to potentially learn something too. Also this will lure new users to Clearwin. The more users the more features and faster fixes.

Thanks for the accolade, we'll see how the implementation works!

I'll let you know!

Bill

I am not clear about what your uid's are for. I would have to see some code to work it out. If they are needed then I guess it won't work without them.

Paul, each swatch is assigned a uid, and there is a common callback handler. I'm not trying to process coordinates; I have user data attached to each swatch as well, and as the cursor moves across them, the user data is sampled and that shows the user what color is 'rolled over'.

So, each swatch is created thusly:

					ii = winio@('%`^gr[colour=#'//initial_color//',FULL_MOUSE_INPUT]%ud&',24,24,1000+k,track_mouse_autocad,k)

%ud&',24,24,1000+k,track_mouse_autocad,k)

[quote:584fb22ebb]I didn't see that I could supply an initial color any other way. If there is one, I'm open to change!

and the callback that populates other controls is:

	integer function track_mouse_autocad()
	USE MSWIN
	INCLUDE 'CONFIG_AUTOCAD_COMMON.INS'
	INTEGER:: I,J,K,RR,GG,BB
	CHARACTER*20:: REASON
	INTEGER:: USER_DATA,HANDLE
	HANDLE = CLEARWIN_INFO@('CALL_BACK_WINDOW')
	REASON = CLEARWIN_STRING@('CALLBACK_REASON')
	SELECT CASE (REASON)
		CASE ('MOUSE_MOVE')
			USER_DATA = CLEARWIN_INFO@('USER_DATA')
			USER_DATA = MOD(USER_DATA,1000)
			IF(LAST_COLOR.NE.USER_DATA) THEN
! PICK UP THE INFO REGARDING THE COLOR
				PRINT *,USER_DATA
				call retrieve_color(USER_DATA,   RR,  GG,  BB) ! to verify
				AUTOCAD_COLOR(1) = RR ; AUTOCAD_COLOR(2) = GG ; AUTOCAD_COLOR(3) = BB
				CALL WINDOW_UPDATE@(AUTOCAD_COLOR(1))
				CALL WINDOW_UPDATE@(AUTOCAD_COLOR(2))
				CALL WINDOW_UPDATE@(AUTOCAD_COLOR(3))
				AUTOCAD_INDEX = USER_DATA
				CALL WINDOW_UPDATE@(AUTOCAD_INDEX)
				LAST_COLOR = USER_DATA
			ENDIF
		CASE ('MOUSE_LEFT_CLICK')
			CALL SET_MOUSE_CURSOR_POSITION@(HANDLE,0,0)
			I = SETFOCUS(FOCUS_CONTROL)
	END SELECT
	track_mouse_autocad = 1
	return
	end

One of the problems with this was I wanted the user to be able to see the color choices as they scanned the cursor over the swatch area. This causes a problem if the user moves the cursor over the swatches to select other controls, the selection changes. So, I have some additional work to do to make the user interface a bit more seamless (like taking the mouse_left_click and making that the selection criteria, not just scanning over the colors).

Ultimately, when the user chooses to change the color, I will use the UID to draw the new color over the old one, thus showing the change. I've already tried that out in some test code, works great! But for that, I have to have the UID to select the color to be updated.

        k=select_graphics_object@(clearwin_info@('USER_DATA')+1000)
        call draw_filled_rectangle@(0,0,24,24,color(i))
        call perform_graphics_update@()

Being able to use the system dialog for color is great. I was also wondering if (somehow) the initial RGB color setting can be applied to that dialog so the user is at the appropriate starting point for doing a color change. That would increase its usability immensely, especially for my application!

Bill

I don't have time to analyse your code right now but I will look at it when I can.

As I recall, the colours in the Choose Color dialog can in theory be preset but not at the moment via ClearWin+. However, they are saved between one call and another within a given session.

It should be fairly easy to add something to ClearWin+ that allows you to preset the custom colours.

Paul, the Choose Color addition of setting the original would be fantastic! I look forward to that capability.

As far as my %gr code, what you see is pretty complete, but not 100%. I can envision a few ways to get the same results without having the UID specifically, but it sure does make life easy!

Perhaps even a %lc would work......

Bill

I have had a look at your code but I am not able to deduce anything from it.

Just to clarify, the colours that can be preset (by my adding a routine to ClearWin+) are the 16 'Custom colors' and not the 'Basic colors'.

Paul,

Given a break in my schedule, I can come up with a simple example of how the code works with the %gr and 'uid' working in coordination.

Being able to attach 'user data' to the %gr is what makes it all work well; I don't need to know where the graphic object is placed because I have an identifier attached to it, and that's what I use.

Rather than setting the initial colors 'manually' by creating the winio@() command on the fly, I could have used a %ps callback function to initialize the objects. Either way it's working well in the development cycle.

Bill