Jump to content


Photo
- - - - -

Making a field always mandatory (part II)


3 replies to this topic

#1 Richard Bassett

Richard Bassett

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 696 posts
  • Location:Rural France

Posted 11 December 2002 - 03:08 PM

I spent half an hour playing with Rob's original mandatory field problem (on green screen), doing a bit of detective work with BITON and BITOFF.

It seems the special treatment of the first input field can be avoided by doing a DISABLE(318) in the before-field logic.

However, this has the unwanted side effect that cancelling no longer exits the LS!
So one also needs to have the following logic at the start of the first field's general-check.
CHECK-INPUT
IF @FNKEY = &#@CANCEL OR $INPUT = '/' THEN LSEXIT ;
Then I think things seem to behave pretty much as desired (but I haven't thought about it for long).

Whether anyone in their right mind would use such an undocumented feature is a different question of course :)
Nothing's as simple as you think

#2 Andy Jones

Andy Jones

    Member

  • Members
  • PipPip
  • 41 posts
  • Gender:Male

Posted 11 December 2002 - 07:46 PM

Maybe you should also Enable (666) at application start up if you're going to do something as unholy as that!

I'm scared anyway...!

:)


Twisting the kernel's behaviour by direct setting of internal bits is probably not a very wise idea!
How can you be sure of there being no implications?
How many applications were killed or injured in the making of that tip?

(Not to mention that Support would have kittens if they were given a test case with that in it!)
Nothing is foolproof to a sufficiently talented fool...

Don't learn from your own mistakes - it's safer and more entertaining to learn from the mistakes of others!

Just because you can, it doesn't mean you should!

#3 Richard Bassett

Richard Bassett

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 696 posts
  • Location:Rural France

Posted 12 December 2002 - 10:34 AM

I'm not advocating this Andy! You'd have to be nuts to use it in a production application.

I just thought it was interesting. I merely compared the bits set in before and after logic for the first input field and it SEEMS this is the bit ProIV itself is setting to make the distinction.

Of course ProIV might be doing a lot more than that internally and twiddling undocumented bits will definitely void your warranty.. :)
Nothing's as simple as you think

#4 Dan Shannon

Dan Shannon

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 374 posts
  • Gender:Male
  • Location:Australia

Posted 13 December 2002 - 09:58 AM

What exactly are you saying that support is doing to these kittens? Should we call the RSPCA?



Reply to this topic



  


0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users