Re: Dispatch-Sending keyDown

[Jan Schenkel]

One of the key differences between 'send' and 'dispatch' (other than the 'with' 
extension to more easily pass paramaters), is that 'dispatch' won't throw an 
error if the message isn't handled.

So in fact, when you use
##
dispatch "foo" to this stack with "bar"
##

It internally works more like
##
try
  put "bar" into theParam
  send "foo theParam" to this stack
catch theError
  -- ignore the error but set the result to "unhandled"
end try
##

I hope this clarified it somewhat.

Jan Schenkel
=
Quartam Reports & PDF Library for Revolution
<http://www.quartam.com>

=
"As we grow older, we grow both wiser and more foolish at the same time."  (La 
Rochefoucauld)


--- On Mon, 10/26/09, dunb...@aol.com  wrote:

> From: dunb...@aol.com 
> Subject: Re: Dispatch-Sending keyDown
> To: use-revolution@lists.runrev.com
> Date: Monday, October 26, 2009, 11:52 AM
> Brian.
> 
> Fair enough. But then we should insist that "dispatch" not
> be allowed to 
> "send" system messages. And now this really is getting to
> be too much.
> 
> I love Rev for the same reasons I love HC. They are
> magnificent 
> intellectual tools manipulatable by mere mortals. Therefore
> I will cut either any break 
> they need; I just want to know how they work.
> 
> Craig Newman
> 
> 
> In a message dated 10/26/09 2:44:11 PM, bri...@qldlearning.com
> writes:
> 
> 
> > 
> > Ideally (in my mind), if Rev wants to be strict then
> it should just 
> > not allow you to "send" system messages. Either pass
> them, don't pass 
> > them, or use send with a non-reserved name. Then there
> would be little 
> > room for expecting them to continue to behave as
> system messages.
> > 
> 
> ___
> use-revolution mailing list
> use-revolution@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage
> your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
> 



___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Dispatch-Sending keyDown

[DunbarX]

Richard:

Bug report # 8372.

Craig

In a message dated 10/26/09 3:13:52 PM, ambassa...@fourthworld.com writes:


> If you file a bug report about dispatch allowing this while send
> doesn't, please post the RQCC number so I can track it.  TIA.
> 

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Dispatch-Sending keyDown

[Richard Gaskin]

DunbarX wrote:

Fair enough. But then we should insist that "dispatch" not be allowed to 
"send" system messages. And now this really is getting to be too much.


I agree that messages should be allowed with send and dispatch so long 
as there's a handler for them.


If you file a bug report about dispatch allowing this while send 
doesn't, please post the RQCC number so I can track it.  TIA.



>> Know the engine.
>> Trust the engine.
>> Use the engine.


I am trying to.
I was trying to.
I will.


:)

--
 Richard Gaskin
 Fourth World
 Rev training and consulting: http://www.fourthworld.com
 Webzine for Rev developers: http://www.revjournal.com
 revJournal blog: http://revjournal.com/blog.irv
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Dispatch-Sending keyDown

[Brian Yennie]

Well I did say *if* Rev is going to be strict. I have no idea whether  
it should be =). But yes, I would say send and dispatch should follow  
the same rules here.


On the second part... amen.

Fair enough. But then we should insist that "dispatch" not be  
allowed to

"send" system messages. And now this really is getting to be too much.

I love Rev for the same reasons I love HC. They are magnificent
intellectual tools manipulatable by mere mortals. Therefore I will  
cut either any break

they need; I just want to know how they work.




___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Dispatch-Sending keyDown

[Brian Yennie]

This is probably highly unnecessary, but I found it interesting to  
imagine:


on keyDown
   pass keyDown to this stack
end keyDown

A "pass" with a target =)!


The way I rationalize it is along your line of thinking, Jacque.

Basically I see a system message as something only the engine can  
create. As soon as you use "send", you are creating a custom user- 
level message like any other. What you have sent is NOT a system  
message any more, it's just some sort of clone which lacks its  
"system" identity. So it will just travel the message hierarchy the  
same way as if you had changed the message to "BriansKeyDownHandler".


I'm sure there are exceptions, but I think Hypercard had more of a  
anything goes attitude. If you send a message, it would actually  
simulate the behavior whenever possible. Perhaps the liberal use of  
doMenu for even system tasks (copy / paste for example) instilled  
this deeply?


