Hi Thomas,

I don't disagree with that. I have most UI actions controllable from metadata, and room for customized commands. So yes, I don't spend time in control events, except in those complex UI's for whom it isn't worth attempting to rationalize the metadata/action interface.

Hank

>Hi Hank,
>
>>Notice that Vulcan.net hasn't really done much with the .Net language: e.g., to put code in a click event, you have to use an eventhandler. Eeesh. I realize that VFP is doing that behind-the-scenes, in some fashion: and that's the point -- 99% of the instances of connecting code to a click event does not require multiple targets, so the IDE shouldn't require the use of an eventhandler.
>
>at least something in architecture we don't see totally eye to eye<g>. I think MS attempts to decouple GUI and programming logic as one of the better ideas of Dotnet, although seriosly marred by their love for code generation. If a click is needed, I call out into a GUI-biz-tier based on naming conventions if not overriden with specific call targets (either manually or via DD) just the same as for validation. Net effect: almost automatic set up for the event handler and no code in the GUI itself - for instance for switching to another page via outlook bar or doing some pure GUI stuff like embolding certain lables if another control is not readonly any more. The mentioned control changing the readonly status is bound to a more traditional biz layer, but also with methods set up via properties and coding conventions (sort of a set of default mappings following the name convention) and dynamically loading the objects "housing" the targeted methods from values - thus implementing a flexible factory and minimizing the need to even generate actual gluing code. Did too much boring work of cleaning out GUI from spr/vcx biz code - and IMHO the ease of putting too many snippets in click(), validated() and the 2 change-Methods created apps whehre the amount saved in coding was lost later after the first dev change. And it certainly did not train the devs to at least refactor the common parts out of the snipptes, as they were all over the form.
>
>>And it's not that a VFP programmer can't write an eventhandler -- we've had them in VFP9 for what, 6 years? It's just that those distractions add up.
>
>That is the job of the fwk has to lessen for me. vfp lured many onto the path "easy to write-hell to support".
>
>regards
>
>thomas