Four Js Development Tools Forum

Discussions by product => Genero BDL => Topic started by: Stephen T. on April 02, 2012, 05:18:44 pm


Title: Table Aggregates
Post by: Stephen T. on April 02, 2012, 05:18:44 pm
Just a couple of queries when using aggregates, I don't appear to be able to:
1) ..give the field an independent label and style. I see that I can use a pseudo style attribute, but doesn't that then effect both the 'text' and the value?
2) ..to have multiple values for a single column. IE I do not appear to be able to have a count and a sum on a column as it seems to expect the AGGREGATE to be directly below the table column.
3) ..to have an aggregate on a non-EDIT field as the compiler rejects the field the aggregate is attached to. I can follow that normally, apart from in the case of a COUNT or PROGRAM type.
 

Title: Re: Table Aggregates
Post by: Julian B. on April 02, 2012, 05:33:20 pm
Quote from: Stephen Tucknott on April 02, 2012, 05:18:44 pm
Just a couple of queries when using aggregates, I don't appear to be able to:
1) ..give the field an independent label and style. I see that I can use a pseudo style attribute, but doesn't that then effect both the 'text' and the value?
2) ..to have multiple values for a single column. IE I do not appear to be able to have a count and a sum on a column as it seems to expect the AGGREGATE to be directly below the table column.
3) ..to have an aggregate on a non-EDIT field as the compiler rejects the field the aggregate is attached to. I can follow that normally, apart from in the case of a COUNT or PROGRAM type.
 

+1 from me

I raised similar issues during the EAP on the back of a "Hidden attribute for aggregate" question from Snorri Bergmann. The feature could do with being more general as far as attributes, position, multiple aggregates etc., but I don't think it's viewed as a high priority.

Julian

Title: Re: Table Aggregates
Post by: Stephen T. on April 02, 2012, 06:00:26 pm
OK, Thanks Julian.

Title: Re: Table Aggregates
Post by: Reuben B. on April 04, 2012, 05:58:46 am
Quote from: Julian Bridle on April 02, 2012, 05:33:20 pm
Quote from: Stephen Tucknott on April 02, 2012, 05:18:44 pm
Just a couple of queries when using aggregates, I don't appear to be able to:
1) ..give the field an independent label and style. I see that I can use a pseudo style attribute, but doesn't that then effect both the 'text' and the value?
2) ..to have multiple values for a single column. IE I do not appear to be able to have a count and a sum on a column as it seems to expect the AGGREGATE to be directly below the table column.
3) ..to have an aggregate on a non-EDIT field as the compiler rejects the field the aggregate is attached to. I can follow that normally, apart from in the case of a COUNT or PROGRAM type.
 

+1 from me

I raised similar issues during the EAP on the back of a "Hidden attribute for aggregate" question from Snorri Bergmann. The feature could do with being more general as far as attributes, position, multiple aggregates etc., but I don't think it's viewed as a high priority.

Julian

In order to get a higher priority, the developers need the feedback from the user-base.

In the case of ...

Quote
2) ..to have multiple values for a single column. IE I do not appear to be able to have a count and a sum on a column as it seems to expect the AGGREGATE to be directly below the table column.

... I raised that internally when I first saw the first screenshots in May last year, I raised it again in October when I was in Strasbourg seeing the new features in the new flesh before the EAP, and then again in the EAP itself, myself, Julian, and Tim Sodowsky commented or +1.

I reckon every 4gl/Genero site I have been to over the years has had a screen like the third one below with totalling on a column showing Nett, Tax, Gross totals, and a developer has asked how they can align these totals with the column.  However only myself, Julian, Tim, and now Steve will be down as requesting that feature.

Below is an extract of my mail from the EAP.  If you have screens like the following where the new AGGREGATE functionality won't meet your needs then make sure your voice is heard.  I can't promise anything, I'm too far away from the action, but a request with lots of requestors is more likely to be considered than one with no requestors,


Quote
Below are some cases I don't think the current implementation can't handle, but to date apart from your brief comments in b) and c), no-one has raised in the EAP.  So if you or anyone else do have a 'use case' that you can't handle with the new functionality, but you would expect that you would be able to, then this EAP is the place to raise it.   

Similarly if anyone agree or disagree with something, rather than silently nodding or shaking your head, make your opinion known.  Even if it is a simple email that says +1.  I can't promise it will be implemented but the more input we have the better decisions we will make.

Reuben



