Color of highlighted line in a report

I have Q2006 Premier H&B and XP and I don't get any highlighting in my Cash Flow report - just an unshaded box around the amount field of the selected item. However I do get the dark blue shading in other reports, e.g. the Transaction report. Still other reports, e.g. the Itemized Categories report, have an unshaded box around the entire line.

The dark blue shading appears to be hard-coded into the Quicken program. It seems to me to be the same color used to highlight items in Quicken menus. For selected menu items the color of the menu item text is inverted to white. That's probably what should be done, but isn't, for selected items in reports.

I think you should report this as a Quicken bug.

Jerry

Thanks for your comments. You are right, the blue highlight doesn't occur on the cash flow report itself. My mistake. However, on the cash flow report, when I double click on one of the line amounts, I get another report that details each transaction that makes up the line item from the cash flow report. It's that report that gets the dark blue highlighting.

As you suggest, I think this must be a bug in Q2006, unless it can be changed by some sort of configuration parameter, perhaps a Windows XP parameter, however I can't find it if it is.

Does anyone know if this is the case in Q2007 as well?

I tried changing the Windows color scheme to no avail. For your reference right-click on an empty area of your display, select Properties, then the Appearance tab. In the resulting Display Properties form you can change the entire Color scheme. Or you can click the Advanced button to change individual items. The relevant item (in the drop-down list under Item:) is "Selected Items". Your item is obviously not under Windows control.

I also looked in Quicken under Edit in the top menu: Edit -> Preferences ->

Quicken Program then click Register in the left pane and then the Colors button in the right pane. As stated in Quicken Help this seems to change only colors in your registers. The available selection of colors are all very light anyway, nothing remotely resembling dark blue. Check this out if you like - you can do some neat stuff here that I didn't know about before.

I also tried Start -> All Programs -> Accessories -> Accessibility ->

Accessibility Wizard, told it I was blind, and selected the High Contrast #1 scheme. This changed almost everything but the report highlighting. Try this if you haven't had your morning coffee - the garish display will give you a real jolt :-)

There might be a way to change the highlighting color if it's specified in the Windows registry but I strongly suspect it's hard-coded in Quicken.

Intuit did a lot of overhauling of the Reports area for both Q2005 and Q2006 and the work is probably continuing. Perhaps it's fixed in Q2007. If not maybe Q2008 if you report the problem.

Thanks for posting any interesting question. Sorry I couldn't find a fix.

Jerry

Thanks for your input. I, too, tried all that stuff but was not able to change the highlight color.

Do you suppose no one else is bothered by the fact that they can't read the DARK blue highlighted line in a report? Seems that this would be SO EASY to fix. I did report this as a bug to Quicken 6 tech support.

Hey, I just got a reply from a support guy at Quicken. He says that there is no way to change the color of a highlighted line and that is true for both Quicken 2006 and 2007. He says that he agrees that the dark blue highlight makes the line difficult to read and will pass a suggestion along to the development group to change the color to be more transparent. I'll be sitting on the edge of my chair waiting for the update. :-)

"John K" wrote

If you want an even better chance of having this acted on, why not report it at the Quicken forums in the Product Feedback forum. If it is as easy as it sounds, I would guess there's a reasonably good chance that it would get fixed in Q2007, for which there will almost certainly be another release (and for Q2006, if there is ever a reason for Intuit to issue another release of it ... I don't think this issue alone would be cause for a new Q2006 release).

"John Pollard" wrote

In case you do decide to report it; your results are different than mine. In my Q2006 Premier, the problem only appears in a very few of all the reports available in Q2006 ... and the Cash Flow report is not one of them. I see the problem in the following reports:

1.) Cash Flow Transactions 2.) Itemized Categories 3.) Itemized Payees 4.) Tax Schedule 5.) Tax Summary 6.) Account Balances

