Re: TARGET bug..please check

[wouter]

On 02 May 2007, at 04:06, Chipp Walters wrote:


Wouter,

Yep, I ended up doing something along the lines of what you and Ken
suggested. Though, why do you suggest adding an exitField handler?
Just in case?

-Chipp


Chipp,

Not really just in case.
Your second example stack will not have the "modal" functioning  
without an exitfield handler.
Once the dialog box is dismissed another field can be focussed (which  
was not the case in your first example stack).

In OS X that is, I don't have a winbox here to test.

on exitfield
   closefield
end exitfield

will force the re-evaluation from the closefield handler.

Greetings,
Wouter
___
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: TARGET bug..please check

[Chipp Walters]

Wouter,

Yep, I ended up doing something along the lines of what you and Ken
suggested. Though, why do you suggest adding an exitField handler?
Just in case?

-Chipp
___
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: TARGET bug..please check

[wouter]

On 01 May 2007, at 22:07, Chipp Walters wrote:


Whoops! Spoke too fast.
Wouter, thanks for the 'focus on the target' but it doesn't work with
the following stack.
Check it out:

put in the message box and hit return.

go URL "http://www.gadgetplugins.com/chippstuff/TargetBUG2.rev";

Turns out if there is a LIST field on a lower layer, the 'focus on the
target' just doesn't work.
I'll post to bugzilla.

-Chipp


Hi again,

That is why I used "more or less".
The workaround I normally use to not let the updates by the engine  
screw up
the intentions of a script (because this case is no real exception),  
is to get "behind" those updates.

Something like this:

on closeField
  if the text of the target is not empty and the text of the target  
is not a number then

beep
put the id of the target into tTarId
answer "Please enter a number."
--  the amount of millisecs may be related to processor speed
send "epilogue" && tTarId to me in 10 millisecs
  end if
end closeField

on epilogue x
  focus on control id x
  select text of control id x
end epilogue

ps: and in this particular case I would add an exitfield handler

Greetings,
Wouter
___
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: TARGET bug..please check

[Chipp Walters]

Whoops! Spoke too fast.
Wouter, thanks for the 'focus on the target' but it doesn't work with
the following stack.
Check it out:

put in the message box and hit return.

go URL "http://www.gadgetplugins.com/chippstuff/TargetBUG2.rev";

Turns out if there is a LIST field on a lower layer, the 'focus on the
target' just doesn't work.
I'll post to bugzilla.

-Chipp
___
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: TARGET bug..please check

[Chipp Walters]

Wouter,

Ding ding! That's the ticket. Your fix works perfectly...and indeed
THAT is the bug identified by RunRev support (only a few hours after I
posted to the bug database!).

Thanks for the fix. best, Chipp

On 5/1/07, wouter <[EMAIL PROTECTED]> wrote:

Hi,

For what it is worth, as there is still a focus problem with the
answer dialog box in rev 2.8.1 on OS X  (it still needs 2 clicks),
I added  a focus on line to the script after which it seems to work
more or less normally here (in OS X), the selecting part that is.

on closeField
   if the text of the target is not empty and the text of the target
is not a number then
 beep
 answer "Please enter a number."
 focus on the target  
 select text of the target
   end if
end closeField

___
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: TARGET bug..please check

[wouter]

Hi,

For what it is worth, as there is still a focus problem with the  
answer dialog box in rev 2.8.1 on OS X  (it still needs 2 clicks),
I added  a focus on line to the script after which it seems to work  
more or less normally here (in OS X), the selecting part that is.


on closeField
  if the text of the target is not empty and the text of the target  
is not a number then

beep
answer "Please enter a number."
focus on the target  
select text of the target
  end if
end closeField

Greetings,
Wouter

On 01 May 2007, at 04:25, Chipp Walters wrote:


I've discovered what I believe is to be a significant bug in the
latest release version of 2.8 and would like to verify before I post
it.

The bug has to do with a simple target expression and has to do with
existing groups on a card. It's very easy to test, if you don't mind
please check it on your system and let me know what you find. Thanks
in advance.

put into the message box and hit return:

go URL "http://www.gadgetplugins.com/chippstuff/TargetBUG.rev";

best,
Chipp


___
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: to avoid making mistakes (was TARGET bug..please check)

