As there have been few attempts to create this functionality (that I can find) I decided that I'd have to do this myself. And seeing as it boodly doesn't exist anywhere, I thought I'd share.
It does not extend GuiTextField, though it probably could, but it was easier to just take everything that was GuiTextField and make a new class and just make changes as needed, particularly as a lot of GuiTextField's fields were private and thus not visible to a subclass (using getters and setters was frustrating, as many setters either didn't exist or had annoying side effects, such as ignoring newlines and up/down arrow keys).
https://gist.github.com/Draco18s/2b02762b597e67a9b887aed241f25077
Known issues:
Minimum height of 2 lines enforced (are you really going to complain?)
Does not support multi-line selections (they are trouble some to handle; rendering, copying, etc)
Does not feature a scroll bar (yet)
Mouse wheel scrolling clamped to range that keeps the cursor within the visible text box range (technical limitation; could be overcome, but the limitation relates to automatically scrolling the cursor into range when using the arrow keys)
Page up/down not supported (yet)
Sometimes the selection highlight appears in edge-case situations that cause the cursor to reposition due to another (e.g. moving from one line to another when pasting multi-line content, etc)
Up/down arrow cursor movement is "by column" rather than "by rendered position" as I can't be arsed to figure out where the carat should go instead (my usage will be moving to a monospaced font, where those two values are the same).
Crash log says that Tinkers-Defense-Mod-1.12.2.jar is "Errored". Try temporary removing it from the mod list.
P.S.: Here is crash log packed in file if someone's interested.
CrashLog.txt
So, like, ya-know, probably, if you, like, maybe use, say, real English, with, like, fewer, uh, "filler" words?
And maybe talk in specifics instead of generalities?
As I told a former boss of mine, "I can code this to do anything you want, but you have to tell me what you want."
"Magic spells" is basically my actual job and covers a lot of tasks and virtually every function I write is a spell of one sort or another.
It looks like the RightClickItem docs are incorrect, since the RightClickBlock docs explicitly mention that the client will try RightClickItem unless the result is SUCCESS:
/**
* This event is fired on both sides whenever the player right clicks while targeting a block.
* This event controls which of {@link net.minecraft.block.Block#onBlockActivated} and/or {@link net.minecraft.item.Item#onItemUse}
* will be called after {@link net.minecraft.item.Item#onItemUseFirst} is called.
* Canceling the event will cause none of the above three to be called
*
* Let result be a return value of the above three methods, or {@link #cancellationResult} if the event is cancelled.
* If we are on the client and result is not {@link EnumActionResult#SUCCESS}, the client will then try {@link RightClickItem}.
*
* There are various results to this event, see the getters below.
* Note that handling things differently on the client vs server may cause desynchronizations!
*/
If you perform some action, you should set the event's cancellation result to EnumActionResult.SUCCESS and then cancel the event. This will stop the Vanilla methods from being called and the other event from being fired.
That said, there's no need to use events to handle the right click behaviour of your own Item; just override the appropriate methods in the Item class instead.
No. As I said, those ByteBufs aren't PacketBuffers; so that code will never send the unique IDs.
When I say "create a new instance", I mean "use the new operator".