Some fixes and expermental features added to the Scintilla (SyntaxEditor) Widget

What is the airspace problem?

The Airspace problem is a description for mixing different GUI technologies. In this case, the scintilla control uses natively gdi+ and its own window class and HWND. this window is rendered by gdi+ while the rest of the ui is rendered by UltraEngine.  So to show the scintilla control, it must always been on top of the Ultra Engine-Widgets, which means that the z-Index or order doesn't matter and in the gif you can see that the red overlay is clipped by the scintilla control, while with the redirection to the pixmap this is no problem, because i render the pixmap natively in UltraEngine and the original Scintilla Window is hidden. The term mostly comes from WPF and WinForms: https://adityaswami89.wordpress.com/2014/02/24/airspace-problem-wpf/

I'm doing the same thing for 3D rendering viewports. It works very well, but the pixmap approach you are showing here is very cool.

Wait, so what is doing rhe rendering to the pixmap? GDI, or does Scintillia have that capability built into it?

The rendering is done by a combination of gdi+ and the basic win32 api. I will send you some code tomorrow. But the keyword is PrintWindow() and getdibits().

It's also worth noting that in desktop mode menus and comboboxes use a separate window for the pop-up component, so there is no problems with these things appearing on top of a child window. However, this is not true when the GUI is being rendered in Vulkan.

I am using a small helper method to check if the interface is native or not (maybe something like this could make it into the Widget class) and to decide if i could use textures or must use pixmaps:

bool IsNativeInterface(shared_ptr<Interface> i)
{
    return i->GetWindow() != NULL;
}

If the interface is not native and you want or need to interact with the window you need to get it with ActiveWindow() and not use ui->GetWindow().