Post Reply 
Custom Text Formatting (Previously: Getting long results in a program)
04-05-2024, 02:36 PM (This post was last modified: 04-05-2024 04:18 PM by komame.)
Post: #40
RE: Getting long results in Program
(04-04-2024 07:34 PM)Tyann Wrote:  With several functions, the tests don't start until there are 6 or more elements and only the type of the second element is tested (at least if my approach is correct).

You should also consider this for functions with 4 and 5 parameters, as TEXTOUT_P can also be called without specifying the GROB parameter:
TEXTOUT_P("text",20,20,1);
TEXTOUT_P("text",20,20,7,#255d);

So testing the second parameter is necessary here as well.

(04-04-2024 07:34 PM)Tyann Wrote:  I've attached the code I wrote with several functions to see what you think.
.
.
.

Let's assume we call such a command: TEXT_P("text",20,20,7,#255d,"B"). This will trigger the TEXT_P function with 6 parameters, and within it, a test of the 2nd parameter will occur. Since the 2nd parameter is not of type GROB, G0 will be substituted, and the function will be called again with 7 parameters. Within it, another test of the 2nd parameter will occur, and the TEXT_P function will be called for the third time, this time with 8 parameters. Inside it, another test of the 2nd parameter will occur, and only at this point will the actual drawing code be invoked. This is a rather convoluted and costly path. Don't you think that instead of repeatedly passing all parameters and repeatedly performing tests of the 2nd parameter type, it would be much better to call the target function directly with all parameters, by hard-coding default values?

(04-04-2024 07:34 PM)Tyann Wrote:  You'll notice that each time you call G0, the parameters change: 'g' becomes 'x', 'x' becomes 'y' etc...
I have to admit that this thing gave me brain knots.

When the meaning of parameters changes during program execution, it's better not to assign them names suggesting a specific meaning, as this can be misleading. Just name them v1, v2, etc. In the documentation for the call, you can provide parameter names and indicate which ones are optional, but in the code, imho it's better not to assign names with specific meanings in such cases.

I will return for a moment to the "CASE" scenario. Here is the final code that achieves the same:

Code:
EXPORT TEXT_P(...p)
BEGIN
  LOCAL pt;
  pt:=EXECON("TYPE(&1)",p);
  CASE
    IF EQ(pt,{2,0,0}) THEN
      TEXTOUT_P(p[1],p[2],p[3]);
    END;
    IF EQ(pt,{2,8,0,0}) THEN
      TEXTOUT_P(p[1],p[2],p[3],p[4]);
    END;
    IF EQ(pt,{2,8,0,0,0}) THEN
      TEXTOUT_P(p[1],p[2],p[3],p[4],p[5]);
    END;
    IF EQ(pt,{2,0,0,0,0}) THEN
      TEXTOUT_P(p[1],p[2],p[3],p[4],p[5]);
    END;
    IF EQ(pt,{2,8,0,0,0,0}) THEN
      TXT_P(p[1],p[2],p[3],p[4],p[5],p[6],"",-1,-1); 
    END;
    IF EQ(pt,{2,0,0,0,0,2) THEN
      TXT_P(p[1],G0,p[2],p[3],p[4],p[5],p[6],-1,-1); 
    END;
    IF EQ(pt,{2,8,0,0,0,0,2}) THEN
      TXT_P(p[1],p[2],p[3],p[4],p[5],p[6],p[7],GET(TEXTSIZE(p[1],p[5]),1),-1); 
    END;
    IF EQ(pt,{2,0,0,0,0,2,0}) THEN
      TXT_P(p[1],G0,p[2],p[3],p[4],p[5],p[6],p[7],-1); 
    END;
    IF EQ(pt,{2,8,0,0,0,0,2,0}) THEN
      TXT_P(p[1],p[2],p[3],p[4],p[5],p[6],p[7],p[8],-1); 
    END;
    IF EQ(pt,{2,0,0,0,0,2,0,0}) THEN
      TXT_P(p[1],G0,p[2],p[3],p[4],p[5],p[6],p[7],p[8]); 
    END;
    IF EQ(pt,{2,8,0,0,0,0,2,0,0}) THEN
      TXT_P(p[1],p[2],p[3],p[4],p[5],p[6],p[7],p[8],p[9]); 
    END;
    RECT_P(""); // if none of the above syntaxes is found, it triggers an 'Invalid input' error
  END;
END;

TXT_P(s,g,x,y,p,c,a,l,f)
BEGIN
// Here is the drawing logic.
END;

It looks more readable, there is less of it, and all calls require only one "IF" before the direct invocation of the drawing procedure, because after the condition is met, the number of parameters, their types, and their order are known.

However, this solution also has its drawbacks because it doesn't automatically handle binary integers. The type for a binary integer is different from a regular numeric type, so adding alternatives in specific cases within the "CASE" is required (the number of "CASE" items won't increase, but additional ones will need to be added to the lists in "OR" mode).

So let's optimize what you've already prepared and move on to the drawing function.

Piotr Kowalewski
Find all posts by this user
Quote this message in a reply
Post Reply 


Messages In This Thread
RE: Getting long results in Program - komame - 04-05-2024 02:36 PM
RE: Custom Text Formatting - Tyann - 04-15-2024, 06:55 PM
RE: Custom Text Formatting - komame - 04-15-2024, 07:42 PM
RE: Custom Text Formatting - Tyann - 04-16-2024, 04:38 AM
RE: Custom Text Formatting - komame - 04-16-2024, 06:02 AM



User(s) browsing this thread: 50 Guest(s)