Information générale
Catégorie:
VFP Compiler for .NET
>- the this and thisform keyworkd are used extensively and they belong to the very heart of my grasp of object-orientation... Of course I do mind when they are called self or whatever.
vfp actively using container hierarchy is IMO - when viewed as evolutionary steps - further developed than WinForms linking every control at the form level. ThisForm, when called deep in container hierarchy makes sense and it also fortifies code called from rearranged hierarchies, as thisform.oBiz.oData will be reached by the same path.
>
>I understand that it may be quite a challenge to cross the two language universes, compiler-based and interpreter-based xbase technologies! That may take a bit of time:-)
Less than you think - in Ironpython I coded a GUI handler using WPF controls which read out a vfp form running off screen, building a WPF equivalent GUI tree (similar to DOM trees) and bound controlsources to the vfp COM object. Something similar to FoxInCloud, but not working across the internet and displaying HTML, but running clientside, exchanging vfp for WPF GUI.
Vfp builds a GUI tree as do most other GUI sets - otherwise dynamic XAML could never work ;-)
Yes, there are differences in approach, but not insurmountable.
>
>Daniel
Précédent
Suivant
Répondre
Voir le fil de ce thread
Voir le fil de ce thread à partir de ce message seulement
Voir tous les messages de ce thread
Voir tous les messages de ce thread à partir de ce message seulement