U++ forum: Welcome to the forum

Search on this site

Search in forums

Home » U++ Library support » U++ Widgets - General questions or Mixed problems » DropList color is the same when editable or not

Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend

DropList color is the same when editable or not [message #31924]

Thu, 07 April 2011 18:33

koldo
Messages: 3435
Registered: August 2008

Senior Veteran

Hello Mirek

Now when DropList is not editable it has the same background color as if it is editable.

To solve this a possible way could be in method void MultiButton::Paint(Draw& w) to put this in line 412:

		if(HasFocus()) {
			paper = SColorHighlight();
			text = SColorHighlightText();
		} else if (!IsEditable()) 		// Added
			paper = SColorFace();		// Added
		else
			paper = SColorPaper();

Best regards
Iñaki

Report message to a moderator

Re: DropList color is the same when editable or not [message #32025 is a reply to message #31924]

Sun, 17 April 2011 21:59

mirek
Messages: 14257
Registered: November 2005

Ultimate Member

Fixed, using consistent coloring with EditField.

Report message to a moderator

Re: DropList color is the same when editable or not [message #32077 is a reply to message #32025]

Wed, 20 April 2011 13:56

rylek
Messages: 79
Registered: November 2005

Member

Hi there!

After analyzing the the situation I agreed with Mirek to rewrite MultiButton coloring code using style information. I added the following style member variables in analogy to EditField:

		Color paper;
		Color hot_paper;
		Color pressed_paper;
		Color focus_paper;
		Color readonly_paper;
		Color disabled_paper;
		Color text;
		Color focus_text;
		Color disabled_text;
		Color readonly_text;

Thus no color constants are hardcoded anymore in MultiButton and all can be fully customized.

Regards

Tomas

Report message to a moderator

Re: DropList color is the same when editable or not [message #32093 is a reply to message #32077]

Thu, 21 April 2011 20:32

mirek
Messages: 14257
Registered: November 2005

Ultimate Member

Unfortunately, I had to revert these changes, as they are fundamentally incompatible with Win7 and most Linux styles, where MultiButton background is painted by system, so paper has to be Null...

Report message to a moderator

Re: DropList color is the same when editable or not [message #45988 is a reply to message #32093]

Wed, 10 February 2016 01:05

jfranks
Messages: 36
Registered: September 2014
Location: Houston, Texas

Member

Mirek,

We just ran into this same issue with snapshot 9251 running
on Linux Mint distro.

We have migrated an app based on Upp 2007.1 into 9251 and have
found behavioral issue in DropList as described in this topic.

We've had to resort to not only making the control not editable,
but now we have to disable it also in order for it to have the
look-and-feel that matches the behavior of the older library.
However, there are over 500 more places where this change needs
to be made in our code.

We hope that the DropList behavior can be changed so that we
don't have this large edit to make in our app code.

Please let us know what you think.

-- Jeff

Report message to a moderator

Re: DropList color is the same when editable or not [message #45991 is a reply to message #45988]

Wed, 10 February 2016 18:11

mirek
Messages: 14257
Registered: November 2005

Ultimate Member

Please tell me more, as "same issue" can be interpreted multiple ways here. Maybe screenshot of what you see and description what is wrong with it with perhaps a code snippet...

Also, Mint version and theme used.

(Mind you, this thread is 5 years old...)

Mirek

Report message to a moderator

Re: DropList color is the same when editable or not [message #45992 is a reply to message #45991]

Wed, 10 February 2016 19:46

Klugier
Messages: 1099
Registered: September 2012
Location: Poland, Kraków

Senior Contributor

Hello,

I have notice some problems with Standard theme. I attached screenshot:

index.php?t=getfile&id=4933&private=0

This is the problem? In this case "Platform version", "Build tools version", "Toolchain" and "C++ runtime" should be gray when they are disabled.

Sincerely,
Klugier

Attachment: StandardTheme.png
(Size: 58.50KB, Downloaded 628 times)

U++ - one framework to rule them all.

[Updated on: Wed, 10 February 2016 19:48]

Report message to a moderator

Re: DropList color is the same when editable or not [message #45993 is a reply to message #45991]

Wed, 10 February 2016 20:11

jfranks
Messages: 36
Registered: September 2014
Location: Houston, Texas

Member

Mirek,

Thank you for responding so quickly.

Attaced are two screen shots of the DropList issue we are experiencing.
----
Exhibit-1 is a screen shot of our application that uses Upp library 2007.1
running on a older Ubuntu 10.4 LTS distribution.

Note that the DropList controls that are set editable = false provide
feedback to the user because of the different darker color.
The DropList control that are set editable = true are the "normal" color
and indicate that the control can be changed by the user.
----
Exhibit-2 is a screen shot of our application that uses Upp library snapshot
9251 running on Linux Mint Mate 17.3.

The behavior of DropList controls is different from Exhibit-1 in that those
controls set to editable = false provide no feedback to the user that the
control cannot be changed by the user, i.e., they all look the same whether
they can be edited or not.

The expectation is that when the control is set editable = false, that the
color would be darker to indicate it cannot be selected.

One work-around is that we have found is to set the DropList control disabled = true,
then the control has the proper visual look that indicates it cannot be edited, and that works.
These exhibits are from one of many pages in our application that have DropList controls.
There are roughly ~500 occurances in our code where we would have to modify our application to make the control
have the proper behavior.

And so . . .
We are looking for remediation of this issue in the Upp library itself so that we are
not faced with all those edits in our application.

BTW: I used this old thread because it is identical to what we are seeing now.

-- Jeff

Attachment: Exhibit-1.jpg
(Size: 18.77KB, Downloaded 310 times)
Attachment: Exhibit-2.jpg
(Size: 23.70KB, Downloaded 300 times)

Report message to a moderator

Re: DropList color is the same when editable or not [message #46061 is a reply to message #45993]

Fri, 26 February 2016 13:24

mirek
Messages: 14257
Registered: November 2005

Ultimate Member

It looks like you have the application in "Standard" theme (not the one that picks appearance from the host platform). Is that correct?

If so, I can certainly fix the "Standard". Just need to know whether I am chasing the right thing.

Mirek

Report message to a moderator

Re: DropList color is the same when editable or not [message #46064 is a reply to message #46061]

Fri, 26 February 2016 21:31

jfranks
Messages: 36
Registered: September 2014
Location: Houston, Texas

Member

Mirek,

Attached is our setup for the IDE.

GUI theme is set to "Host Platform".

-- Jeff

Attachment: ideSettings.png
(Size: 374.85KB, Downloaded 328 times)

Report message to a moderator

Re: DropList color is the same when editable or not [message #46128 is a reply to message #46064]

Sun, 13 March 2016 19:27

mirek
Messages: 14257
Registered: November 2005

Ultimate Member

Hopefully fixed.

I have created a simple upptst/TestChStyle example to test this. Looks ok in Win32 and Linux, with Std/Classic/Host skins.

Report message to a moderator

Re: DropList color is the same when editable or not [message #46131 is a reply to message #46128]

Mon, 14 March 2016 16:11

jfranks
Messages: 36
Registered: September 2014
Location: Houston, Texas

Member

Mirek,

Thank you so much.

Can I get the fix you made from a nightly build?

-- Jeff

Report message to a moderator

Re: DropList color is the same when editable or not [message #46132 is a reply to message #46131]

Mon, 14 March 2016 19:26

mirek
Messages: 14257
Registered: November 2005

Ultimate Member

Yes, it should be in latest one.

Report message to a moderator

Previous Topic:	GetRectInParentWindow for all backends
Next Topic:	why the ctrl does`t have HWND?

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

] [

]

Current Time: Sat May 10 13:46:04 CEST 2025

Total time taken to generate the page: 0.04009 seconds