Archived Beta Discussions > SlickEdit 2019 v24 Beta Discussion

c++ color coding issues

(1/2) > >>

1: While the color coding is being applied to c++ code, if I scroll I can end up with sections of code that are not colored. It's gotten bad enough that I've had to map a key to disable/enable color coding. (I use relaxed symbol lookups)

I get the feeling that when it takes multiple passes of colorLines to get through the DBS_GET_SYMBOLS stage we end up passing in different startLine and endLine and the stateInfo gets screwed up. I haven't been able to prove my suspicion yet though...

I created a regex color analyzer for log/trace files that uses a very similar process. I actually use a dumbed down version of determineLineRangeToColor() as well as an instance of LineNumberRanges to keep track of my coloring analysis. I limit mine to determining/coloring/adding to number rage in a single pass and haven't seen this issue with my macros; but it is persistent daily with symbol coloring.

Obviously I a bit of a noob with SE coloring macros so take my gut feel with a giant grain of salt...

2: Is there any thread safety between symbol color updating and how it modifies p_window_id and running macros that modify p_window_id (specifical callbacks from timers)? My regex color analyzer runs off a timer for its passes currently and I've seen a few times where my coloring is getting applied to another buffer, presumably my macro is running on a buffer and symbol coloring times out and runs out and calls _UpdateSymbolColoring on a particular window.

The symbol coloring is not threaded, so this has nothing to do with threads (we can't thread it because it calls code that isn't thread safe yet).

I will try to create a test file and see if I can reproduce the issue.

One thing to remember is that sometimes Symbol Coloring will not update because it gets pre-empted by more pressing operations, like background tagging.  If we are busy building or updating a tag file in the background, Symbol Coloring will shut down until that is done.  So it can seem like it isn't working, but it really is just not working "yet".

1: For the first issue

--- Quote --- If we are busy building or updating a tag file in the background, Symbol Coloring will shut down until that is done.  So it can seem like it isn't working, but it really is just not working "yet".
--- End quote ---
I don't believe that is the issue. The _UpdateSymbolColoring() function returns visible current, off-screen current, visible other, off-screen other. I'm seeing a visible chunk being colored, but not containing the whole visible area. Say I scroll up 10 lines, those 10 lines are not colored when coloring finally appears. Then I see on the mini-map the above code colored and then below being colored without the entire visible chunk being updated. I can scroll all over but that chunk (10 lines in the example) will never be colored until symbol coloring is forced reset for the buffer.

2: For the second issue I'll rephrase my question. Is the thread used for calling pfnCallback parameter of _set_timer() the same as the one that is doing the symbol coloring? If not, are they guaranteed to not be called at the same time to protect overwriting p_window_id? My timer function scans through all showing buffers and applies some coloring to the ones that contain a certain unique BufferInfo key (much like symbol coloring does). If the timer function is being called at the same time as symbol coloring, I believe they could each be overwriting each other; causing my timer function to 'switch' to a different buffer mid process.

Slick-C does not support multiple threads.  Timer callbacks also run on the main thread.

FWIW, I just reproduced the problem.  This will be difficult to debug, because it takes a lot of scrolling around and trickery to even make it happen.  Expect the fix to come in a hot fix to 24.


[0] Message Index

[#] Next page

Go to full version