Why does this show no errors when I test with the goto but errors with Throwfocus? Does it have something to do with the fact that goto ends the program and ThrowFocus allows the programming to finish?

What do I have wrong?

SUBROUTINE DoAssignLocationInfo()
var vName as String
var vZip as String
var vLVals as String

// checks for 5 digits in zip code

If @len(@num(ThisElement)) <>5 then

{
@Msgbox("The ZipCode Must be" , "at least five digits." , "Please correct the entry.")

     // RGBColor(ThisElement,",",",255,0,0)
      Throwfocus ThisElement
}
else

{

    vName = @ElementName(ThisElement)
    vZip = ThisElement
    vLVals = GetLocationInfo(vZip)


    If @Len(vLVals) > 0
    {
   AssignLocationInfo(vName, vLVals)
    }
}   
END SUBROUTINE

I also tried this and 2000 other possibilities


SUBROUTINE DoAssignLocationInfo()
var vName as String
var vZip as String
var vLVals as String


    vName = @ElementName(ThisElement)
    vZip = ThisElement
    vLVals = GetLocationInfo(vZip)

// checks for at least 5 digits in zip code

If @len(@num(vzip)) <> 5 then

{
     @Msgbox("The ZipCode Must be" , "at least five digits." , "Please correct the entry.")

     // RGBColor(ThisElement,255,255,255,255,0,0)
      ThrowFocus vzip
}
else

{


    If @Len(vLVals) > 0
    {
   AssignLocationInfo(vName, vLVals)
    }
}   
END SUBROUTINE

Quote:



Dang it,  I have read page 12 of the 1.0.4 supplement at least 200 times since yesterday, No Kidding.  I have tried everything with the code possible and a simple basic thing like that messes me up. (Shame on me) I was so busy looking for something wrong with the logic I missed the simplest thing.

Thanks for the help, Sorry it was for something so stupid.

The combination of the @MsgBox and the ThrowFocus may be creating an event loop, depending on where things are being called. I can't tell without seeing the rest of your code.

Regardless, you may want to consider using the alternate method of data validation that I showed you in the SBasic class, rather than creating a "trap".   

The phrase that comes to my mind is: "Control the data, not the user".

As an ancilliary: "It is better to accept a mistake than enforce one".

As an example, take phone numbers: From my phone in a office building, any of the following are legal phone numbers:

*8
3-81
011-49-222-444-111
1-800-555-1200 @ 444
1-800-555-1200 ext 4444
751-1212
(321) 123-1234
(321) 123-4444-8-1234
(321) 123-4444 or (321) 123-9999 if after noon, but before 6:00
+49-222-444-111

The variety is pretty much endless. The situation is similiar with postal codes, first and last names, currency, any unit of measurement, etc...

The irony of this seemingly untenable situation is that the humans using the computer deal with it fine, it really only becomes a problem when the programmer/designer attempts to enforce an overly narrow set of conditions on the users. In other words, the programmer tries to make the user create uniformity in data, where uniformity is actually incorrect.

If, you enforce that a phone number must be (xxx) xxx-xxxx, you will begin to see addtions, notes, and alterations appearing in less frequently used fields nearby. That reduces the value of the phone number field (which is usually only used by humans that can and do understand that "Ext" and "@" both mean "extension") and the nearby field, that starts to become nonsensical.

Very often the best thing a programmer can do to prevent typos while still allowing for the correct non-conformity of data, is to be adaptive. Check the data against a set of known good formats, if it matches none of them, ask the user if they are sure. If they are, add that "new" format to the list of known good formats.

Quote:

Excellent suggestion Mark!