After re-reading the comments in the script, maybe I misunderstood something.

Static color assignment, i.e. the colors will be assigned permanently to the row contents rather than to the row number.

I was under the impression this would mean I could move a row up/down and the custom background color would stick? or am I wrong?

Also, I can't seem to find any real examples on how to properly use this script. All the comments in this thread have different code (some labeled as "no longer needed"). Where can I find the 'up-to-date' usage information?

My description may be confusing, but I don't know any better. The colors are 'tied' to the item at the moment it is added to the LV.

I don't know a way to 'move' items within a LV except the built-in sort. In all other cases you most probably delete the original item and add/insert a new item. So the connection between the item and the colors get's lost if you don't renew it.

Hi just me,I'm using a single-column LV_Colors to implement what I call the Processing Console, which gives the user feedback as the program is processing (mentioned in this previous post). One of the menu items in the program allows the user to copy the contents of the Processing Console to the clipboard. Here's the code snippet for it:

It works well, but does not get the colors. The AHK doc says that ClipboardAll (rather than Clipboard) "contains everything on the clipboard, such as pictures and formatting", which would presumably include colors, but ClipboardAll cannot be on the left side of an assignment statement. How can I can get the rows, including the colors from LV_Colors, to be on the clipboard so that a user can Paste them into a program that handles color? Thanks very much, Joe

No chance to do it automatically! As the name implies LV_GetText() gets only the column text. Also, the colors are only used internally for drawing, not as text attributes which could be interpreted by other programs.

Ive got an issue where when running my compiled program(in x86) on 32 bit machines, the color in the listview rows does not maintain its proper width when being resized(single column listviews - colors span the listview width). It does work fine though when im running the program on an x64 PC.....any ideas why that would happen?

Everything works great except for on these 32bit PC's. All running Win7.

Hi just me,Something strange is happening with LV_Colors that I'm hoping you can explain. As mentioned earlier, I'm using a single-column LV_Colors to implement what I call the Processing Console, which gives the user feedback as the program is processing. One of the menu items in the program allows the user to clear the contents of the Processing Console. The code for that is simply LV_Delete().

In case the user accidentally clicked Clear Processing Console, there's a menu item Restore Processing Console. What that does is read a plain text logfile that has the text-only contents of the Processing Console. The code for that is:

Now here's what's strange. Since the logfile is plain text, I would expect there to be no colors in the restored Processing Console (i.e., just the default text and background colors). But there are colors! The colors are on the "wrong" rows, that is, not where they were before the Clear Processing Console was issued, but why are there any (non-default) colors at all? I'd rather have there be no colors on rows (just the default text and background colors) rather than the wrong colors. How would I do that? Thanks, Joe

Update: It's even stranger than I thought. Turns out that the reason for the colors being on the "wrong" rows is that I put out new messages in the LV that say, "Processing Console cleared on..." and "Processing Console restored on...". So the row numbers in the cleared LV don't match the row numbers in the restored LV. When I stop writing out the "Processing Console cleared on..." and "Processing Console restored on..." messages, the row numbers match — and, guess what? — the colors (text and background) are right! This means that LV_Colors is somehow retaining the text and background colors of previously added row numbers. I'm actually thrilled about this, but I don't understand what's happening under the covers. I'm sure you do, and if you could take a moment to explain, I'd appreciate it. Regards, Joe

LV_Colors() keeps its own color array. In the default 'non-static' mode the array is indexed by the row numbers. In 'static' mode an internal ID is used instead which (according to the MSDN) is unique for each row for the lifetime of the control.

LV_Delete() does not touch this array. So subsequently added rows will use the stored colors if their row numbers are contained in the array. To clear the whole array you have to call LV_Colors.Clear().

AHK 1.1.22.09 32-bit Unicode (reluctant to go to 1.1.23.05 because of this issue)W7 Pro 64-bitLV_Colors 1.1.03.00/2015-04-11

Hi just me,As you know from my previous posts, I'm using a single-column LV_Colors to implement what I call the Processing Console, which gives the user feedback as the program is processing. I've been troubleshooting a problem where the program hangs, and I've been able to isolate the problem as being related to LV_Modify when using LV_Colors. The whole script is fairly large (more than 1,500 lines) but I created a small script that reproduces the problem:

When you do a File>Run on the above, it will eventually hang. The logfile shows that it returns from the LV_Add and then dies, meaning that it never comes back from the following LV_Modify (unless it's hanging in FileAppend to write the logfile, which I think is highly unlikely). It dies at different places — I ran it ten times and it hung at these rows (random, as far as I can tell):

The two scripts are identical except for the six commented out lines relating to the use of LV_Colors. It processed all 10,000 iterations without hanging — four times!

Maybe I'm calling LV_Colors incorrectly, but I'm hoping you can help me figure this out as my users find the colors in the Processing Console to be extremely helpful. But for now I've stopped using colors, as the program's hanging is a show-stopper. Thanks very much, Joe

LV_Colors() has to process WM_NOTIFY notifications sent by the ListView to do its job. It's a known issue that this might cause problems if the contents of the ListView is changing fast. One possible workaround ist to set the LV_Colors object's Critical property to On or another sufficient value (e.g.ColorConsole.Critical := "On"), but Critical might cause its own special issues.

Usually it's best to disable redrawing while adding a large amount of items. But if you have to add single items in rapid sequence this will be no option.

After testing your example I think that the use of GuiControl,+Redraw,%ConsoleHandle% is causing the issue. It will redraw the whole control so notifications for all visible items have to be processed by the LV_Colors object after each added item. I think that you're doing it to update the added item's colors. For me, LV_Modify(RowNumber, "Vis") seems to redraw the item on its own, so it seems to be sufficient to set the colors before it is called:

FileMenuRun:Loop,%Iterations%{ ConsoleRow :="Loop index=".A_Index" at ".A_NowFileAppend,%ConsoleRow%`n,%Logfile%If(ErrorLevel<>0)Goto, FileAppendError ; are you sure you want to 'Goto'? RowNumber :=LV_Add("", ConsoleRow) ColorConsole.Row(RowNumber, ColorBackground, ColorText); set the colors before you call LV_Modify()LV_Modify(RowNumber,"Vis"); scroll LV so newly added last row is visible}Return

It's working here. If it doesn't work for you, we can try other options.

sorting might cause the well-known issues.That's why it is disabled by default. You can change the default by setting NoSort to False when creating the LVObject or you can call LVObject.NoSort(True/False) whenever you need it.

CLV.Row() sets the colors for a specific row whereas CLV.SelectionColor() sets the colors used for the currently selected row(s). Without it the row colors set by CLV.Row()before the row gets selected are ignored.