Parsing is a matter of converting text to a list of tokens, and verifying there were no syntax errors. Actually I've found the error checking to be the more involved part.
Anyways here's my two cents on top of what has been mentioned. I'd go this route:
1. Convert text to a list of tokens. Basically numbers and operators (+-*/).
2. Convert the list of tokens from infix notation to reverse polish notation (RPN) using:
en.wikipedia.org/wiki/Shunting-yard_algorithm
That will eliminate the parenthesis and make it much simpler to calculate the result. An expression tree is another option but the code to do so in Construct will be more involved.
3. Evaluate the RPN expression to get the result.
Here's the current way I've gone about it. 61 fairly organized events although I can see shaving that down further. Handles decimal numbers, the five math operations (+-*/^), parenthesis and negation.
dropbox.com/s/f7lzeykvp98j1mw/parser_test3.capx
Older stuff:
106 events. Same capabilities as the one above. The approach is fairly different. Error checking is done by looking at neighboring tokens to see if it makes sense.
dropbox.com/s/36fg2ook2g0850o/parser.capx
70 events with a similar error checking method. Doesn't have ^ but it lets you write expressions like you do on paper with some variables. ex: 2(3), 4x+5y, etc...
dropbox.com/s/29i3dv40hk4ll1b/simpleEval.capx
You can also just use the browser.execjs() expression to evaluate the expression. The main disadvantage of that is the user can run any js with it. Not really an ideal situation. You could use a complicated regex expression to verify it only contains stuff you want, or maybe there's other approaches. The second disadvantage is you lose the ability to show good error messages if a bad expression is written.