IMHO one of the most common form functions is to include quantity fields and to subtotal or grand total those quantities.

I would LOVE to have a feature like this in DF!

Thank you for your input, we value enhancement requests from our customers. I will review these enhancements, summarize them, and pass them along to development to revise.

Let us know if you have any other great enhancement ideas, or questions.

Thanks,

Ryan

Hi guys - Just a follow up... I think that the trouble here is that typically when the "total" fields are often implemented they involve different types of fields such check box lists, radio buttons, text box's etc... So the enhancement itself might be difficult or limited to only text box fields? Or how would you see the enhancement created visually I guess? In other words, what settings or features/tokens/settings would you imagine you would find within the module area?

We are working on better methods of having our customers provide us direct feedback of our modules (either bugs or enhancements etc...). We have released a new support ticket that can be used to submit bugs as well which then are inserted/added into our Jira bug tracking and feature request system. So... Feel free to submit a "Feature Request" from support.datasprings.com. There is a "Suggest a feature" button on the bottom right of the main page.


Thanks,

Chad

I will be more than happy to enter it in the support system. I wanted to post it in the forum to gain other feedback. I can appreciate the possibilities of issues with field types but I have to say I think it is ultimately doable as long as there is proper documentation/demonstration(s) provided.

For example, if the rules of the road are, don't setup a combo box to allow a user to add their own entry, then so be it. If the rules state that it won't work if you include alpha characters so be it (but then again, that's what field level validation is for. I'm completely ok with substituting combo boxes with populated quantity values over having a text quantity fields.

I think including a new field type of numeric would be the simplest. Include an option that would enable totaling and it could be stand alone or included in an HTML field (I think that's the newest 4.1 capability - but haven't tried).

For example, 5 line items (A thru E) on the form;
Each item has a new quantity field;
A sixth quantity field is added to the form and the Totaling setting is checked;
This action queries the form for quantity type fields used in this form and allows the user to select only the quantity fields to be included in the total.

Other considerations would be the mathematical operators to be available via drop-down or radio button or designer defined variables such as (field A * variable(4.95))

In place of the designer defined variable, it would be helpful to allow designers to hide any field type but not by role (perhaps they can but I'm not aware). Meaning, a designer could populate a field with a numeric variable such as shipping rate = 4.95 but it didn't need to be visible by the end user. This field needs to be periodically updated by a designer and it needs to be used in one or multiple calculations.

At present, the designer has to update the shipping rate in the client-side event everywhere it reside and this makes everyone sad...

Lastly, since the previous totaling field is a new quantity field type, a second Grand Total quantity field type should be allowed to select any other quantity field type including the previous totaling field.

for starters...

I like the idea of a Totals field/function. It would have saved me hours of time and raised my confidence in using DF. I was in the middle of looking at other solutions when Dan responded to my post.

One suggestions, the Demonstration #20 page is a great idea, however it doesn't tell the entire explanation on how to implement the total function. It leaves out important details like the 'hidden field'.

Being able to download a copy of the form would have been helpful.