A modern programming language that makes developers happier.

kotlinlang

*EDIT:* Solved this, solution in :point_right: :thread:

I'm integrating a `TextField` and `DropDownMenu` to make a fairly standard drop-down selection for a form.
For this I want to suppress the standard text-editing interaction with the `TextField` and just respond to clicks by opening the menu.  Found this becomes a bit of a catch 22 though:
• Keeping the `TextField` _enabled_, and trying to apply an overriding `clickable` modifier to it, or its parent, does *not* stop the TextField from capturing user interaction and behaving normally, as hoped.
• _Disabling_ the TextField and applying `clickable` to its parent gives desired behaviour, but then of course the colours look disabled too, which I don't want.  So I'm trying to apply new `TextFieldColors` to it, that maintain the enabled appearance.  However I'm not finding this straightforward either - trying to reference the existing default colors gets you tangled up in interaction sources and stuff which does not feel necessary to be doing.
Any 3rd way I'm missing?

GetTextFieldColors_kt.kt

Looking at the `TextFieldColors` interface again; this seems to be a fairly robust way of optionally forcing an 'always enabled' appearance.
Using `remember` to avoid re-wrapping an unchanged `normalTextFieldColors` at every recomposition.

Usage_kt.kt

Seems like it would be more straightforward to just use a `Text` and a border instead of trying to disable a `TextField`

Agreed with Zach, that's my recommended solution as well

While I see the pro's of doing that; our design calls for  the hint, icons and other elements of the standard `TextField` to be present in this 'Drop Down' control.  This also paves the way for a potential 'combo' control.  In this instance, the path of least resistance still seems to be to base efforts on a `TextField`; otherwise we're faced with recreating &amp; maintain the exact L&amp;F of those secondary `TextField` elements, in sync with the original.