Ideally (in my mind), if Rev wants to be strict then it should just  
not allow you to "send" system messages. Either pass them, don't  
pass them, or use send with a non-reserved name. Then there would be  
little room for expecting them to continue to behave as system  
messages.


FWIW.


Richard Gaskin wrote:

Perhaps HC allowed you to send message to any arbitrary point in  
the message path beyond the current script regardless whether or  
not there's a handler for it there as a more verbose alternative  
to "pass".  But as I explained in detail earlier there are reasons  
why Rev doesn't work the same way with messages, and instead  
requires that you use the method which is simpler and faster in  
both xtalks, "pass ".


I think Craig's question is more basic. He wonders why sending some  
keywords to a stack will then pass that message along the hierarchy  
automatically if the target object doesn't have a matching handler,  
but sending other keywords doesn't. I.e.:


send "beep" to this stack -- passes it through the message path

send "keydown" to this stack -- stops the message with an error at  
the stack level


I have an untested theory. Command keywords will pass through the  
hierarchy, but system messages won't. ("Beep" is a command.  
"Keydown" is a system message.) I'm not sure what built-in  
functions would do but I'm guessing they'd act like command keywords.


No time to test or verify; maybe someone else can.

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Dispatch-Sending keyDown

[DunbarX]

Brian.

Fair enough. But then we should insist that "dispatch" not be allowed to 
"send" system messages. And now this really is getting to be too much.

I love Rev for the same reasons I love HC. They are magnificent 
intellectual tools manipulatable by mere mortals. Therefore I will cut either 
any break 
they need; I just want to know how they work.

Craig Newman


In a message dated 10/26/09 2:44:11 PM, bri...@qldlearning.com writes:


> 
> Ideally (in my mind), if Rev wants to be strict then it should just 
> not allow you to "send" system messages. Either pass them, don't pass 
> them, or use send with a non-reserved name. Then there would be little 
> room for expecting them to continue to behave as system messages.
> 

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Dispatch-Sending keyDown

[Brian Yennie]

The way I rationalize it is along your line of thinking, Jacque.

Basically I see a system message as something only the engine can  
create. As soon as you use "send", you are creating a custom user- 
level message like any other. What you have sent is NOT a system  
message any more, it's just some sort of clone which lacks its  
"system" identity. So it will just travel the message hierarchy the  
same way as if you had changed the message to "BriansKeyDownHandler".


I'm sure there are exceptions, but I think Hypercard had more of a  
anything goes attitude. If you send a message, it would actually  
simulate the behavior whenever possible. Perhaps the liberal use of  
doMenu for even system tasks (copy / paste for example) instilled this  
deeply?


Ideally (in my mind), if Rev wants to be strict then it should just  
not allow you to "send" system messages. Either pass them, don't pass  
them, or use send with a non-reserved name. Then there would be little  
room for expecting them to continue to behave as system messages.


FWIW.


Richard Gaskin wrote:

Perhaps HC allowed you to send message to any arbitrary point in  
the message path beyond the current script regardless whether or  
not there's a handler for it there as a more verbose alternative to  
"pass".  But as I explained in detail earlier there are reasons why  
Rev doesn't work the same way with messages, and instead requires  
that you use the method which is simpler and faster in both xtalks,  
"pass ".


I think Craig's question is more basic. He wonders why sending some  
keywords to a stack will then pass that message along the hierarchy  
automatically if the target object doesn't have a matching handler,  
but sending other keywords doesn't. I.e.:


send "beep" to this stack -- passes it through the message path

send "keydown" to this stack -- stops the message with an error at  
the stack level


I have an untested theory. Command keywords will pass through the  
hierarchy, but system messages won't. ("Beep" is a command.  
"Keydown" is a system message.) I'm not sure what built-in functions  
would do but I'm guessing they'd act like command keywords.


No time to test or verify; maybe someone else can.

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Dispatch-Sending keyDown

[J. Landman Gay]

Richard Gaskin wrote:

Perhaps HC allowed you to send message to any arbitrary point in the 
message path beyond the current script regardless whether or not there's 
a handler for it there as a more verbose alternative to "pass".  But as 
I explained in detail earlier there are reasons why Rev doesn't work the 
same way with messages, and instead requires that you use the method 
which is simpler and faster in both xtalks, "pass ".


