Hilite Color disobeyed

Karl Petersen karlpet at mac.com
Sun Apr 7 15:02:01 EDT 2002


At 6:33 AM -0700 4/7/02, Jeanne A. E. DeVoto wrote:
>I've seen this too, intermittently, and it's a known problem (which I
>should have put in the release notes). I think it was determined that this
>is an engine buglet. I'm not sure when it will be addressed.

Thanks for your reply, Jeanne.

I'm really disappointed to hear the text-hilite problem may be an 
engine bug. It occurs about 70% of the time here, and causes any 
stack where the user enters text to be virtually useless. (That's 
especially true when the text hilite color is very dark, which 
usually occurs.) When the user tabs from field to field, for example, 
the field text is unreadable. So too is text selected to be modified 
or Copied. A selected line of a list field cannot be read. Default 
text in Ask dialogs cannot be read. And, of course, the overall 
impression is "buggy software".

As a Revolution newbie, I'm really excited by what I see in 
Revolution, but I'm uncomfortable offering stacks with this feature 
to the general public. This really needs to be fixed, in my opinion.

Maybe this recipe is already known, but I've noticed the script 
editor uses the correct hilite color when opened by the Script tab of 
the Properties palette, but not when you press Command-Option over an 
object. Nor does it work correctly when opened by one of the "Script" 
buttons of the Application Overview window, nor by dragging the 
Script tab out of the Properties palette. So sometimes the script 
window is fine and other times it has the problem, which may make it 
easier to debug. (On the other hand, if they are two very different 
windows it only suggests that one Script window has the problem and 
the other doesn't.)

There's another text-selection issue that need to be addressed too, I 
believe. Selected text should show a different hilite when Revolution 
is in the background. (Mac OS 9.1 here.) As I type in Eudora, for 
example, the selected text of the Revolution window in the background 
looks identical to when it is frontmost. Instead of hiliting the 
text, the text should be framed. (That, or not show a hilite at all 
in the background.) As a newbie, I never know if there's a yet 
undiscovered setting to apply the proper behavior, or if I can safely 
assume the environment controls such behavior. (I spend a lot of time 
searching.)

Karl



More information about the use-livecode mailing list