Hi,
Is there a way under Win32 to make sure that the newTextField does not have any border, etc ? We want a seamless integration with our ui and currently there is a some sort of double border which is making a lot of noise inside our UI.
Any help would be appreaciated ?
thank you
Nick
Unfortunately no. And this is because native Win32 TextFields and TextBoxes do not actually support transparency. This means that the “hasBackground” and “alpha” properties are not supported on this platform.
The reason is because Microsoft’s classic Win32 UI doesn’t actually support alpha transparency. This is the old Microsoft native UI from the early 90s. Microsoft’s old Win32 native UI does not support *composite* drawing via OpenGL/Direct3D like modern UI frameworks do where the entire UI is rendered in 1 shot after all views/controls update themselves, which is the key to making alpha transparent UI work. The old Win32 UI draws each child control individually where you can literally watch each control draw themselves if they take long enough… and if they don’t completely paint the rectangle behind the control then you’ll see artifacts from what was last drawn/painted. Some Windows developers *fake* transparency by taking a screenshot of the content behind the native view and draw that captured image as the background… but this would be performance suicide in an app that draws at 30 FPS or 60 FPS via OpenGL in the background such as Corona. Because you would be literally be taking a screenshot on every frame (awful performance) and even if you did do this, you would have a bad flickering effect with the top level child controls because they would be painted over on every frame as well and they would quickly draw themselves on-top afterwards (hence the flicker effect). There really is no good solution to this.
Bottom line:
Transparent native UI will *never* be supported by classic Win32 apps. It’s a technical limitation.
I understand, in that case could we control the background color and the border color ? That way in our case, we could match both colors and give the illusion of the same background color.
That’s definitely possible. Especially a solid background color. It can replace the background and frame, but we would probably want to keep the Win32 vertical scrollbar for TextBoxes or else the user would be unable to scroll its content.
I don’t think the rest of the team here would want to port such a feature to the other platforms though.
I understand for the other platform as this is mostly for our Win32 needs. Any chance this could be done in the near future ?
thanks
Probably not in the near future. Our next most popularly requested thing to do on the desktop is to improve our mouse support.
Perhaps for the time being, you can use the solutions posted by Corona developers Ed and Jason. They’ve created their own Lua library for Windows which renders its own TextField and TextBox via display objects (which do support transparency) that accept input via “key” events. It’s limited to western languages since you can’t get the keyboard’s generated Unicode character and it’s impossible to know what symbols exist for the top row of number keys, but it works fine for simple text input.
Here is Ed’s solution…
https://forums.coronalabs.com/topic/57623-support-for-nativenewtextfield/?p=300554
Here is Jason’s solution…
https://forums.coronalabs.com/topic/57623-support-for-nativenewtextfield/?p=301146
Unfortunately no. And this is because native Win32 TextFields and TextBoxes do not actually support transparency. This means that the “hasBackground” and “alpha” properties are not supported on this platform.
The reason is because Microsoft’s classic Win32 UI doesn’t actually support alpha transparency. This is the old Microsoft native UI from the early 90s. Microsoft’s old Win32 native UI does not support *composite* drawing via OpenGL/Direct3D like modern UI frameworks do where the entire UI is rendered in 1 shot after all views/controls update themselves, which is the key to making alpha transparent UI work. The old Win32 UI draws each child control individually where you can literally watch each control draw themselves if they take long enough… and if they don’t completely paint the rectangle behind the control then you’ll see artifacts from what was last drawn/painted. Some Windows developers *fake* transparency by taking a screenshot of the content behind the native view and draw that captured image as the background… but this would be performance suicide in an app that draws at 30 FPS or 60 FPS via OpenGL in the background such as Corona. Because you would be literally be taking a screenshot on every frame (awful performance) and even if you did do this, you would have a bad flickering effect with the top level child controls because they would be painted over on every frame as well and they would quickly draw themselves on-top afterwards (hence the flicker effect). There really is no good solution to this.
Bottom line:
Transparent native UI will *never* be supported by classic Win32 apps. It’s a technical limitation.
I understand, in that case could we control the background color and the border color ? That way in our case, we could match both colors and give the illusion of the same background color.
That’s definitely possible. Especially a solid background color. It can replace the background and frame, but we would probably want to keep the Win32 vertical scrollbar for TextBoxes or else the user would be unable to scroll its content.
I don’t think the rest of the team here would want to port such a feature to the other platforms though.
I understand for the other platform as this is mostly for our Win32 needs. Any chance this could be done in the near future ?
thanks
Probably not in the near future. Our next most popularly requested thing to do on the desktop is to improve our mouse support.
Perhaps for the time being, you can use the solutions posted by Corona developers Ed and Jason. They’ve created their own Lua library for Windows which renders its own TextField and TextBox via display objects (which do support transparency) that accept input via “key” events. It’s limited to western languages since you can’t get the keyboard’s generated Unicode character and it’s impossible to know what symbols exist for the top row of number keys, but it works fine for simple text input.
Here is Ed’s solution…
https://forums.coronalabs.com/topic/57623-support-for-nativenewtextfield/?p=300554
Here is Jason’s solution…
https://forums.coronalabs.com/topic/57623-support-for-nativenewtextfield/?p=301146