I think Craig's question is more basic. He wonders why sending some 
keywords to a stack will then pass that message along the hierarchy 
automatically if the target object doesn't have a matching handler, but 
sending other keywords doesn't. I.e.:


send "beep" to this stack -- passes it through the message path

send "keydown" to this stack -- stops the message with an error at the 
stack level


I have an untested theory. Command keywords will pass through the 
hierarchy, but system messages won't. ("Beep" is a command. "Keydown" is 
a system message.) I'm not sure what built-in functions would do but I'm 
guessing they'd act like command keywords.


No time to test or verify; maybe someone else can.

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Dispatch-Sending keyDown

[Richard Gaskin]

J. Landman Gay
I think Craig's question is more basic. He wonders why sending some 
keywords to a stack will then pass that message along the hierarchy 
automatically if the target object doesn't have a matching handler, but 
sending other keywords doesn't. I.e.:


send "beep" to this stack -- passes it through the message path

send "keydown" to this stack -- stops the message with an error at the 
stack level


I have an untested theory. Command keywords will pass through the 
hierarchy, but system messages won't. ("Beep" is a command. "Keydown" is 
a system message.) I'm not sure what built-in functions would do but I'm 
guessing they'd act like command keywords.


No time to test or verify; maybe someone else can.


That is weird indeed, and your theory seems reasonable given Raney's 
focus on trimming system message handling.


I would file such inconsistencies as minor bugs and move on to enjoy the 
greater variety of messages Rev offers which don't require workarounds 
like sending an unhandled keyDown to the stack at all.


--
 Richard Gaskin
 Fourth World
 Rev training and consulting: http://www.fourthworld.com
 Webzine for Rev developers: http://www.revjournal.com
 revJournal blog: http://revjournal.com/blog.irv
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Dispatch-Sending keyDown

[DunbarX]

Richard.

I'm going forward with this:

send "bugReport" to Revolution with messages

This may be going on too long. I have missed nothing in your posts to this 
thread.   I appreciate them all, especially "dispatch" working as I would 
expect.

Of the scenarios you mentioned, you omit the original one:   I want to send 
the "keyDown" message and then continue to work in the same handler. "Send" 
doesn't work. "Dispatch" does. "Pass" don't cut it, or rather, it cuts it 
right off.

Craig

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Dispatch-Sending keyDown

[Richard Gaskin]

DunbarX wrote:
A char typed into a field is actually written via a "keyDown" message 
reaching the engine. It doesn't just appear there via some other mechanism. At 
least that is what I believed. How it gets there is a matter of choice. This 
all seems like what I would consider "normal handling".


So I just wanted to know why I could not send that message explicitly, by 
hand. You can in HC, and I wondered why you could not in Rev. Why would it 
not continue along, like all other messages:


on sendBeep
   send "beep" && 3 to this stack
end sendBeep

This works fine. What is the thing about keyDown? In other words, what is 
the difference, trying to understand the way things work. If your point is 
that the message is stopped for some reason if I intercept it and send it 
rather than passing it to the engine, then I am really confused.


I am with Richard in thinking it is some sort of bug.


Please review my post:


I also summarized it here:


The possible bug I noted was the difference between dispatch and send. 
Specifically, you can "dispatch" a message to a stack and it works well, 
but if you "send" the same message to the same stack the engine will 
complain with an error.


And IMPORTANT POINT apparently missed each of the times I've written it 
is that there does not appear to be a bug with "dispatch".


In brief:

- IF you want normal engine handling,
  THEN don't do anything and let the engine handle it

- IF you want custom handling up front and then want to the engine
  to handle it after,
  THEN do your custom processing and then use "pass" to let the
  engine handle it

