Lars Fosdal

@havrlisan Report it. Make a video. Describe what we see vs what you expect.

I wonder why I can't access that issue! And... now it works. Make sure to re-enter your creds after time-out 😛

Not sure why the colors for this are not one single color entry, but two. Foreground - Sync edit highlight (it appears only the foreground color is used) Background - Sync edit background (it appears only the foreground color is used) Edit: But no - I don't know why the template "helper" goes away when you switch focus, but the behaviour is the same in 11.1.

No, no, @David Heffernan - What I mean is that I keep the new version away from my regular work cycle until the new unintended features have been discovered - and if those affect our apps, until the first service update arrives. When I am happy that 11.3 is ready to use, having built our apps with it, and gone through the tests, we migrate everything. All of the devs switch version, and the build environment is upgraded. So far, that approach has worked well. As an example, we never upgraded to 11.2, f.x. as it didn't really fix the issues we had with 11.1, and offered little new of use to us. We went from 10.4 to 11.1 as well. We have the luxury of being able to do that, since our software is corporate and not shelf-ware.

@Vandrovnik - Tools | Options | User Interface | Editor - Don't highlight keywords - is checked by default. Also, Highlight words setting offers None, When selected, By cursor. I prefer By cursor.

I just noticed that my 11.3 in the VM compiled my 1.1MLOC project in 36 seconds, while 11.1 in the main OS used 1 min 5 seconds. The main OS has a corporate straight jacket and a ton more processes, though.

I have the new version in a VM until I am satisfied that it won't cause me problems. Only then do I upgrade my "production enviroments".

Not if you use a thread safe queue and the access to the data that needs to be updated are protected with f.x. a critical section, or you only access data that you know will not be touched by other threads. Lets say you have a 500ms timer. If you have activities on the TCPClient that receive data every 50 ms - the UI would still only refresh only every 500 ms The only time you would get an issue with performance in the UI, is if the render takes longer than the timer - but you would not lose any data - and assuming the render contains all the most recent data - it would all be displayed, albeit at your fixed timer frequency. In most cases, throttling the UI updates to refresh less often than the actual data refresh-rate will not be an issue. If your TCPClient thread consumes all your CPU - you have a very different problem. The only way it would be a problem, is if you use UI elements as data storage, instead of having an underlying structure as you should. Divide and conquer. Separate your UI from your business logic.

I agree.

Are we talking about the same highlight?

Drat - I think I got the wrong color >< Nope, it was the right color option.

That was good info, @Dalija Prasnikar! Thank you!

@Stano - In the Tools - Options - User Interface - Editor Options - Color, you can change the color with "Additional search match highlight".

I really REALLY dislike Synchronize. It is a pitfall of pitfalls. IMO, a better approach is: In your thread, send a signal when there is something that needs to be refreshed. That signal can be a queue, and you may want to include info about the type of content change if the UI should do a selective refresh Decide how often the UI should refresh and make a timer in the UI that checks the queue if something should be refreshed You still need to protect access to elements shared by the UI thread and the background threads - but at least you will have FULL control over what the UI draws and when.

The users that get the error - what Windows version do they have?

@bzwirs Do you get a callstack from the IDE?

Big mistake. It is the .dproj file that can be recreated.

Is it possible to make a demo of that problem and report it?

America is awake now, I guess.

There must be something fundamentally wrong with the code flow of that dialog. After the initial component load - why does it need so long to change a filter, complete a search, or even just scrolling down the list a little?

There must be a lot of people are installing today. GetIt UI is slow as heck and server is complaining.

I don't disagree, but a lot of dev tools have these issues. Complex software = complex installations.

Then you should report it to https://quality.embarcadero.com/

Are you using the DPIAware or DPIUnaware mode?