next »

[Bradford D.]

When using the TEXTEDIT type of field, the field will only allow entry of (# of rows * width of the field) as defined within the per file.  What we need is to allow a variable number of characters to be entered in the text edit field taking advantage of the scroll bars should the amount of text exceed the size of the field.  If the user expands the window thus expanding the TEXTEDIT field, they can still not enter any more text than what was initially defined by the size within the per file even though the field in the widow has been expanded.

It is counter intuitive that you should have a field such as TEXTEDIT and then restrict the amount of text that can be entered to be limited by the per file definition.  It would make more sense to simply allow the amount of text to be variable and the screen field to scroll appropriately and let the programmer deal with the length in the associated program.

The system should also allow the text field in the per file to have a type of STRING which would allow a dynamic string length and would not restrict the entry of text in the field.

Is this something that you are planning to add to the product in the future?

[Daniele A.]

Hi,
in BDL 2.50 (and 2.41, 2.21 i'am sure)
the textedit support the size of the  variable used for the input.

example in the .per file:
 grid
 {
  [dp_info1                          ]
  [                                  ]
  [                                  ]
  [                                  ]
  [                                  ]
 }
 end --grid


TEXTEDIT dp_info1=formonly.my_string_variable,SCROLLBARS=BOTH,style="font_bold";

in the .4gl you simply make an input with a string variable.

of course in the form the definition of the field must be formonly.name  and not table.colum

bye

[Bradford D.]

Sorry, but that is not what I have found.  I have a screen exactly like you have outlined below, and the maximum number of characters I can enter is the total of the space contained within the square brackets.  The documentation also states that the total number of characters that can be entered is defined by the space on the screen and not by the variable associated with the field.

[Sebastien F.]

I confirm that normally a TEXTEDIT allows a max input length defined by the program variable size.

Could you please provide more information about your configuration?
What Genero BDL version?
What type of front-end, version?

Can you double check that the .42f file contains a <TextEdit /> node definition with scroll="1"?

Normally with EDIT fields you have to add the SCROLL attribute by hand to force the max input length to the program variable size, but this is not required for TEXTEDIT fields, which get automatically scroll="1" in .42f ...

Seb

[Sebastien F.]

Could it be related to:
https://4js.com/support/issue/FGL-02077
?

[Reuben B.]

My quick tests suggests that the TEXTEDIT behaves as described in the documentation. 

The documentation https://4js.com/online_documentation/fjs-fgl-manual-html/#c_fgl_FormSpecFiles_TEXTEDIT_Item_Type.html says (my bolding)

You can use the SCROLLBARS attribute to define vertical and/or horizontal scrollbars for the TEXTEDIT form field. By default, this attribute is set to VERTICAL for TEXTEDIT fields. The STRETCH attribute can be used to force the TEXTEDIT field to stretch when the parent container is re-sized. Values can be NONE, X, Y or BOTH. By default, this attribute is set to NONE for TEXTEDIT fields. Note that using either the SCROLLBARS or the STRETCH attribute will automatically set the SCROLL attribute, to bypass the size limit defined by the screen tag and use the size of the program variable instead. For more details about size limitation, see the SCROLL attribute definition.

My quick test was

Code

DEFINE s1,s2 STRING
 
MAIN
    OPEN WINDOW w WITH FORM "textedit"
    INPUT BY NAME s1,s2
    DISPLAY s1
    DISPLAY s2
END MAIN

Code

LAYOUT
GRID
{
[f01        ]
[           ]
[f02        ]
[           ]
 
}
END
END
ATTRIBUTES
TEXTEDIT f01 = formonly.s1, SCROLLBARS=NONE, STRETCH=NONE, FONTPITCH=FIXED;
TEXTEDIT f02 = formonly.s2;

So the first field does not have scrollbars or stretch, so the scroll attribute is not automatically set, and hence I am limited to entering the amount of text defined by the screen tags.  This is useful for ASCII reports where you may have an area e.g. 4 lines by 60 columns set aside for notes/comments.
The second field received the default scrollbars/stretch settings which do set scrollbars=vertical, and hence the scroll attribute is automatically set, and hence the program variable controls the length of what can be entered.  In this case a STRING so unlimited.

So I suggest taking this example, check you get the same behaviour.  If you don't then report back with versions and OS so that the issue can be reproduced, or modify the example so that you get your undesired behaviour.

Reuben