 |
ReedN
Wizard
Joined: 04 Jan 2006
Posts: 1279
Location: Portland, Oregon
|
 Posted: Wed Jan 21, 2009 6:50 am
(Fixed) [3.03a] #CW with #say has a bug
|
Summary:
When #cw is used on the match of a #say statement it can cause the coloring to extend beyond what it should color.
Instructions:
| Code: |
1) Escape when presented with the sessions to enter a blank session.
2) Copy the xml into the session editor.
3) Run the alias 'go'.
The alias prints out both #say and #show statements to show how #say is done incorrectly.
|
| Code: |
<class name="Test" id="1">
<trigger name="pattern1" priority="40" regex="true" id="4">
<pattern>\b(?:@list)\b</pattern>
<value>#CW gray,firebrick</value>
</trigger>
<trigger name="pattern2" priority="50" regex="true" id="5">
<pattern>\b(?:@list)\b</pattern>
<value>#CW brown</value>
</trigger>
<var name="list" type="StringList" id="6">one|two|three</var>
<alias name="go" id="7">
<value>#show This is example one, which is correct.
#say This is example one, which is incorrect.
#show This is example two following one, which is correct.
#say This is example two following one, which is incorrect.</value>
</alias>
</class>
|
[/code] |
|
Last edited by ReedN on Sat Apr 18, 2009 7:16 pm; edited 1 time in total |
 |
|
|
Fang Xianfu
GURU
Joined: 26 Jan 2004
Posts: 5155
Location: United Kingdom
|
Posted: Wed Jan 21, 2009 8:48 am
|
Confirmed, and it's not to do with having two triggers trying to colour the same thing - you can delete the #cw brown trigger and it'll still bug.
|
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Wed Jan 21, 2009 5:29 pm
|
Confirmed and added to bug list. Looks like it's an issue when Styles are used (the #SAY command outputs the text using a Style for the colors).
|
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Thu Apr 02, 2009 10:36 pm
|
Actually, I tracked down this problem and it is rather complicated. Here is what's going on...
If you open your Preferences and look at the "Information message" style, you will see that the Background Color of this style is "Default". This means that this particular style does not change the background color (it leaves it at the default or previous value). Now, normally this doesn't cause a problem. But in your trigger above, you change the background color of some text to "firebrick". The text that comes after this is styled using the "Information message" style, which says to keep the background unchanged. So the firebrick bleeds into the rest of the text.
You can see this happen simply with the following example:
#mxp %ansi(white,blue)highlighted
The "information text" has the text color changed, but leaves the background color unchanged.
If you edit the Information message style and change the "Default" background to "Black" background, then your above trigger works as expected.
The actual bug here is that the "Default" setting for the style should be using the "Default session text" colors as the default, and not just leaving the previous value unchanged.
I'm still trying to figure out if I can fix this without screwing up the entire ansi/mxp color handling system. The "default" attribute is used a lot internally when I don't want it to change the previous value. For example, when you use something like:
#SHOW Text %ansi(red)red text
the %ansi(red) is actually converted to %ansi(red,default) to preserve the previous background color. So you can see how it can get complicated...I can't just change how "default" is handled because it would break a lot of stuff. So I'll need to look specifically at the Style code and see if I can intercept the Default attribute when processing a Style and convert it to the "Default session text" values. |
|
|
|
|
ReedN
Wizard
Joined: 04 Jan 2006
Posts: 1279
Location: Portland, Oregon
|
Posted: Sat Apr 18, 2009 4:16 pm
|
Confirmed fixed 3.06.
|
|
|
|
|
|
|
|