- IF you want to split your custom processing so that half is done
  in the control and half is done in the stack,
  THEN do what you want in the control and use "dispatch" (or, when
  it's fixed, "send") to call the handler in the stack

But please keep this in mind:  the engine is not a stack, nor a stack 
the engine.  I don't know what sort of ambiguity the HC team may have 
had for things like this, but in Rev "stack" and "engine" are not 
synonymous; rather very different things, and you would only send a 
message to a stack if it was indeed the stack that you wanted to handle 
it.  If instead you want the engine to handle it, just use "pass" and 
it'll find it's way to the engine as you would expect and as the many 
examples already posted in this thread have shown.


Perhaps HC allowed you to send message to any arbitrary point in the 
message path beyond the current script regardless whether or not there's 
a handler for it there as a more verbose alternative to "pass".  But as 
I explained in detail earlier there are reasons why Rev doesn't work the 
same way with messages, and instead requires that you use the method 
which is simpler and faster in both xtalks, "pass ".


Learning Rev isn't the hard part.  It's unlearning the ambiguousness of 
HC that's hard. ;)


--
 Richard Gaskin
 Fourth World
 Rev training and consulting: http://www.fourthworld.com
 Webzine for Rev developers: http://www.revjournal.com
 revJournal blog: http://revjournal.com/blog.irv
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Dispatch-Sending keyDown

[DunbarX]

Mark.

A char typed into a field is actually written via a "keyDown" message 
reaching the engine. It doesn't just appear there via some other mechanism. At 
least that is what I believed. How it gets there is a matter of choice. This 
all seems like what I would consider "normal handling".

So I just wanted to know why I could not send that message explicitly, by 
hand. You can in HC, and I wondered why you could not in Rev. Why would it 
not continue along, like all other messages:

on sendBeep
   send "beep" && 3 to this stack
end sendBeep

This works fine. What is the thing about keyDown? In other words, what is 
the difference, trying to understand the way things work. If your point is 
that the message is stopped for some reason if I intercept it and send it 
rather than passing it to the engine, then I am really confused.

I am with Richard in thinking it is some sort of bug.

Craig Newman

In a message dated 10/23/09 4:21:43 PM, mwie...@ahsoftware.net writes:


> But by dispatching the message you're saying "don't handle this char
> here, but instead bypass the normal handling and give the char
> directly to the stack script." If it's not handled there it will get
> passed on to the backscripts, engine, etc. But nothing is going to
> place the char into your field because you've very explicitly stopped
> that from happening.
> 

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Dispatch-Sending keyDown

[Mark Wieder]

Craig-

Friday, October 23, 2009, 12:13:13 PM, you wrote:

> No problem with passing keydown, wherever it appears. Or explicitly putting
> the character after the field. I just wanted to understand why explicitly
> sending the message fails. Purely academic at this point.

If you mean explicitly "dispatching", then it *is* working. You're
intercepting the "keydown" message, then dispatching it directly to
the stack. The stack is never going to put the char into your field
unless you tell it to.

By not "passing" the keydown message you're interfering with the
normal message control path. In some cases this is exactly what you
want to do: for a password field, for instance, you would want to
intercept the char, store it away somewhere, and put a cummy char in
its place in the field. In that case you do *not* want to pass the
original char.

But by dispatching the message you're saying "don't handle this char
here, but instead bypass the normal handling and give the char
directly to the stack script." If it's not handled there it will get
passed on to the backscripts, engine, etc. But nothing is going to
place the char into your field because you've very explicitly stopped
that from happening.

-- 
-Mark Wieder
 mwie...@ahsoftware.net

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Dispatch-Sending keyDown

[Richard Gaskin]

DunbarX wrote:
No problem with passing keydown, wherever it appears. Or explicitly putting 
the character after the field. I just wanted to understand why explicitly 
sending the message fails. Purely academic at this point.


As I wrote earlier, there is an inconsistency with the way send and 
dispatch work:



In brief, even if you have a handler defined, dispatch will work but 
send won't.


File it as a bug if you like:


In the meantime, you have solutions in hand.

--
 Richard Gaskin
 Fourth World
 Rev training and consulting: http://www.fourthworld.com
 Webzine for Rev developers: http://www.revjournal.com
 revJournal blog: http://revjournal.com/blog.irv
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Dispatch-Sending keyDown

[Richmond Mathewson]

I thought I would be 'clever' having read
what the Documentation says about DISPATCH
and did this:

on keyDown var
  dispatch "keydown" with var
end keyDown

and fell foul of a recursion problem.

I quote from a user-note contributed by somebody called
OLIVER (Hello, Oliver, are you reading this? Because your
input would be extremely welcome.):

"Be careful to ensure when using dispatch recursively that an infinite 
loop won't be caused. For example something like this will never 
terminate unless a child handles the message:


command updateView
  dispatch "updateView"
end updateView

This applies equally to the send and call commands."

Obviously the keydown IS being dispatched SOMEWHERE . . .  :)
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Dispatch-Sending keyDown

