next »

[Jeff M.]

Hi,

Sorry if this makes no sense but I remember seeing or having the conversation with someone about a feature I thought was coming in V3 - but I'm now doubting it really happened.

The feature I was hoping for was identifying the specific field clicked within a DISPLAY ARRAY even if it was implemented as a built in function:
eg:
BEFORE FIELD field1, field2, field3, field4
   -- Remember this is in a DISPLAY ARRAY
   CASE fgl_clicked_column("s_screenrecord")

   -- Or even fgl_dialog_getfieldname() to work in display array

Was something introduced to allow this or was it all a dream? If so, could we please have this dream feature?

Thank you

Jeff

[Laurent G.]

Hello Jeff,

Does the following feature description describes your need:
https://4js.com/en/support/issue/?id=FGL-3456

This is still not implemented, so if it is, let me know and we will add you to the list of requesters.

Best

Laurent

[Jeff M.]

That would great as long as the normal right click menu comes up on right click though I know before hand which cell that was clicked.

At the moment we have to use an INPUT ARRAY and in the before field capture the field name then immediately NEXT FIELD dummyfield

dummyfield is a slider as this allows us to detect arrow left/right (on change dummyfield) but doing this removes our ability to have a right click context menu pop up, or to scroll within a textedit field in the table.

I've included a screenshot to show a typical example.

[Sebastien F.]

Just an idea, that was suggested and discussed internally:

I see you are using a DISPLAY ARRAY... (not sure if you are using TEXTEDIT columns or another widget to display richtext?)

Anyway, what if we would have a READONLY or NOTEDITABLE attribute for editable fields like TEXTEDIT?

By using an INPUT ARRAY with all fields set to read-only, focus could be given to a specific field, but the value could not be changed (you would see the edit caret but typing on keyboard would do nothing), and you could then put code in a BEFORE FIELD block...?

Of course the INPUT ARRAY should deny insert/append/delete rows with ATTRIBUTE(INSERT ROW=FALSE, APPEND ROW=FALSE, DELETE ROW=FALSE)

To me, a "cell click" implies the concept of "current field/cell"...
One should even be able to set the current cell by program (with NEXT FIELD!)... did you consider this?

Seb

[Jeff M.]

Hi Seb. Thank you for the feedback.

That is actually exactly what we want. We are using INPUT ARRAY with TEXTEDIT (style=html) and not DISPLAY ARRAY at the moment but straight after the click into the field we have to move you off to a separate input field to prevent editing of the cell.

Your proposed changes are a great way to go and I'm fairly sure it was this suggestion I remember being mentioned elsewhere.

One thing we do need to ensure is that when in the field we can detect left/right arrow key presses - basically where READONLY field arrrows  should work as TAB/SHIFT-TAB (normally in edit mode it would move within the text).

Am I right in saying that the READONLY or NOTEEDITABLE attribute is not yet implemented?

Thank you

Jeff

[Sebastien F.]

Hi Jeff,

In fact NOTEDITABLE exists already for BUTTONEDIT (since 2.50).
We have added this attribute to BUTTONEDIT in order to prevent value modifications when the button must be the only way to change the value.
https://4js.com/online_documentation/fjs-fgl-manual-html/?path=fjs-fgl-manual#c_fgl_FSFAttributes_NOTEDITABLE.html

About left/right arrows in read-only fields, I would leave the default behavior (move in the text), because of text selection with the keyboard (shift-left / shift-right for ex)...

We need of course to discuss again this feature internally, I just wanted to clarify the need...

In the meantime, maybe you could try to use BUTTONEDITs + NOTEDITABLE in your form - of course the HTML will display as plain text - but it could help to check the concept and see how it behaves... ?

Seb

[Reuben B.]

Jeff,

I look at your screen-shot and ask myself, why don’t you use WEBCOMPONENT?

A DISPLAY ARRAY or INPUT ARRAY, with TABLE is good for displaying and maintaining values from one database table.  That is with a fixed number of database table columns going across the screen and a variable number of database table rows going down the screen.  It is not so good for what you are trying to do.

By using WEBCOMPONENT, you’ll be able to come up with something that will ...

- allow single or double-click on a cell
as well as some other functionality that may include
- cater for indvidual stying for row, column, and cells.  This includes styles for column and row headings
- cater for column and row totals
- cater for merged cells, useful for sub-headings, sub-totals
- and other things you may want to include in your user interface

… this will work well across all our front-end clients, desk-top, web, and mobile

In Genero 3.0, the new WebComponent call front-call method https://4js.com/online_documentation/fjs-fgl-manual-html/#c_fgl_frontcalls_webcomponent.html makes it a lot easier to alter at run-time the html of a web component to reflect data values, and we already had the ability for an onclick method inside a webcomponent to change a 4gl variable and trigger a 4gl action.  If written well,  you can hide the html complexities of the web component from your junior developers.  My touchpad example, source available here https://github.com/FourjsGenero/wc_touchpad, shows these techniques.  I should put together an example to cater for the two dimensional array pattern (variable number of rows and variable number of columns, select and edit a cell).

Reuben

[Jeff M.]

HI Rueben,

Thanks for the feedback. I know ultimately that web components is the way to go but am very time poor (ie, buried by work) and therefore it is much easier to sit within my comfort zone (Genero) as I simply don't have the time to play - I'm sure I'm not alone here and having it all within Genero does allow me to keep up the pace.

I will clearly need to spend some time though, but it could be months before I can as we are against a very tight deadline to get this implemented and the way we currently do it works - sort of. I would love to revisit it though so might be in touch at the time.

Any two dimensional array examples you can put together though would be gratefully accepted as it will help me over that first hurdle - the one I don't currently have time to take a run up on.

Thank you,

Jeff