dagl@ur-tut.UUCP (09/13/87)
I'm writing a program (with Lightspeed C) which plots functions, and am using
a dialog with an editText item to get a string representing the function from
the user. A default value (the previous function string entered by the user,
if any) is copied into the item with SetIText.
The problem I've encountered is that when the string contains one of the
ParamText keys (^0,^1,^2,^3) the ParamText strings are substitued in place.
For example, if the user enters "x^2" in the f(x) box in my dialog, the next
dialog invocation will show f(x) with the default value of "x", substituting
the null string for ^2. (I do use ParamText1 for my alerts, but I pass null
strings for the other 3 arguments)
Is there any way to disable this substitution process ? I attempted
ParamText("\P^0","\P^1","\P^2","\P^3"); but this only caused an infinte loop
of substitution as I observed with TMON.
--
-------------------------------------------------------------------------------
David Glowny | Internet: dagl@tut.cc.rochester.edu
| UUCP: {decvax,cmcl2}!rochester!ur-tut!dagl
-------------------------------------------------------------------------------olson@endor.harvard.edu (Eric Olson) (09/14/87)
In article <73@ur-tut.UUCP> dagl@ur-tut.UUCP (Dave Glowny) writes: >The problem I've encountered is that when the string contains one of the >ParamText keys (^0,^1,^2,^3) the ParamText strings are substitued in place. >For example, if the user enters "x^2" in the f(x) box in my dialog, the next >dialog invocation will show f(x) with the default value of "x", substituting >the null string for ^2. (I do use ParamText1 for my alerts, but I pass null >strings for the other 3 arguments) > >Is there any way to disable this substitution process ? I attempted >ParamText("\P^0","\P^1","\P^2","\P^3"); but this only caused an infinte loop >of substitution as I observed with TMON. This is not a solution, but a praise of ParamText. You can't define ParamText 1 to be "^1" because it does the substitution in an infinite loop. But this is very convenient, since your error function could be: myerr(errnum,paramnum,errfn) long errnum; long paramnum; char * errfn; { char numstr[20]; char parmstr[20]; StringHandle errstr; NumToString(errnum,numstr); NumToString(paramnum,parmstr); errstr=GetString(errnum); HLock(errstr); ParamText(*errstr,numstr,parmstr,errfn); do_error_alert(); HUnlock(errstr); } Now, if errnum is -108 and STR -108 is "Out of memory (need ^1 more bytes) while ^2.", and the error call is myerror(-108,needed-got,"\pallocating buffer") then the dialog will acutally say: Out of memory (need 28934 more bytes) while allocating buffer. Similarly, you could have a rangecheck error called like: myerror(300,value,"\pstart point") where STR 300 is: "The value of ^2 (^1) is out of range." Then the dialog will actually say: "The value of start point (234) is out of range." Anyways, I use the ParamText a lot like this and find that, because it isn't just a one-level substitution, it's very easy to make error messages that look good. -Eric Eric K. Olson olson@endor.harvard.edu harvard!endor!olson
barmar@think.COM (Barry Margolin) (09/16/87)
In article <2837@husc6.UUCP> olson@endor.UUCP (Eric Olson) writes: >This is not a solution, but a praise of ParamText. You can't define ParamText >1 to be "^1" because it does the substitution in an infinite loop. For the times when this is useful, you could always call ParamText a second time in your program. On the other hand, given this "feature", there is no way to get it to stop when you want it to. --- Barry Margolin Thinking Machines Corp. barmar@think.com seismo!think!barmar
dagl@ur-tut.UUCP (Dave Glowny) (09/16/87)
In article <8466@think.UUCP> barmar@godot.think.com (Barry Margolin) writes: >In article <2837@husc6.UUCP> olson@endor.UUCP (Eric Olson) writes: >>This is not a solution, but a praise of ParamText. You can't define ParamText >>1 to be "^1" because it does the substitution in an infinite loop. > >For the times when this is useful, you could always call ParamText a >second time in your program. On the other hand, given this "feature", >there is no way to get it to stop when you want it to. I've implemented a work-around which was suggested via e-mail by several people: sustitute the null-character between '^' and [0-3]. Because it has zero-width, it will not be displayed. In my own application, because the string is returned from an editText item to my function parser, I must also remove the null-character after the dialog is dismissed. -- ------------------------------------------------------------------------------- David Glowny | Internet: dagl@tut.cc.rochester.edu | UUCP: {decvax,cmcl2}!rochester!ur-tut!dagl -------------------------------------------------------------------------------