Curl Global Community
RecordForm do-command "move-to" - Printable Version

+- Curl Global Community (
+-- Forum: Discussions (
+--- Forum: General Curl questions (
+--- Thread: RecordForm do-command "move-to" (/showthread.php?tid=495)

RecordForm do-command "move-to" - RobertShiplett - 05-13-2012


I am having some problems with command "move-to" for a RecordForm.

What I need is the result for the last index which the user actually visited or should visit next - and not just "move-previous" and "move-next".

{output for supported? and enabled? shows that "move-to" is supported but it is only enabled after a first use by a bound control. The RecordForm control panel obviously uses the command for its idx entry field ...

Any help will be much appreciated.

You can see my problem at where you enter some value as an index i1 where 0 < index < 1946 and once it jumps to that kanji, enter another, i2 = i1 +-n where |n| > 1 and then use my custom "back" button at the top left. Without "move to" the result is the unintended "move-previous" of the control panel reverse button at bottom- which is not what I want. To do Spaced-Rep learning, the applet needs "move-to" for those buttons.


30 min later: {set cmd.param-index=cookie-index} AND {set cmd.param-index=cspd-index} BOTH work fine.

I am trying to understand why "move-to" is still failing on startup and forcing me to use an explicit

... {recForm.request-current-record-change starting-idx}

while buttons bound to "move-next" and "move-previous" not being a problem ( using, e.g.,
bound-command = {rf.get-command "move-next"} )

If I were able to PCurl the applet, would the "move-to" problem go away ?

My current test applet is

- the applet on the Kanji page is using the explicit request rather than { "move-to"}

I have added an example at

The two "inner" buttons use {rf get-command "move-to" } and the outer "arrow" buttons "bind" the commands "move-previous" and "move-next" as can be seen by using the entry field to leap forward and a the left "inner" button to "recover".

But the "move-to" commands {RecordSetDisplayMoveToCommand } do not report as cmd.enabled? == true until at least one request was processed by the RecordForm - nota problem for cmd.supported? == true but not the former - until at least one record is in the view and one "changed" loop fired. That behavior is not what I want for "spaced-repetition" at startup.

I will try removing he control panel from the RecordForm and see if the "move-to" command can become enabled after the AttachEvent without first firing a request for a record.

{ "move-to"} always fails, whereas no exceptions kick up for

{set cmd.param-index = reps-idx}
{cmd.execute} || called explicitly by "inner" button action handlers
catch ex:Exception do
{output "Exception ", ex.value, " for index ", reps-idx}

RE: RecordForm do-command "move-to" - RobertShiplett - 05-14-2012

Sorry to see the SPAM

Of course, the parent class at issue is RecordSetDisplay as a CommandContext which support "move-to" Command