Performance oxygene in visual studio 2019

We are facing problems with oxygene performance in Visual Studio 2019. We sent our solution and video with example to marc in February. I am opening this topic for better monitoring.
I ask you to pay attention to this point, as the actual performance actually makes use unviable. we are willing to collaborate in whatever it takes to help identify what causes it.

To simulate it, just open our project and edit some sample files

UCBOControllerA, b, c, etc

Include new methods, type something in existing methods, see perceive slowness and warnings from the visual studio itself about slowness


Thanx for opening a new thread so we can work on this. my colleague @viktoriad is looking at the issue now, and will get back to you once she knows more. I’m hoping we can have this fixed soon.


We’ve isolated the problem. A full proper fix will take a few days, but with the next build (I can send you one later, but also with tomorrow’s build) you can add the following registry key to temporarily disable the drop-down boxes at the top of the editor; populating them, combined with the huge size of the project, is what us causing the delay.

“DisableDropdowns” = “1”

the key itself should already exist (in 64-bit windows it will be “Software\WOW64\RemObjects\Elements”) and should contain other values, such s “Oxygene”=“1” already. the new value should be a of type string.

hopefully we’ll have a proper fix for next week’s build, or sometime during the next week.

Wow! what good news! as soon as you make it available I do the test here.

if you can put a hotfix already testo to see if it worked in my environment

I should have a finished build for you in a short while.

RemObjects Elements - should be up in your personal downloads now.


In this build that sent you by default I left it disabled, correct?
because I didn’t put the key in the registry and he’s not carrying the combo.

I will ask other team members to validate the performance and give feedback.

Hmm, let me check with Vika. i’m pretty sure you’re supposd to need the setting. But either way, if the combos are disabled that’s good and should allow you to test if the performance issues are either (a) better or (b) completely fixed with this.


Yup, the check was revered by accident ;). fixed for vNext, so only add the setting when/if you update to 2615 tomorrow.

ok -I just realized that it was inverted

1 Like

we could see an improvement in performance when the combos are not refilled.
however we still have problems, example when editing forms (uprogramacaocarga), when we edit sometimes the visual studio closes.
another point is the memory consumption see the print. it is common for visual studio to pass 3GB and ebuild to pass 4.5gb

That seems like a separate issue? do you get any crash report, as dialog or in Event Log?

that might very well be “expected” for a vey huge solution.

1 Like