GUI Buttons can wrap & pad text, GUI Labels full alignment

[ivan-mogilko]

Resolves #1876
Resolves #2546

1. Added a GUIControl flag kGUICtrl_WrapText that may be applied to any text-based control, in theory.
   GUIButton supports this flag, and in case it is set:

• splits text into lines;
• aligns the text block vertically using vertical part of text alignment;
• aligns each text line horizontally using horizontal part of text alignment;

Wrapping and drawing code is mostly shared with the GUILabel class (picked out as a separate commit).

Added WrapText property to a Button in the Editor.

2. Added TextHorizontalPadding and TextVerticalPadding properties to GUIButton. These specify left-right and top-bottom space between button's frame and aligned text.

Button placeholder text supposedly should not be affected by this.
This has to be tested more.

3. GUILabels support full Alignment (both horizontal and vertical).

Possible TODOs:

• Add new properties to script API.

[ericoporto]

This appears to work. The (INV) macro also still works. I haven't tested many fonts here though.

I noticed that the comment of the text property is "Whether button will wrap long text", which is true but it's more than this, if this property is false the text is considered to be a single line and if this is true it will wrap long text but also take into account new line characters (\n and [), so I would amend that comment to "Whether button will wrap long text and accepts new line character" or just "When true, wraps text when it's long or has new line characters".

[ivan-mogilko]

I had a suspicion that after adding wrapped text, users may also ask for extra padding to better accomodate this text on a button, in case it has a Graphic with thick edges. And we already have #1876.

So, I decided to also add two more properties called TextHorizontalPadding and TextVerticalPadding.

[ivan-mogilko]

Added support for full text Alignment for Labels. This seems trivial to make at this point: as the calculating and drawing code is shared with button text, and HorizontalAlignment enum constants have values equal to the matching FrameAlignment enum.
(i.e. Left == TopLeft, and so on).

I think no additional backwards compatibility fixes are necessary here for that reason.

EDIT: I only had to add DeserializeConvertValue attributes to enum FrameAlignment in the AGS.Types.

[ericoporto]

@ivan-mogilko , I think you need to update the Engine/game/savegame_components.cpp

Uhm, I am getting an error when loading a save now. I am using the Sierra Template.

An internal error has occurred. Please note down the following information.
If the problem persists, contact the game author for support or post these details on the AGS Technical Forum.
(Engine version 3.6.2.1)

Error: Unable to restore the saved game.
Failed to restore the savegame component.
(#4) GUI, version 3060200, at offset 17661.
Inconsistent format, or file is corrupted.
Mismatching tag: GUILabels.

[ericoporto]

Well, as far as I can tell, it all works now, pretty cool, saving and loading and setting/getting properties appear to work too. Not too much sure of what else to test now, but it looks fine for merge. There is just an additional comment I added above in the RegisterButtonAPI function

[ivan-mogilko]

Would it be better if properties were called TextPaddingHorizontal and TextPaddingVertical? I think that has an advantage of having "TextPadding" first in both cases which keeps them together name-wise, and in autocomplete list.

Also, in hypothetical case we add more paddings, or replace this with a single property TextPadding which contains a struct, the new names will be easier to find.

[ericoporto]

Would it be better if properties were called TextPaddingHorizontal and TextPaddingVertical? I think that has an advantage of having "TextPadding" first in both cases which keeps them together name-wise, and in autocomplete list.

Yeah, that groups better for typing.

Also, in hypothetical case we add more paddings, or replace this with a single property TextPadding which contains a struct, the new names will be easier to find.

Right, let's say we have TextPaddingLeft, TextPaddingRight, TextPaddingTop, and TextPaddingBottom, setting TextPaddingHorizontal internally sets both Left and Right, and TextPaddingVertical sets both Top and Bottom. That works, but it can't be read back I think? So they wouldn't be properties if we intend to read them - or they give always say the value of left or top. I think the struct would have the same considerations as direct properties.

I had an idea for a property in the editor that takes comma separated values, so perhaps if it was a single property in the editor it could be like, one number means all text padding is equal, two numbers mean horizontal and vertical and four numbers mean the 4 directions. (this is from CSS rules, it has even a case for 3 numbers!)

Other approach would be something like WalkSpeed, with an additional property to set if the padding is uniform, symmetrical or "four sides" (I lack a word for the 4 dirs), and then setting this would make the proper entries appear. There may be other ways too.