Prev: 10.6.3 and Home Edition crashes
Next: math lib change in OS X bug + workaround
From: mkr on 2 Apr 2010 06:20
I am trying to set up some interactive code where I issue short
instruction strings to drive some additional dynamic code.

My hope was to use an InputField into which I could continuously type
these short instructions, with a given character sequence ("do" in the
code below) acting as the trigger (I was guessing that using the
[Enter] key might not work).

There are a couple of immediate problem behaviors that I observe:
first, when InputField input contains spaces, the cursor keeps getting
moved to inside of the string, second, after ending a string with
"do", the cursor ends up to the right of the InputField, requiring a
[<-] keypress to get the cursor back into the InputField.

I am using 7.0.1 on XP. Code follows:



msgs={};
procstring[ins_String]:=If[StringLength[ins]>1&&StringTake[ins,
{-2,-1}]=="do",AppendTo[msgs,StringTake[ins,{1,-3}]];"",ins]

FullForm(a)procstring["process thisdo"];
FullForm(a)procstring["and thisdo"];
FullForm(a)procstring["but not this"];
msgs

ins="";
InputField[Dynamic[ins,(ins=procstring[#])&],String,ContinuousAction-
>True]
Dynamic[Column(a)msgs]



Any help fixing this approach, or with some other technique for
achieving the same general sort of input mechanism by another
approach, would be greatly appreciated.

Thanks,

Miles

From: John Fultz on 3 Apr 2010 06:58
There are two bugs here. Let me discuss the bugs and give you some tools that
you might use to construct things in a different way.

Bug #1 is the caret moving from the end of the string when you type a space.
Something similar happens if you begin typing a number, then type a letter (say,
"123do"). This is a bug which is specific to ContinuousAction->True and
String-type InputFields. Coincidentally, I independently discovered this bug a
few weeks ago, and the problem has been fixed in our internal development
builds.

You could work around this by using another type of InputField and trying to
convert the type back to strings. Here's a bit of code which uses the Boxes
type InputField with some conversion to bring it back to a string form.

makeString[RowBox[boxes_List]] :==
Apply[StringJoin, Map[makeString, boxes]];
makeString[box_String] :== box;

InputField[Dynamic[a], Boxes, ContinuousAction -> True]
Dynamic[makeString[a]]


Bug #2 has to do with the front end's attempt to figure out how to move the
selection when the selection is in a Dynamic thing which is changing size. The
FE is badly compensating in this case, pushing the selection right out of the
InputField. The selection should never be pushed out of the InputField. You're
the first lucky person to have reported this issue, and I'll file a bug report
on the issue.

I tried several ideas to work around this while preserving the two argument
Dynamic style that you're using, but was completely unable to think of a way out
of the box. However, it is possible to do by putting the procstring action into
a second Dynamic and combine with a SelectionMove. Something like this...

Row[{InputField[Dynamic[ins], String, ContinuousAction -> True],
Dynamic[ins == procstring[ins];
SelectionMove[EvaluationNotebook[], Before, Expression] &; ""]}]

I think with these workarounds, you'll be able to fashion a solution which will
work for you.

Sincerely,

John Fultz
jfultz(a)wolfram.com
User Interface Group
Wolfram Research, Inc.


On Fri, 2 Apr 2010 05:20:20 -0500 (EST), mkr wrote:
> I am trying to set up some interactive code where I issue short
> instruction strings to drive some additional dynamic code.
>
> My hope was to use an InputField into which I could continuously type
> these short instructions, with a given character sequence ("do" in the
> code below) acting as the trigger (I was guessing that using the
> [Enter] key might not work).
>
> There are a couple of immediate problem behaviors that I observe:
> first, when InputField input contains spaces, the cursor keeps getting
> moved to inside of the string, second, after ending a string with
> "do", the cursor ends up to the right of the InputField, requiring a
> [<-] keypress to get the cursor back into the InputField.
>
> I am using 7.0.1 on XP. Code follows:
>
>
> msgs=={};
> procstring[ins_String]:==If[StringLength[ins]>1&&StringTake[ins,
> {-2,-1}]===="do",AppendTo[msgs,StringTake[ins,{1,-3}]];"",ins]
>
> FullForm(a)procstring["process thisdo"];
> FullForm(a)procstring["and thisdo"];
> FullForm(a)procstring["but not this"];
> msgs
>
> ins=="";
> InputField[Dynamic[ins,(ins==procstring[#])&],String,ContinuousAction-
>> True]
> Dynamic[Column(a)msgs]
>
>
> Any help fixing this approach, or with some other technique for
> achieving the same general sort of input mechanism by another
> approach, would be greatly appreciated.
>
> Thanks,
>
> Miles


From: ADL on 3 Apr 2010 06:59
I obtained the effect you are looking for by using Null instead of ""
as a return value of procstring:

procstring[ins_String]:=
If[
StringLength[ins]>1 && StringTake[ins,-2]=="do",
AppendTo[msgs,StringTake[ins,{1,-3}]]; Null,
ins
];

ADL


On 2 Apr, 12:20, mkr <mileskra...(a)gmail.com> wrote:
> I am trying to set up some interactive code where I issue short
> instruction strings to drive some additional dynamic code.
>
> My hope was to use an InputField into which I could continuously type
> these short instructions, with a given character sequence ("do" in the
> code below) acting as the trigger (I was guessing that using the
> [Enter] key might not work).
>
> There are a couple of immediate problem behaviors that I observe:
> first, when InputField input contains spaces, the cursor keeps getting
> moved to inside of the string, second, after ending a string with
> "do", the cursor ends up to the right of the InputField, requiring a
> [<-] keypress to get the cursor back into the InputField.
>
> I am using 7.0.1 on XP. Code follows:
>
> ....
>
> Miles


 | 
Pages: 1
Prev: 10.6.3 and Home Edition crashes
Next: math lib change in OS X bug + workaround