Code
  1. -- Input to total fields, as used in a Quotes Entry Screen, (or as you called it goal seeking)
  2. -- Salesman can enter the Quote value (f07), and have the system calculate margin for each line
  3. -- Salesman can enter the Quote margin (f06), and this will be applied to each line
  4. -- Salesman can enter override price (f03) or margin (f04) for each individual line.
  5.  
  6. Product       Qty    Price    Margin   Value
  7. [f01     |f02     |f03     |f04     |f05     ]
  8. [f01     |f02     |f03     |f04     |f05     ] 
  9. [f01     |f02     |f03     |f04     |f05     ] 
  10. [f01     |f02     |f03     |f04     |f05     ] 
  11.                      Total [f06     |f07     ]
  12. ...
  13. EDIT f04 = fomronly.margin, COMMENT = "Enter the desired quote line margin percentage"; EDIT f05 = formonly.line_value, COMMENT = "Enter the desired quote line value"; EDIT f06 = formonly.quote_margin, COMMENT="Enter the desired overall quote margin percentage"; EDIT f07 = formonly.quote_total, COMMENT="Enter the desired overall quote total";
  14.  
  15.  
  16.  
  17. -- Opening balance and a running total
  18. -- Summary line at top with an opening balance
  19. -- A list of transactions and a running total in a column
  20.  
  21.  Date     Transaction           Value Balance           
  22.                             (Opening)[f00    ] 
  23. [f01     |f02             |f03       |f04    ]
  24. [f01     |f02             |f03       |f04    ]
  25. [f01     |f02             |f03       |f04    ]
  26. [f01     |f02             |f03       |f04    ]
  27. [f01     |f02             |f03       |f04    ]
  28. ...
  29. LABEL f00 = formonly.opening_balance;
  30. LABEL f04 = formonly.running_balance;
  31.  
  32.  
  33.  
  34. -- More than one Summary Line
  35.  
  36.  Product       Qty    Price     Value
  37. [f01     |f02     |f03     |f04      ]
  38. [f01     |f02     |f03     |f04      ]
  39. [f01     |f02     |f03     |f04      ]
  40. [f01     |f02     |f03     |f04      ]
  41. [f01     |f02     |f03     |f04      ]
  42. [f01     |f02     |f03     |f04      ]
  43. [f01     |f02     |f03     |f04      ]
  44. [f01     |f02     |f03     |f04      ]
  45. [f01     |f02     |f03     |f04      ]
  46. [f01     |f02     |f03     |f04      ]
  47.            Delivery Charges[f05      ]
  48.            Net Total       [f06      ]
  49.            Tax             [f07      ]
  50.            Gross Total     [f08      ]
  51.  
  52.  
  53.  
  54. -- More than one summary line, additional fields to the right
  55.  
  56.  Product       Qty    Price     Value
  57. [f01     |f02     |f03     |f04      ]
  58. [f01     |f02     |f03     |f04      ]
  59. [f01     |f02     |f03     |f04      ]
  60. [f01     |f02     |f03     |f04      ]
  61. [f01     |f02     |f03     |f04      ]
  62. [f01     |f02     |f03     |f04      ]
  63. [f01     |f02     |f03     |f04      ]
  64. [f01     |f02     |f03     |f04      ]
  65. [f01     |f02     |f03     |f04      ]
  66. [f01     |f02     |f03     |f04      ]
  67.   Total (Invoice Currency) [f05      ][c05    ]
  68.   Total (Home Currency)    [f06      ][c06    ]
  69.  
  70. LABEL f05 = formonly.invoice_total; -- Value of invoice in invoice currency LABEL f06 = formonly.home_currency_total; -- Value of invoice in home or base currency LABEL c05 = formonly.invoice_currency;-- Currency of invoice LABEL c06 = formonly.home_currency; -- Currency of sales ledger

Title: Re: Table Aggregates
Post by: Stephen T. on April 04, 2012, 09:07:00 am
Reuben,
You're correct in that the users should provide feedback. I used to take part in the EAPs, but that was before the Enterprise OS bit came in. I tend to use a non-enterprise OS for my day to day stuff, so I 'assumed' that my EAP findings would have to be replicated on an Enterprise OS - which just made it unworkable for me. If the developers are ok with getting feedback from un-supported OSes, then I'll join the next!

Title: Re: Table Aggregates
Post by: Reuben B. on April 05, 2012, 06:09:56 am
Quote from: Stephen Tucknott on April 04, 2012, 09:07:00 am
Reuben,
You're correct in that the users should provide feedback. I used to take part in the EAPs, but that was before the Enterprise OS bit came in. I tend to use a non-enterprise OS for my day to day stuff, so I 'assumed' that my EAP findings would have to be replicated on an Enterprise OS - which just made it unworkable for me. If the developers are ok with getting feedback from un-supported OSes, then I'll join the next!

I'm not sure what non-enterprise or unsupported OS you are using, but one of the reasons the EAP's tend to be Linux and Windows first is under the assumption that most people have ready access to one of those, even if they use in production the likes of AIX/Solaris.

For all my day to day stuff I use a Windows 7 lap-top with a number of VM's to look at other O/S should I need to.

In any event, the choice of O/S shouldn't impact on the language syntax and the functionality it provides.

What you also have to remember is that the EAP is the best time to change things.  Once a version is released, we are for want of better words stuck with what we have released, and any changes have to be maintenance fixes.   A maintenance release (2.40.01, 2.40.02 etc ) doesn't force you to recompile, whilst if we have a 2.41.00 that may force you to recompile.  Hence we'd rather get it right due to feedback in the EAP rather than get feedback just after a release.

Reuben

Title: Re: Table Aggregates
Post by: Stephen T. on April 05, 2012, 01:21:13 pm
Reuben,
That's simply my misconception then. I tend to use Fedora Core on a day to day basis - that was ok in the days when the support was based on the compiler and lib versions, but 'appeared' to change when the list became officially supported OSes. I had (obviously wrongly) assumed that as support was restricted to specific OSes, then EAP testing would be as well. My mistake.