Hatched Background in item list

I have a list of items for selection, within which the developers, bless their pointed little heads, have decided that each of the line items will be displayed with an alternate shaded or plain white background, and the shaded background seems, through RDC, to be hatched.

If I select and use item 3, which might happen to have been rendered against the plain white background, all of the following items will then be moved up a place in the list, and their backgrounds will be changed, with those that were against a white background now being rendered against a shaded background, and vice versa.

Any thoughts about how this should be handled? In particular, the hatched background?

Ewww. Yeah that’s ugly.

Now typically the standard tolerance will deal pretty well with a highlight shading (a light grey, blue or something like that).

But in your case with the “hatch pattern” it’s actually turning white pixels into black ones and so that won’t do.

First, is there any way to increase the RD “color depth” to convince it to do something a little less obtrusive?

The other suggestion I have is to use “pixel discrepancy” which will allow either an absolute amount or a percentage of pixels to just completely fail. Using this search tends to be a bit slower than other types and so you might want to combine it with a restricted search rectangle. If you haven’t yet tried using the “Image Doctor” I would recommend doing so because it tries a modest “pixel discrepancy” setting as part of it’s heuristic.

If those don’t work then the Redstone team here might have to put our pointy little heads together and try to come up with something clever to compensate for that.

Yes, and there’s enough other similar lists within the application that are being more correctly rendered.

First, is there any way to increase the RD “color depth” to convince it to do something a little less obtrusive?

Already at 24 but, and I’ve also tried it through a couple of different connection routes, but with no change in the manner by which this is rendering.

The other suggestion I have is to use “pixel discrepancy” which will allow either an absolute amount or a percentage of pixels to just completely fail. Using this search tends to be a bit slower than other types and so you might want to combine it with a restricted search rectangle. If you haven’t yet tried using the “Image Doctor” I would recommend doing so because it tries a modest “pixel discrepancy” setting as part of it’s heuristic.

I will have a play in this realm then, but given that I have a number of other similar lists that are being rendered in a more compliant/standard manner, I have also referred this one back to the development team on the basis of it being inconsistent with the way the rest of the application runs.

If those don’t work then the Redstone team here might have to put our pointy little heads together and try to come up with something clever to compensate for that.

Let’s wait till I get a reaction from my dev team, and my further playing, first of all.

Another thing to try (this has helped us a bit with some nasty lists like this) is to make another text style (in preferences) with a different background color, one that more closely resembles the hatching, and search for it, if the first search fails:

try
    if imageFound(text:"Some Text", TextStyle:"Default")
       click foundImageLocation()
    end if
catch e
     if imageFound(text:"Some Text", TextStyle:"Hatched")
       click foundImageLocation()
    else 
       throw e
    end if
end try

Hope this is useful

If you are doing developer driven development, then maybe it is time to fire those allowing or driving that kind of decision process. If that fails, then maybe you could hold a GUI or CHI bible in the next meeting up for all to see, and talk about some standards that work. Zebra striping is helpful, in some cases where wide rows or similar names are common. However, the research out now shows that zebra stripping is not all that it once was thought to be cracked up to be. In your case, with a fairly small width it would make sense to get rid of it all together. It likely serves no purpose other than to make someone get a pat on the back by someone else higher up that read something about striping or attended a webapp dev tutorial online at youtube.com :slight_smile:

I wish.

The situation is that I come from a development background, but I’m the test manager in this particular project.

I’m working with a project management consultancy that is managing this project for their client, and the development is being handled by a different party to whom I’ve been basically denied direct access.

I suspect that is because I ask too many questions, and can can call them when I think they’re talking BS. Which seems to be a lot of the time. :slight_smile: Without wishing to blow my own trumpet, I suspect they view me as a threat …

If that fails, then maybe you could hold a GUI or CHI bible in the next meeting up for all to see, and talk about some standards that work.

I’ve already called them on a couple of standards compliance issues, (or their failure to comply with some well accepted standards) and for some reason, they didn’t seem to appreciate that. :slight_smile:

In your case, with a fairly small width it would make sense to get rid of it all together.

That’s exactly the approach I’ve taken. I’ve put that to the powers that be, and am now waiting on their response.

What’s quite amusing in this one is that they have said that the problem lies in the way that I’m accessing the system (via RDC) and as such, this is beyond their control.

That totally avoids the fact that I can point to a half dozen other listboxes that otherwise appear to be identical, including the banded backgrounds being correctly rendered, that I can access in exactly the manner that they say is the source of the problem, without this hatching.

Clearly, there must be underlying differences between the versions of the control that work fine, and those that do not, but they refuse to see that.

It seems to me that this is just a property of the listbox control that has been (incorrectly) set by the GUI developer, and should be dead easy to fix. However, because these people are so defensive in their approach (and they have their heads stuck so far up their … ) that they don’t want to see or understand what the issue is.

I’d like to suggest that they’re a bunch of morons, but I think that it’s “Be Nice to Morons Week” this week. :slight_smile:

Any suggestions as to what a suitable background colour might be? I’ve not found one as yet, and I’m open to suggestions, please.

The dots in the image you posted are a light grey, not black, so I suggest you try a very light grey, maybe (210,210,210) or so. I assume you are using generated text images here, which automatically use the “text” search type, so I think you should have a good chance of making this work.