[Jan Schenkel]

--- Dick Kriesel <[EMAIL PROTECTED]> wrote:
> On 4/30/07 11:23 PM, "Richard Gaskin"
> <[EMAIL PROTECTED]> wrote:
> 
> > I got on this kick a while back about reducing the
> warnings in my apps,
> > looking for ways to provide guidance to the user
> to avoid making
> > mistakes in the first place.
> > 
> > With regard to validation, this trajectory led me
> to a frontScript that
> > simply prevents non-numeric characters from being
> entered into numeric
> > fields, something like this:
> > 
> > on keyDown k
> >get the uValidationType of the target
> >if it is empty then pass keyDown
> >if it is "number" AND k is in "0123456789" then
> >   pass keyDown
> >end if
> > end keyDown
> 
> Does that trajectory lead to a switch in the
> frontScript, or to focusIn
> handlers that insert their own frontScripts, or
> what?
> 
> It sounds like a good topic for an article in
> RevJournal.  I think it'd be a
> worthy feature for some Rev Standard Library too
> (unless it's become
> proprietary, of course).
> 
> -- Dick
> 

Hi Dick et al,

Putting this into a frontscript with switches based on
a custom property, is definitely the way to go for
input validation.

The tricky part is making sure the pasteKey and
dragDrop messages are handled to test if the content
will still be correct after pasting/dropping text into
a field.

This is not too hard for numerical data, but it gets
tedious to properly support date and time fields, or
text fields that may only contain plain ASCII
characters of a maximum length in a certain pattern.

Jan Schenkel.

Quartam Reports for Revolution


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

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.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

to avoid making mistakes (was TARGET bug..please check)

[Dick Kriesel]

On 4/30/07 11:23 PM, "Richard Gaskin" <[EMAIL PROTECTED]> wrote:

> I got on this kick a while back about reducing the warnings in my apps,
> looking for ways to provide guidance to the user to avoid making
> mistakes in the first place.
> 
> With regard to validation, this trajectory led me to a frontScript that
> simply prevents non-numeric characters from being entered into numeric
> fields, something like this:
> 
> on keyDown k
>get the uValidationType of the target
>if it is empty then pass keyDown
>if it is "number" AND k is in "0123456789" then
>   pass keyDown
>end if
> end keyDown

Does that trajectory lead to a switch in the frontScript, or to focusIn
handlers that insert their own frontScripts, or what?

It sounds like a good topic for an article in RevJournal.  I think it'd be a
worthy feature for some Rev Standard Library too (unless it's become
proprietary, of course).

-- Dick


___
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: TARGET bug..please check

[Chipp Walters]

Thanks Richard,

While your script works fine for numbers, it can't easily validate
email addresses, social-security numbers, zip codes, etc.. I really
need a single place I can put all this validation stuff, as the
project I'm working on has over 50 different input screens.

best,
Chipp
___
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: TARGET bug..please check

[Richard Gaskin]

Chipp wrote:

On 4/30/07, Richard Gaskin  wrote: 

Was there a version in which this worked correctly?


I tested it on 2.6.1 and it worked the same. I suppose this has been a
bug for a long time. Don't know about prior to 2.6.1. In anycase, I've
already filed a bug report.

This one seems like a significant one as it really damages the
closeField message for use in validation, unless one uses a workaround
like Ken suggests. (Thanks, Ken;-)


There's another option:

I got on this kick a while back about reducing the warnings in my apps, 
looking for ways to provide guidance to the user to avoid making 
mistakes in the first place.


With regard to validation, this trajectory led me to a frontScript that 
simply prevents non-numeric characters from being entered into numeric 
fields, something like this:


on keyDown k
  get the uValidationType of the target
  if it is empty then pass keyDown
  if it is "number" AND k is in "0123456789" then
 pass keyDown
  end if
end keyDown


--
 Richard Gaskin
 Managing Editor, revJournal
 ___
 Rev tips, tutorials and more: http://www.revJournal.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: TARGET bug..please check

[Chipp Walters]

On 4/30/07, Richard Gaskin <[EMAIL PROTECTED]> wrote:


Was there a version in which this worked correctly?


I tested it on 2.6.1 and it worked the same. I suppose this has been a
bug for a long time. Don't know about prior to 2.6.1. In anycase, I've
already filed a bug report.

