CALCULATION Wizard - bug with hyphen in values

If one of the selections in a list contains a hyphen (eg Co-operative $100) then the calulation wizard treats it as a 'minus sign' and is deducted from the result when calulated. It didn't behave this way before another bug was recently fixed, so assume this was not intentional. 

see example here

 

 

Hi, thanks for reporting this, I cloned the form and removed the hyphen, and I see it gives the expected result:

I have escalated this to our second level, you will be notified via this thread when this is fixed. 

Hi John,

One workaround would be to replace the hyphen with a tilde as I've done in this clone of the form. It just looks like a stylish hyphen!

Cheers

(Yes thats a smart alternative, but still a workaround) I wrote the following just as you were posting a reply...

I already use a discount (or Subsidy) in calulations and a typical formula is

Result={item1}+{Item2}+{item3}-{subsidy} 

The numeric or text value should ALWAYS be distinctly separate from the mathematical operator, otherwise your formula is never complete in 1 place - and it is much harder to troubleshoot. For example, say you have a negative value "Discount-$200" deducted in a formula {cost}-{discount} then it will end up as a double negative and even worse when you start using multiply and squared functions. The only time the hyphen as a minus would be logical is if you had a (SUM) function, but you don't. 

Yes you can ask forms designers to avoid hyphens but I think that it is making another hidden trap to have to avoid, rather than a design which always works consistently. And you can't logically avoid hyphens in some words.

It would be interesting to get others input.

M2CW 

In my 'real' Enrolment form (not the simple test form used above) I have over 400 entries in drop down lists of names. Many of them have a number tacked on the end representing the geographical zone which is used to calculate a subsidy. A high proportion of these names have a hyphen and I dont want to delete or fake these as they are formal names.

e.g. "Hamilton - Chartwell co-operating Parish" is the correct legal name.

Finally - if a hyphen is to be treated as a mathmatical operator, then so should / and + and * if they are used in text strings. This logic defeats the purpose of a calculator function.

(good debate) and I agree with you about check box/radio buttons because there is an implied "SUM" function already, but not for text boxes which are free form.

Thanks
I have added a final argument in my debate - please see my last post.
Radio buttons and checkboxes already have an implied (SUM) function so yes they need to be able to have negative values. I like your idea of honouring the minus sign only if it is right next to a digit.
Please let me know if you are going to change this so I don't waste time editing 400 entries and then back again!
regards

...

"so do you suggest we only accept negative signs when next to numbers like I said above?"

I think  that would be a good option because it would make a negative sign quite specific to the numeric value and not a hyphen. And radio buttons and check boxes are OK as is. Next question - how to define "next to" ?

Should it recognise -$20 or $-20 or $20- or only -20 and what if someone entered 20-24 meaning from 20 to 24, not 20 minus 24? You will need to think this through carefully.

Of course this whole question would go away if you had a delimeter option for all lists and text boxes. A semicolon or other custom delimiter (like the tilde~, or |) to separate Name from Value would provide much more control and avoid having to parse text for numeric value and operator. But this is a wider issue - right now I just want to have a predictable form function.    

Thanks for following this through. 

 

Thank you for the update.

Our developer has recieved your message and will update when available.

Hi Nicholas
Thanks - I'm pleased to say everything is now working predictably without needing tricky workarounds (for example - I used to multiply results * 1 to strip out the text value from the result).
...