Four Js Development Tools Forum

While we are at it, any news on this feature?

I quote a mail from the 7th of feb. 2006 (soon 2 years ago!):


We have had other requests on this issue (quoting Reuben Barclay)


Regards
-Snorri

Unfortunately, because of prioritization of others features (some more or less linked to the multiple-dialogs) this feature is still in pending mode.

We know this has been asked several times (we update the list of requesters every time someone asks for it) and we had already discussions concerning the subject but it is not our top priority at the moment.

Keep also in mind that this feature would impact the DVM and also client-side development. Not something very easy to implement anyway.

Once again, we are sorry for the inconvenience.

Best regards,
Bernard

Bernard,

I am guessing that the real reason is because the Qt libraries don't cater for it, and you don't want to override QTable.

However theres more than one way to arrive at a soution.  How about you implement...
- a pseudo style selector for the last row of an array
- add an attribute SORTLASTROW=[YES|NO] that would control wether sorting an array includes the last row of the array in the sort.

Then we'd have a) the ability to alter how the last row displays and make it stand out, and b) when the user sorts the array the last row stays in the same position.

DEFINE l_arr DYNAMIC ARRAY OF RECORD
   code   STRING,
   value  DECIMAL(11,2)
END RECORD
 
LET l_length = l_arr.getLength()
LET l_sum_row = l_length + 1
 
LET l_arr[l_sum_row].code = "TOTAL"
LET l_arr[l_sum_row].value  0
FOR i = 1 TO l_length
   LET l_arr[l_sum_row].value = l_arr[l_sum_row].value + l_arr[i].value
END FOR
 
DISPLAY ARRAY l_arr TO scr.* ATTRIBUTES(SORTLASTROW=NO)

<Style name="Table.total:last">
   <StyleAttribute name="fontWeight" value="bold" />
</Style>

TABLE (STYLE="total", HEIGHT=5 LINES)
{
[f01   |f02     ]
[f01   |f02     ]
[f01   |f02     ]
[f01   |f02     ]
[f01   |f02     ]
}
END
ATTRIBUTES
f01 = formonly.code;
f02 = formonly.value;
INSTRUCTIONS
SCREEN RECORD scr[5](code, value)

Reuben

Reuben,

Yes and No.

Yes, the Qt Library does not provide an out of the box extended table, and we tend to not override too much their code (this to avoid beeing stucked in one direction while Qt finally moves in an other one).

No, the fact that the summary line is not implemented is not because of that.

What is really difficult to achieve in GDC is "freeze panes" like in Excel, because here we've to make a lot of drawings by ourselves. (We had a prototype, but as said previously it was unfortunately not an option as it was 100% home made and the we would be blocked later to extend it easily).

The "sum" line problem is more a question of 4GL definition.
I agree your solution could be quickly implemented (even if it's a bit more difficult than you say, as the runtime has to send a page with the current page + the last line).

But I feel (personnal opinion, everyone's idea is of course welcome here) that this is not "4GL" enough. In my eyes, the SUM line and the ARRAY must be two different data objects.
It's not up to the 4GL developper to think the last line must be the total.
It's not up to the 4GL developper to think that you have to insert rows at the last-1 position instead of appending rows, when there is a total line.

Just some ideas, but:

DEFINE ar ARRAY OF RECORD xx ...
DEFINE total RECORD xx ...
 
DISPLAY ARRAY ar TO sr.* ATTRIBUTES (SUMRECORD = total)
 

..
or

 INPUT ARRAY ar FROM sr.* ATTRIBUTES (SUMRECORD = total)
  ON ROW CHANGE
   CALL recomputeTotal( DIALOG.DIALOG.getCurrentRow("ar") )
...
 

Of course then you need a selector for the sum line, but this should be the last issue ;)

As said: in any case, the runtime system and the front ends are impacted: the sum line must always be sent, the synchronisation must be done a bit differently...

Therefore this has not been done today. The goal was to finish Multiple Dialogs first, then to go further.

Now, I can't tell you when this will be done (always the same story of priority), but be sure this is not written on a small paper then thrown to the trash. We've it in mind, and we've already some ideas on how to make it.

Thanks for he input.

I think the issue could get a little more complicated than just adding a sum column to a table. Perhaps one would like to have more than one aggregate on a single column (like sum and avg) which means you would need more than one line. It is also possible that you would like to put some text to the left of the column like SUM: or Average etc. Maybe something like this:
Basically, allow the user to create a normal field (or a table) that can be linked to the "parent" table (or column) in some way. By linked (align) I mean: If the column in the table is resized, the linked column is resized as well. If the table column is moved, the linked one is moved as well. Then it's up to the programmer to populate the aggregate fields. This could probably be done in GDC entirely.

Does this make sense?

Best regs,
-Snorri

Pierre-Nicolas,

I wasn't thinking of fixing the last row so its always visible, but yeah once you go down that path of Excel like splits and freeze panes figuring out what you're sending from the back to the front must get a little more complicated.  Of course we would also want the ability to programmatically add/remove a split and/or freeze :-)

Snorris example with more than one line of footer would be similar to the cases we had where if the enquiry screen was mimicing the layout of the printed document you would want 3 lines in your footer to show a nett, tax, and gross total value.  Currently that would be implemented like ...

TABLE 
{
[fff |f01   |f02     ]
[fff |f01   |f02     ]
[fff |f01   |f02     ]
[fff |f01   |f02     ]
[fff |f01   |f02     ]
}
GRID
{
[Nett:      |f03     ]
[Tax:      |f04     ]
[Gross:   |f05     ]
}

... with the annoyance that the value columns don't line up.

Once it gets into the realm of providing sums, averages, min, max, rank, percentage of, sub-totals, we are then into the realms of Excel like Pivot tables.  Unfortunately I don't see a QPivot amongst the Qt classes.

Reuben

FYI,
We started to write a spec draft for this and we have for now two options:
1) Simple solution based on table column attributes (summary line would be a kind of decoration like column titles are)
2) More complete (and complex) solution based on real form fields under each table column, could even act as input fields if bound to dialog controllers.

Hi,

Is there been any update on this feature request?

Cheers,
Roy.