(Account Balances is the oddball as it's the only one where the problem occurs on lines that are not Quicken "transactions".)

(My workaround is to select the line below the one I want to view, then treat the blue band as a sort of underline.)

For large systems even a simple fix is dangerous because it may expose latent bugs in unrelated areas of the product. For a product with Quicken's extensive user community this risk is usually unacceptable unless (a) it fixes an important operational bug or (b) it causes database corruption.

I'm probably more annoyed than most at the new minor bugs that creep up in each new Quicken release. Sometimes I even suspect Intuit of deliberately planting these bugs to get you to buy the next release :-) But I still support Intuit's decision not to fix minor problems before the next product release. You probably have to be a programmer to appreciate this philosophy.

I just select a different line.

If the highlighting appears in a printed report I try to unselect everything or select the smallest possible area in the least needed part of the report.

430 No such article

Hey, I was a programmer for 35 years before I recently retired. Although I sympathize with the fear of fixing a minor bug which might cause some other unrelated failure, it's always been my philosophy to fix these minor bugs whenever I came across them. It has a real positive impact on the user base to see little annoying bugs drop by the wayside. They guy making the fix needs to be more than an idiot when he makes the change to prevent additional errors. Then, of course, regression testing should be performed on each release. Competent programmers finding great difficulty fixing simple bugs without causing unlrelated problems is a reflection of a sick code base and or bad design. I certainly hope this is not the case with Quicken, although some times I wonder.

"Jerry Boyle" wrote

I qualify.

With all the time you spend helping others with their problems it amazes me that you have any time left to do any progrmming ;-)

Any fix, no matter how simple or how carefully made, runs the risk of exposing an uninitialized variable or a program bug that stores a value in the wrong location, e. g. because of an uninitialized or incorrect address pointer. The fact that Quicken is a huge legacy system makes the presence of many such latent bugs almost 100% certain. Sick code base? Bad design? Those are harsh words but they're true for almost any big system that's been around as long as Quicken.

Quicken is the steward of many years of financial data for an enormous number of users. That makes the possible consequences of even the simplest fix enormous. And I don't know what systems you worked on, but on my systems it was very expenssive to run full regression testing. Plus they'd have to retest on every platform that Quicken runs on. Even then you can't repeat beta testing and prior user experience.

If they screw up my financial data to fix your dark blue line I'm coming after both you and them with a hatchet :-) I'll probably be able to find the programmer who did it and manager who authorized it standing in an unemployment line.

Hey, I hear you. I've been there lots of times.

I've been using Quicken since the late 80's and I'm in no hurry to screw things up.

However, fear shouldn't be an excuse for doing a shoddy job turning out a product.

Bet I'll bet you a 6-pack of your favorite brew that chnging the color of a highlighted line in a transaction report isn't rocket science and can be accomplished, by a competent programmer who knows what he is doing, with minimal impact to the honorable Quicken program. The key here is a "competent programmer". There are lots of idiots in the world calling themselves programmers. Even if the guy isn't an idiot, he has to have a clear apprecation of how the program works to mess around changing things. I always figgured that my code should be perfect and perfection was my goal. My code and designs were pretty good in their day. Lots of my peers argued that perfection isn't atainable and therefore should not be sought after. If I guy doesn't shoot for perfection he must be shooting for crap and that is exactly what he'll get.

Just MHO!

:-)

"Jerry Boyle" wrote

After 39 years, one gets pretty good at utilizing time ... or one doesn't survive. ;-)

As one old retired perfectionist to another I must confess that I snuck fixes like this in all the time, even though I was fixing others' code in huge, complicated legacy systems. We agree that all easy-to-fix problems, no matter how minor, should be fixed. But I still claim that these fixes belong in the next version or major release, in this case Q2008. If I see light-blue highlighting in Q2007 I'm comin afta ya John :-)

Hi, John and John and Jerry.

Since we have 3 programmers here, I'd like to digress just a little to ask a programming question:

What's "regression testing"?

I have a vague idea from the name of the term and from the way I've seen it used here and elsewhere. But I haven't done any programming since GeeWhiz BASIC and I didn't run into that phrase there. I hear the term a lot in the Vista beta newsgroups, so I assume it just means that the programmers test to see that their one step forward has not resulted in two or more steps back. I don't need a complete dissertation (the kind I usually post!), but a couple of paragraphs should help me (and other readers) to understand this process.

RC

Hi RC,

You hit the nail right on the head.

It's a set of tests to ensure that fixes and enhancements don't break existing features, i.e. it *prevents* regression.

As enhancements are made and as bugs are discovered by system testers, beta testers and users, new tests are added to the set to ensure that the enhancements and fixes continue to work.

Jerry (of the 3 J's)

Jerry, and you to, RC, is exactly correct.