>
>It's general advice. Wait Window is so CP/M
>

Well, QWERTY is so Remington and yet, here we are ;-)

Now, seriously, as I told, its purpose is to let the demonstrator to be self-contained. If one is willing to try, a simple copy & paste & run will do. I spent my fair amount of debugger time before coming to UT with this, but wouldn't expect others to have the same commitment.

>So, you say that if you pint instead of messagebox the error remains. Then it is not bound to the messagebox. Something else is the problem.
>You might run through your code and trace / breakpoint the value. Note, this is tricky. You can set THIS.listbox.value to the watch window end set a breakpoint to it. But this will go out of focus. so you need to bound this to a public variable ant watch for publicvar.listbox.value. You might find the place that alters your value this way.

No, what I said is that it won't solve the problem, that is, "how to trap a change in a ListBox after a MESSAGEBOX()".

>Nope. I let the user enter and check after they try to save. User (I'm in a small corner) found it ugly to have those checks on every boring text box. I was happy about it.
>A textbox that excepts a number is a number, one that excpects date is of date type. Why should I deal with chars? It would only be meaningfull for ranges or uniqness - but unique could be over more then one field so this is on save too.
>All what I say - it's my style and I'm happy to have not this frustrating stuff in each and every input object. I have depencies for enable etc. - but they run over central methods on eventbinding.
>Also VFP is by design a pain with VALUE, a lot of times INTERACTIVECHANGE needs a THIS.SETFOCUS to have THIS.VALUE or more controlsource set to the value entered.
>

Data typing, field length, input masks, all these are constraints that impose validation at input time, long before user clicks save.

>
>Have nice weekend.

The same to you, Lutz, and thanks again.