Peter,
>Just agreed (I get the feeling that you think I just want to do this. But I really don't ;)
I don't have a clue as to what kind of code you have in your UDFs *s*. Since there hadn't been any code posted on that area, I was just giving an example of what I'd consider a bad way of using a UDF for the purpose.
>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.
If some value can't save, (although I strive to use controls that only allow valid entries in the first place like cbo.Type=DropList), focus is set back to the field causing the problem and the user can correct and save again. Nothing is lost unless the user decides to do a Cancel and TableRevert the whole form.
>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".
Again a lot of this is predicated on your need to do control level valids. I disagree with that style of UI. This is just a difference of opinion.
>... 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.
I don't follow what you mean by "OS angle".
>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 ?
I'm glad you got something working, but it really does sound overly complex to me. Why can't you just iterate through the controls based on the TabIndex? The user leaves ControlN and wants to go to ControlM you can iterate
for i = ControlN+1 to ControlM-1. This could be done in a FormSubClass.Method() as easily as in a UDF.
>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.
Again, sounds complex, but it's working the way you want it to work so it doesn't matter.
>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).
No public memvars helps solve that problem. *s*
>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.
I also don't use memvars as ControlSources. I only real data (tables/views) or form level properties. This allows my forms to painlessly be instanced more than once.
It really sounds at the root of all of this is that you have a legacy procedural codebase that you are trying to use in VFP, and that's causing some of these design issues that you are trying to deal with by using the error handler.
>Ha ! and then have a CASE again ? :=)
A block of
ON ERROR( nError ) statements really isn't any different than a CASE statement inside the eror handler.
