Custom Text Formatting (Previously: Getting long results in a program)

[komame]

Hi Tyann,

(04-06-2024 06:50 AM)Tyann Wrote:  Here's a thought I had yesterday, looking at your code and analysing your comments.
For me, with 3 to 5 arguments we have nothing to do but call TEXTOUT_P (which itself tests whether Gx is transmitted or not), but you seem to disagree on this point?

For function with 3 parameters, I didn't have any concerns because it only occurs in one syntax [s,x,y]. As for 4 and 5 parameters, I myself fell into the trap I mentioned regarding the meaning of parameter names. So you're right, because (e.g., in case of 4 parameteres), the syntax [s,g,x,y] could be passed as [s,x,y,p]. If the parameters were described as [s,v1,v2,v3], I would have realized it.

(04-06-2024 06:50 AM)Tyann Wrote:  If we take a basic function with a variable list like your code.
TEXT_P( ...l) and we test the size of the list from 3 to 5 -> TEXTOUT_P, to 6 test of l(2) if TYPE=8 -> TEXTOUT_P.
Otherwise we construct the local function call in a string and use EXPR().

Following this line of thought (which seems like a very interesting approach), it's also possible to use a single EXPR call for list lengths from 1 to 3 (instead of three separate calls). This will simply require using MID to remove the curly braces after converting the list to a string.

(04-06-2024 06:50 AM)Tyann Wrote:  [...] if I've understood your code correctly you seem to be transmitting
your code correctly, you seem to be transmitting -1 for transparency.
Either it's passed and we're in overlay, or it's absent and we're in transparency.

Yes, I assumed that -1 represents transparency (as a default value) and wanted to handle it with a condition inside the code. Ultimately, this would allow us to have only two functions in the entire solution: one that takes parameters and calls TEXTOUT_P (when possible) or a function for custom drawing (when TEXTOUT_P cannot be used directly), and the other for handling custom drawing.