The attached image represents a progression of new projects within one drawing. Each new project is always red. Each project after that is assigned a color. Each revision block you see from left to right is how the revision would appear in a separate drawing version of the same drawing, new project.
So there is a green revision (drawing start). Brand new drawing, the project doesn't get a color, it stays bylayer.
Rev#1 is red
New project starts, Rev#1 becomes color 56, Rev#2 becomes red.
New Project starts, Rev#2 becomes color 107, Rev#3 becomes red.
New Project starts, Rev#3 becomes 136, Rev#4 becomes red.
Most times you might see two colors, but can have as many as 5 projects running within the same drawing at one time. Think of them as chronological revisions.
Using color routines I hunt for RED mtext entities and change them to the next revision color.
Sadly, some of our users insist on overwriting Mtext color. Hence the code below. You might note that I'm exacerbating the mtext color overwrite issue buy using this piece of code as C1 becomed C136, not 1 and 136 per the properties color palette.
I need to find a way to either strip the overwritten Mtext of just one of the colors while leaving the other colors alone during the change from RED (above code) to that new revision color, or better still strip out the overwritten C1 color and then change it to the next color. The overwritten color issue always starts with RED.
For now I'm just adding this to the end of each "return to bylayer" routines.
(Alert "Some MText may have not be returned to it's bylayer color. Select them now") (StripMtext
(ssget) "c") ;;select all red text not changed by routine.