This one seems like a significant one as it really damages the
closeField message for use in validation, unless one uses a workaround
like Ken suggests. (Thanks, Ken;-)

-c
___
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: TARGET bug..please check

[Ken Ray]

On Mon, 30 Apr 2007 22:05:03 -0500, Chipp Walters wrote:

> Thanks Sarah,
> 
> I put at the beginning of the script: "put the target into tTarget"
> then replaced "the target" with "tTarget" and it still acted the exact
> same way. The last statement "select text of the target" is replaced
> by "select text of tTarget" and it still selects text in the wrong
> field.
> 
> I agree, perhaps not a target bug, but some sort of weird object layer
> bug. Not sure how I can use 'closeField' to validate field contents if
> I can't reliably select the text of the field I'm checking...any
> ideas?

I posted this on the Improve list, but for the benefits of the Use 
list, here's what I do:

on closeField
  if the text of me is not a number then
send "NeedNumber" to me in 20 milliseconds
  end if
end closeField

on NeedNumber
  answer "You must enter a number."
  select the text of me
end NeedNumber

HTH,

Ken Ray
Sons of Thunder Software, Inc.
Email: [EMAIL PROTECTED]
Web Site: http://www.sonsothunder.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: TARGET bug..please check

[Richard Gaskin]

Chipp wrote:


I've discovered what I believe is to be a significant bug in the
latest release version of 2.8 and would like to verify before I post
it.

The bug has to do with a simple target expression and has to do with
existing groups on a card. It's very easy to test, if you don't mind
please check it on your system and let me know what you find. Thanks
in advance.

put into the message box and hit return:

go URL "http://www.gadgetplugins.com/chippstuff/TargetBUG.rev";


I get the same result using engine v2.8.1dp3.

Was there a version in which this worked correctly?

--
 Richard Gaskin
 Fourth World Media Corporation
 ___
 [EMAIL PROTECTED]   http://www.FourthWorld.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: TARGET bug..please check

[Chipp Walters]

Thanks Sarah,

I put at the beginning of the script: "put the target into tTarget"
then replaced "the target" with "tTarget" and it still acted the exact
same way. The last statement "select text of the target" is replaced
by "select text of tTarget" and it still selects text in the wrong
field.

I agree, perhaps not a target bug, but some sort of weird object layer
bug. Not sure how I can use 'closeField' to validate field contents if
I can't reliably select the text of the field I'm checking...any
ideas?

-Chipp
___
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: TARGET bug..please check

[Sarah Reichelt]

On 5/1/07, Chipp Walters <[EMAIL PROTECTED]> wrote:

I've discovered what I believe is to be a significant bug in the
latest release version of 2.8 and would like to verify before I post
it.

The bug has to do with a simple target expression and has to do with
existing groups on a card. It's very easy to test, if you don't mind
please check it on your system and let me know what you find. Thanks
in advance.


Hi Chipp,

I get the same results using 2.8.0-gm-4 and 2.8.1-dp-3 with Mac OS X 10.4.9

It works fine if I tab out of the field, but not if I click.

However I'm not sure it is a "target" problem, since I added "put"
statements to tell me what "the target" was at various points. I had
to give your 2 fields different names so I could check, but it was
always giving me the correct target. It's as if the click in the other
field is being processed after the "select text" command.

However why this is fixed by deleting the other group is a mystery, so
it definitely needs a bug report.

Sarah
___
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: TARGET bug..please check

[Curtis Ford]

I get the same problem Chipp describes. OS X, 10.4.9, with various
versions of 2.7 through 2.8.

best

Curt

Dr. Curtis Ford
Instructor of Russian and Linguistics
Dept of Languages, Literatures and Cultures
University of South Carolina
(803) 777-9615
[EMAIL PROTECTED]
___
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

TARGET bug..please check

[Chipp Walters]

I've discovered what I believe is to be a significant bug in the
latest release version of 2.8 and would like to verify before I post
it.

The bug has to do with a simple target expression and has to do with
existing groups on a card. It's very easy to test, if you don't mind
please check it on your system and let me know what you find. Thanks
in advance.

put into the message box and hit return:

go URL "http://www.gadgetplugins.com/chippstuff/TargetBUG.rev";

best,
Chipp
___
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