RecordForm do-command "move-to"

[RobertShiplett]

すみません、してください。

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 http://aule-browser.com/kanji/index.html#curl1 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

http://www.aule-browser.com/kanji/hensha...T-001.html

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

I have added an example at http://www.aule-browser.com/kanji/hensha...T-002.html

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.

{rf.do-command "move-to"} always fails, whereas no exceptions kick up for

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

[RobertShiplett]

Sorry to see the SPAM

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