 |
ReedN
Wizard
Joined: 04 Jan 2006
Posts: 1279
Location: Portland, Oregon
|
 Posted: Mon Mar 09, 2009 7:48 pm
(Fixed) [3.04] #capture not working correctly with #cw
|
I'm seeing some irregularities with #capture combined with #cw applied within an #if statement.
Procedure:
| Code: |
1) Start Cmud and create a new session called 'Test'. Enter 'Test' off-line.
2) Copy the xml code below and save it into a file.
3) Open the Settings Editor and import the xml code from the file saved above.
4) At the command line run 'runme'.
Errors:
Compare the text in the Main window to the text in the 'cap_win' window. You should see that lines 7 and 10 differ in their hilighting.
Line 7: The final 'One' should have a foreground color of blue and a background color of firebrick (like in the main window), but in the cap_win window it has a gray foreground and the standard black background.
Line 10: The final Four should have a background color of firebrick (like in the main window), but in the cap_win window it has the standard black background.
|
Code:
| Code: |
<?xml version="1.0" encoding="ISO-8859-1" ?>
<cmud>
<window name="Test" width="1091" height="853">
<uid>{E4EB427A-81A9-4ACA-AEBA-4A578849F83F}</uid>
<packages>English Keypad|English Directions|Clickable URLs|Test</packages>
<class name="Test">
<trigger priority="80" case="true" repeat="true" regex="true">
<pattern>\b(@var1)\b</pattern>
<value>#if (%ismember( %1, @var3)) {#cw blue,firebrick} {#cw blue,gray}</value>
</trigger>
<var name="var1" type="StringList">One|Two|Three</var>
<var name="var2" type="StringList">Four|Five|Six</var>
<var name="var3" type="StringList">One|Four</var>
<trigger priority="80" case="true" repeat="true" regex="true">
<pattern>\b(@var2)\b</pattern>
<value>#if (%ismember( %1, @var3)) {#cw green,firebrick} {#cw green,gray}</value>
</trigger>
<trigger priority="130" case="true" regex="true">
<pattern>^Line with [A-Z][a-z]+ and [A-Z][a-z]+</pattern>
<value>#cap cap_win</value>
</trigger>
<alias name="runme">
<value>#show Line with One and None
#show Line with Two and None
#show Line with Three and None
#show Line with Four and None
#show Line with Five and None
#show Line with Six and None
#show Line with One and One
#show Line with One and Two
#show Line with One and Three
#show Line with One and Four
#show Line with One and Five
#show Line with One and Six
#show Line with Six and Six</value>
</alias>
</class>
</window>
<window name="cap_win" dockalign="Top">
<uid>{FAD4BD2E-AD4F-41B2-8332-C7315CCD5E09}</uid>
<dockuid>{E4EB427A-81A9-4ACA-AEBA-4A578849F83F}</dockuid>
<packages>English Keypad|English Directions|Clickable URLs|Test</packages>
</window>
</cmud>
|
|
|
Last edited by ReedN on Sat Apr 18, 2009 7:13 pm; edited 1 time in total |
 |
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Mon Mar 09, 2009 8:57 pm
|
Doesn't actually have anything to do with the #IF statement. It's an obscure bug with the #CAPTURE command with different background color combinations. This is a complex bug that has the potential to screw up ANSI and MXP parsing a lot, so I'm not going to get this fixed in the quick release later this week, sorry. But I'll put it on the bug list for the future.
The bug is in the routine that tries to recreate the ANSI and MXP color codes from the existing line on the screen in order to capture it. So this bug will also effect HTML logging as well. |
|
|
|
|
ReedN
Wizard
Joined: 04 Jan 2006
Posts: 1279
Location: Portland, Oregon
|
Posted: Tue Mar 10, 2009 6:21 am
|
Your explanation makes a lot of sense. I had noticed this years ago, I guess I should have posted about it earlier. At the time I had just assumed that only capturing of standard ansi colors was supported, so I just chose all standard ansi colors for all my hilighting. My eyes finally just couldn't take the standard colors against a black background and that led me to start playing around with this again.
|
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Tue Mar 10, 2009 5:07 pm
|
The ability to capture MXP colors is a relatively new feature in CMUD. Older versions never did it, and zMUD still only captures ANSI colors.
|
|
|
|
|
ReedN
Wizard
Joined: 04 Jan 2006
Posts: 1279
Location: Portland, Oregon
|
Posted: Thu Mar 12, 2009 6:08 pm
|
| Zugg wrote: |
This is a complex bug that has the potential to screw up ANSI and MXP parsing a lot, so I'm not going to get this fixed in the quick release later this week, sorry. But I'll put it on the bug list for the future.
|
With the quick release out the door do you anticipate fixing this for the next release? If I were allowed to pick just one bug to be fixed of the dozen or so bugs I've reported, it would be this one. |
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Thu Mar 12, 2009 6:21 pm
|
It's on the list, but I can't promise anything. And I have to be very careful with this part of the ANSI/MXP code since it's very easy to introduce new problems that would effect more people. Right now this doesn't effect many people because it only effects #capture windows, and only when multiple words are replaced with multiple colors using different background colors. So even though it's important to you, it really is pretty obscure.
|
|
|
|
|
ReedN
Wizard
Joined: 04 Jan 2006
Posts: 1279
Location: Portland, Oregon
|
Posted: Fri Mar 13, 2009 3:42 pm
|
Ah, things are making more sense now. I thought I was seeing this occur every line in my capture window, but it turned out to be a new bug.
Originally I used only standard ansi colors on anything that would be captured to another window. However, this was very hard on the eyes because some of the ansi colors are very difficult to see on a black background. So I came up with the idea of hilighting the difficult ones with a white background to help contrast the colors and make them easier to see. This is when I ran into the first bug I posted about which was subsequently fixed. After I avoided the first bug by going to the color ivory I ran into this bug because I'd occasionally have two items on the same line with different background hilighting. Around this time I also had the idea to start using MXP colors to obviate the need to use an ivory background color. MXP had enough colors I could choose all unique colors that all had very excellent visibility against the black background. So I switched over to the new colors and got rid of the 2nd background coloring. Now I was seeing everything with an MXP color disappear when captured to a new window. I had assumed I was still dealing with bug #2, because that was similar to the behavior I was seeing when debugging it. When I read your post above I was a bit incredulous about your assertions since I seemingly saw this every line. However, once I started testing it out it became obvious it wasn't bug #2, but a new one, bug #3, which I've posted about in a separate topic. |
|
|
|
|
Caled
Sorcerer
Joined: 21 Oct 2000
Posts: 821
Location: Australia
|
Posted: Fri Mar 13, 2009 11:38 pm
|
Whenever I install a new version of CMUD I go through and change three of the foreground colours to be readable on a black background.
Prefs>Ansi colours>Foreground
I change:
#4 to an orange colour
#9 to a lighter blue, somewhere between it and ansi #11
#5 to a really light purple, lighter even than ansi #13
Of course, this was easier in zMud, when I could save this to a *.col file to reload next time, or share with friends. *nudge Zugg* |
|
_________________
Athlon 64 3200+
Win XP Pro x64 |
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Mon Mar 16, 2009 5:30 pm
|
You shouldn't need to change this every time. These colors are saved with your session in your *.PKG file for the session, so updating CMUD shouldn't be changing it.
If you want to change your default color, just create your own package, like "MyCustomColors" and then add this package to the list of auto-loaded packages (like the English Directions, English Keypad, etc). To edit the colors in this custom package, go to the Preferences screen, and access the hidden menu in the upper-left corner to select your MyCustomColors package and then change the colors there.
You can also change these colors via the %prefs function, although that's a bit obscure.
Saving/restoring colors to a *.col file is on the to-do list since I added the new xterm 256 color support, but I'm waiting till I add the screen that will allow you to customize all 256 colors. |
|
|
|
|
ReedN
Wizard
Joined: 04 Jan 2006
Posts: 1279
Location: Portland, Oregon
|
Posted: Tue Mar 17, 2009 1:34 am
|
| Zugg wrote: |
You shouldn't need to change this every time. These colors are saved with your session in your *.PKG file for the session, so updating CMUD shouldn't be changing it.
If you want to change your default color, just create your own package, like "MyCustomColors" and then add this package to the list of auto-loaded packages (like the English Directions, English Keypad, etc). To edit the colors in this custom package, go to the Preferences screen, and access the hidden menu in the upper-left corner to select your MyCustomColors package and then change the colors there.
You can also change these colors via the %prefs function, although that's a bit obscure.
Saving/restoring colors to a *.col file is on the to-do list since I added the new xterm 256 color support, but I'm waiting till I add the screen that will allow you to customize all 256 colors. |
You lost me on some of your steps:
1) What's the best way to create an extra package "MyCustomColors"? Create a new session and rename the blank package?
2) So the only thing this package will contain are the changed colors?
3) Once the colors are changed in the new package, they automatically take preference over my normal colors defined in the default package? How is this conflict handled?
4) Since simply changing the colors in the main package seems to do the same thing, ie save the colors in a package. What was the advantage of using a separate package to do this?
Regarding the %pref(id, value) command, I see these IDs (ForeCol0-15), what would the value options be? An MXP code or an RGB code? |
|
Last edited by ReedN on Tue Mar 17, 2009 2:35 am; edited 1 time in total |
|
|
|
Dumas
Enchanter
Joined: 11 Feb 2003
Posts: 511
Location: USA
|
Posted: Tue Mar 17, 2009 2:31 am
|
1) When you choose New Package in the settings editor, it saves it as a .pkg file. You just add this to the auto-loaded packages for your session from the edit session screen.
|
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Tue Mar 17, 2009 4:45 pm
|
The color values for %pref are actually a BGR color value (that's what Windows actually uses internally rather than RGB).
As far as how the color takes precedence: if a session sets the preferences to the default values (reset to Default button in pref screen), then your session will use whatever value is in the previously loaded package. CMUD loads the DEFAULT.PKG file first, which contains the base defaults. If you tell it to then load your MyColors package, that will change the default colors. You'll need to set your session colors back to default to see the change, otherwise your session colors will also override any previously loaded package.
The advantage of using a separate package is that you can change the default colors for *all* of your session (at least the ones that use the default values). You can also change the DEFAULT.PKG file directly (or by using the Set as Default button in the Preferences). |
|
|
|
|
ReedN
Wizard
Joined: 04 Jan 2006
Posts: 1279
Location: Portland, Oregon
|
Posted: Sat Apr 18, 2009 4:33 pm
|
Confirmed fixed in 3.06.
|
|
|
|
|
|
|
|