[DunbarX]

Mark.

Thanks for the reply.

No problem with passing keydown, wherever it appears. Or explicitly putting 
the character after the field. I just wanted to understand why explicitly 
sending the message fails. Purely academic at this point.

Craig Newman
In a message dated 10/23/09 3:03:33 PM, mwie...@ahsoftware.net writes:


> on keydown var
>     dispatch "keydown" to this stack with var
>     pass keydown
> end keydown
> 
> on keydown var
>     dispatch "keydown" to this stack with var
>     put var after me
> end keydown
> 
> or in the stack script:
> 
> on keydown var
>     put var after field "blah"
> end keydown
> 

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Dispatch-Sending keyDown

[DunbarX]

Hi Colin.

Passing works just fine, but terminates the handler. I wanted to send 
keydown to the engine pretty much in the first line, which would make it write 
the char to the field. and then proceed with the remainder of the handler, 
working with the already visible text in that field. This works in HC. It just 
does not in rev.

As Jackie pointed out, there are so many other event driven opportunities 
in Rev, like "keyUp", I was able to separate the tasks. 

Craig
In a message dated 10/23/09 2:59:48 PM, co...@verizon.net writes:


> Might there be potential security issues if those could work?
> 
> Meanwhile, can you not just do a pass keydown?
> 

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Dispatch-Sending keyDown

[Mark Wieder]

Craig-

Friday, October 23, 2009, 11:15:13 AM, you wrote:

> If I type into the field, no text appears. Just like my issue with "send",
> keyDown is not passed to the engine.

Of course it is. Place a keydown handler in the stack and you'll see.

But how do you expect text to get into the field? There's no way for
the stack to know you wanted to put var into the field. Either of
these in the field script will do it:

on keydown var
dispatch "keydown" to this stack with var
pass keydown
end keydown

on keydown var
dispatch "keydown" to this stack with var
put var after me
end keydown

or in the stack script:

on keydown var
put var after field "blah"
end keydown

-- 
-Mark Wieder
 mwie...@ahsoftware.net

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Dispatch-Sending keyDown

[Colin Holgate]

On Oct 23, 2009, at 2:57 PM, dunb...@aol.com wrote:




send "keydown" && tKeyJustPressed to this stack
dispatch "keydown" to this stack with tKeyJustPressed


Might there be potential security issues if those could work?

Meanwhile, can you not just do a pass keydown?


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Dispatch-Sending keyDown

[DunbarX]

Richard and Richmond:

The R word notwithstanding, I am working with the "send" and "dispatch" 
commands as they pertain to the "keyDown" message. I have had no luck getting 
these messages to the engine, however hard I try. I am trapping "keyDown" for 
other purposes, but then want to pass it along so it can tell Rev to write 
the char.

Richard Gaskin claims he can do so with "dispatch", though not with "send", 
as in:

send "keydown" && tKeyJustPressed to this stack
dispatch "keydown" to this stack with tKeyJustPressed

There are workarounds. I just want to know why it fails.

Craig Newman


In a message dated 10/23/09 2:43:29 PM, richmondmathew...@gmail.com writes:


> 
> on keyDown var
>    put fld "fTEXT" & var into fld "fTEXT"
> end keyDown
> 
> Bl**dy silly really as the cursor doesn't travel unless you do this:
> 
> on keyDown var
>    put fld "fTEXT" & var into fld "fTEXT"
>    select after fld "fTEXT"
> end keyDown
> 
> I would just type into the field.
> 
> Objously I am missing something. . . .  do tell . . .  :)
> 

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Dispatch-Sending keyDown

[Richmond Mathewson]

dunb...@aol.com wrote:

Richard.

I have a field with this in its script:

on keydown var
dispatch "keydown" to this stack with var
end keydown

If I type into the field, no text appears. Just like my issue with "send", 
keyDown is not passed to the engine. How did you make yours work?


Craig
___
  

Well my name ISN'T 'Richard', but as I am wide awake I tried this:

on keyDown var
  put fld "fTEXT" & var into fld "fTEXT"
end keyDown

Bl**dy silly really as the cursor doesn't travel unless you do this:

on keyDown var
  put fld "fTEXT" & var into fld "fTEXT"
  select after fld "fTEXT"
end keyDown

I would just type into the field.

Objously I am missing something. . . .  do tell . . .  :)
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution