David,

>
>If the UDF has code like this:
>
>

do case
>   case poCaller.ParentClass = "textbox"
>      ....
>
>   case poCaller.ParentClass = "spinner"
>      ....

>
>Then I'd say a UDF shouldn't be used. Each respective subclass should just have the code. But this is just a matter of opinion. As long as what you are doing works in your environment and is not causing undo maintenance work then there is not a huge reason to change.

Just agreed (I get the feeling that you think I just want to do this. But I really don't ;)


>
>I've pretty much stopped doing control level valids, because they force the enduser into proceeding through a form in too much of a controlled manner, the user can not move freely between controls as their task might need to warrant. I validate the entire dataset only at Save() time.

Yes, but IMO it is not the most friendly way. Sadly, (e.g.) the locking issues with the backend database just tends to work in that direction : Press save after the hard work done, and find all rejected.
This is a matter of opinion, and I am not in favor of it.

>
>>Our general GotFocus code is around 9,000 lines (okay, including comments), and since it is really general, it would apply to the spinner only just as well. Now, WHEN it were right that all should be in the class itself and WHEN it were right that the code is really general, it would just be the 100 % redundant thing, right ? And that's exactly why it's in in the unbound PRG.
>
>That seems like it would make moving between your controls take a very long time to execute. I have to say that it seems overly complex to have a 9k line block of code controlling whether or not a user can put focus into a control.

It is not all that much about the "whether" (we don't even use the When !!), but merely about the program behind the user being in control. This is (too) about the highlighting stuff (Walter). And, it's about when to fire what Valids. Small example : click 10 controls further down the line, and all the controls in between should be validated. Validate can mean (the GUI doesn't know that) that the value of a next control changes. Etc. etc. This could even lead to the user clicking a control that becomes disabled down the line, so how could he ever have clicked it ? And then what ? So, "be in control".

... Hence, once you arrive in the GotFocus Event, you can't tell where you are thinking in procedural sequences. Events don't fire, fire in the sequence the user didn't apply, fire recursively ... it one big pile of a mess. That is, when you approach this from the OS angle.
>>But I got it running. Decently that is.
>
>I'm not following your description of the problem here Peter.
>

There is one GotFocus method. So one set of your code. But, tens of instances as subclassed from the controls, run. The point here is a bit of my own fault (I think) by allowing a control to get into focus, but then starting to fire Valids of other controls (see earlier, the controls between where the user was and where he goes to). So, the program itself gives implicitly control to other controls and gives them the focus. This has to be done in order to fire the Valids in the proper way. And ALWAYS you are in the same GotFocus code. Without the CASES, remember ?
David, I think this is too difficult to explain, but maybe you recognize the being in lack of some main Event in the middle of all (similar to the Idle event in VFP7). If YOU want to be in control, all actually wasn't made for it.


>
>Ok variable not found errors are ones that ought to be discovered by a test plan.

This one (Variable not found. without VFP mentioning the variable name) just couldn't be found. It's a runtime "feaure" only. Compare this one with the Public variable being passed as a parameter; in the called program the Public variable is unknown now. It's Fox kernel behaviour, for you the developer a bad thing, but logic anyhow (looking at the kernel). So just don't do it. The "Variable not found." is much more nasty, but in the same area. When a variable is controlsource somewhere, and under the scope of it (say, that Form) something is instantiated that uses that variable to pass as a parameter, within that called function (or whatever) it becomes unknown. It's run time behaviour because in advance you can't tell what is instantiated (users decide for that).
In the end this is a developers error (shouldn't pass a variable that is controlsource as a parameter), but the very main thing is : THERE IS NO WAY TO FIND WHICH VARIABLE IT IS. But the error handler can sort it out (all very sneaky) and can give "the" variable its content again. Misty.

>
>And yes I think they are frustrating things that I'd rather have a compiler detect at compile time. But Xbase architecture doesn't allow this to be a compiler error. The fact that the architecture allows this is also what makes Xbase such a powerful language and give us a much more dynamic runtime environment.

You just said it.


...
>>What about that ?
>
>I'm not so sure about this one. Maybe it's something that ought to be discussed in a separate focused thread or Wiki topic. We can already handle this by testing the nError value coming into the Error() method.

Ha ! and then have a CASE again ? :=)
An ON ERROR (WhatEverError) would make the code (function) dedicated (i.e. not overloaded).