VFP 5.0: Nouveau et meilleur!

José Constant, January 1, 2001

Voici une version de Visual FoxPro beaucoup plus mûre que la précédente. Visual FoxPro 3.0 introduisait la programmation orientée objet et le Database Container. Mais il s’agissait en quelque sorte d’une première version, handicapée du fait qu’elle devait t...

Cependant, la transition vers une programmation orientée objet n’est pas totalement terminée: les rapports et les menus ont peu évolué depuis les versions 2.x et les possibilités du Database container restent un peu limitées. Mais une version 6.0 est déjà en route et apportera certainement son lots de nouveautés dans le domaine. En attendant, je ne puis que conseiller à tous ceux qui ont la chance de travailler pour des clients équipés de matériel 32-bit de passer à Visual FoxPro 5.0 le plus rapidement possible.

Microsoft semble enfin décidé à donner plus de visibilité au produit, puisque Visual FoxPro (dans sa version 5.0a) fait partie aux côtés de Visual C++ et de Visual Basic 5.0 de la nouvelle suite Visual Studio, lancée en mars dernier. Les demandes en développeurs VFP vont se multiplier…

Dans les lignes qui suivent, nous allons passer en revue de manière systématique les améliorations apportées au produit (version 5.0a, US) par rapport à la version 3.0b.

• L’interface du gestionnaire de projets est similaire à l’explorateur de Windows 95; il suffit de cliquer sur le signe ‘+’ pour détailler l’arborescence. Les lignes connectant les icônes entre elles montrent la hiérarchie entre les différents éléments d’un projet. Il est possible d’assigner des icônes spécifiques aux librairies de classes, d’accéder aux propriétés de contrôle du code source et de naviguer avec le clavier.
• Le gestionnaire de projets conserve les numéros de version et peut incrémenter les révisions à chaque compilation (après BUILD EXE ou BUILD OLE)
• Nouvelle option pour lancer l’application automatiquement après compilation ( après BUILD APP ou BUILD EXE)
• Nouvelle option pour générer une DLL serveur OLE au départ d’un projet et l’enregistrer automatiquement dans le registre de Windows..
• Le gestionnaire de projets restaure la dernière configuration lorsque l’on rentre à nouveau dans VFP.

• Syntaxe colorée: vous pouvez maintenant attacher une couleur spécifique aux mots clés, aux commentaires, etc. C’est vrai aussi pour la fenêtre de commande.
• Beautify est de retour: indentation du code, capitalisation des mots clés, etc…
• Un clic droit de la souris offre une série d’options, notamment celle d’afficher une liste de toutes les procédures dans une fichier .PRG. Cliquer sur l’une de procédures positionne immédiatement le curseur à son début. Des blocs entiers de texte peuvent être commentés ou décommentés.
• Clic droit / Propriétés donne accès à toutes les propriétés de l’éditeur.
• Clic droit / Execute a pour effet d’exécuter le PRG que vous êtes en train de modifier.
• Clic droit / Build Expression amène "l’Expression builder". Quand vous avez terminé, l’expression est collée dans le texte
• Les polices de caractères peuvent être définies pour chaque fichier individuellement.
• Sélectionnez quelques lignes dans votre PRG ou la fenêtre de commande; l’option "Execute selection" exécutera ces lignes.
• "Poursuivre la recherche" est de retour (CTRL+G). L’option recherche (Find) fournit une liste des derniers éléments recherchés.

• La fenêtre "Trace": l’objet et la méthode à suivre peuvent être sélectionnés au départ de listes. L’option "Set Next" permet de forcer l’exécution du programme dans un ordre non naturel. Si la souris est positionnée sur le nom d’une variable, sa valeur est affichée dans une info-bulle.
• La fenêtre "Watch": la valeur courante d’une variable peut être changée en double-cliquant dessus. Les tableaux et les objets sont affichés dans une structure en arborescence. En cliquant dessus, on peut voir le détail de chaque membre sur une ligne séparée.
• La fenêtre "Locals": celle-ci affiche toutes les variables locales et les objets pour une méthode déterminée. L’affichage peut être limité aux variables publiques, locales ou standard ou encore aux seuls objets. Ici aussi, une valeur peut être changée en double-cliquant dessus. Les tableaux et les objets sont affichés dans une structure en arborescence. En cliquant dessus, on peut voir le détail de chaque membre sur une ligne séparée.
• La fenêtre "Debug Output": celle-ci affiche les messages spécifiés par DEBUGOUT (voir ci-après)
• Points de rupture: ils peuvent être définis sur le numéro de ligne dans une méthode, ou quand une valeur devient vraie ou encore quand une expression change. L’endroit ou l’exécution du code doit s’interrompre peut être spécifié. Un compteur permet de n’interrompre un programme qu’à la n^ème itération. Les points de rupture peuvent être rendus inopérants sans que l’utilisateur doive pour cela les supprimer.
• Suivi des événements: toute combinaison d’événements associés aux formulaires et à leurs contrôles peut être enregistrée dans un fichier texte, ou affichée dans la fenêtre.
• Un fichier journal peut être enregistré de manière à visualiser quelle ligne de code a été exécutée, et le temps que demande chaque opération. On veillera à ne jamais prendre en compte le résultat d’une seule passe, mais plutôt la moyenne de plusieurs essais. En effet Visual FoxPro effectue tout un travail de "garbage collection" en tâche de fond qui pourrait venir influencer les résultats d'un test.
• "Fix": le code erroné d'un formulaire peut être corrigé au départ du débogueur.
• ASSERT , SET ASSERT ON: des assertions peuvent être incrustées dans le code; elles spécifient un message à afficher quand une valeur logique est fausse. Toutes les assertions peuvent être rendues inopérantes par la commande SET ASSERTS OFF .
• SET EVENTTRACKING ON/OFF/TO, SET EVENTLIST TO: ces commandes peuvent être utilisées pour activer le suivi des événements au départ du code lui même.
• SET COVERAGE TO: cette commande s’utilise pour activer l’enregistrement du défilement du code dans un fichier journal.
• DEBUGOUT: incrustée dans le code, cette commande va envoyer une expression dans la fenêtre "debug output". Veillez à ne pas abréger DEBUGOUT à moins de 6 charactères, de façon à premettre la distinction avec la commande DEBUG.
• SET DEBUGOUT TO: spécifie le fichier vers lequel rediriger les messages de la fenêtre "Debug Output".

• Sa fonctionnalité a été étendue aux projets, fichiers .TLB (Typelib), et .OLB.
• L’explorateur de classes comprend le nom de la classe et de la libraire, une liste hiérarchisée des objets contenus, un description de l’objet sélectionné et la liste de ses propriétés.
• Les propriétés et méthodes peuvent être renommées par un simple clic droit et la sélection de l’option "Rename".
• Une méthode peut être éditée directement en double-cliquant dessus.
• Il est possible d’accéder directement à la classe parent de l’objet sélectionné.

• Il n’est plus nécessaire d’avoir un accès exclusif à la base de données (fichier .DBC) pour la modifier. Un menu "Refresh" et un raccourci clavier sont prévus pour rafraîchir le contenu de la base de données qui aurait pu être modifié par un autre développeur.
• De nouvelles options améliorent la lisibilité: limiter la visualisation aux tables, vues locales, vues éloignées ou relations. Une recherche rapide fournit la liste de tous les objets pour un accès rapide.

• Meilleure lisibilité grâce aux onglets séparés pour les définitions de champs, d’index et les propriétés de la table.
• Les propriétés de formatage "Input Mask" et "Format" peuvent être spécifiées pour chaque champ en particulier.
• Les sélections de menu "Tools / Options / Field Mapping" permettent de spécifier les classes devant être utilisées par défaut quand vous copiez-collez un champ sur un formulaire.
• Une classe différente peut être définie dans le "table designer" pour des champs spécifiques.
• Des règles de validation de champ et d’enregistrement peuvent comporter du code qui modifie la table à laquelle ils appartiennent. Cependant, cette technique ne peut s'appliquer aux "triggers".

• Meilleure lisibilité grâce aux onglets séparés pour les conditions de jointure et les filtres.
• Nouvelle fenêtre permettant la définition des propriétés de chaque champ de la vue ("input mask", "caption", "validation rules", "default values", "display class", et "data type/size"). Malheureusement ces propriétés ne reprennent pas les valeurs par défaut définies au niveau de la table, contrairement à ce qu’offrent des outils comme xCase. Si vous pensez travailler avec des vues locales, définissez les propriétés au niveau des vues et laissez celles des tables vierges…
• Les champs calculés et les alias sont sauvegardés avec la définition de la vue et peuvent être modifiés par la suite. C’est une amélioration importante par rapport à 3.0 où toute modification ultérieure était impossible.

• Les "outer joins" sont intégralement supportés: gauches, droits et complets ! Ceci a demandé une modification du langage SQL supporté par FoxPro. Les conditions de jointure sont maintenant exprimées dans la clause FROM et on laisse à la clause WHERE la définition des filtres.

• VFP supporte maintenant les requêtes de type "Top number", c’est-à-dire la sélection des n lignes ou des n pourcent. Il est possible de sélectionner le bas du classement en utilisant la clause DESCENDING . Attention, ne pas trop se fier au fichier d’aide qui comporte des erreurs; préférez l’expérimentation.
• SELECT … NOFILTER: force VFP à créer physiquement un curseur plutôt que de faire d’utiliser la table AGAIN avec un filtre, comme il le fait parfois pour des requêtes simples.
• SELECT … FORCE: force VFP à exécuter les joints dans l’ordre spécifié par la commande SQL, plutôt que de lui laisser optimiser l’ordre de l’exécution.
• CompareMemo: Cette propriété de la vue contrôle si les champs mémo sont inclus pour déterminer si des mises à jour doivent être envoyés au serveur.
• FetchAsNeeded: dans une grille ou un browse, cette propriété laisse VFP obtenir des lignes selon ses besoins si l’utilisateur dépasse en scrollant le nombre d’enregistrements déterminés par le "FetchSize" original.
• SQLPREPARE(): demande au serveur de précompiler la commande SQL sans l’exécuter. SQLEXEC peut ensuite être appelé sans repasser la commande SQL. Ceci permet d’éviter sa recompilation à chaque demande et augmente la rapidité d’exécution.
• Le "SQL pass-through" peut maintenant passer des paramètres par référence à des procédures éloignées et recevoir des valeurs en retour de ces paramètres.
• Meilleure compatibilité ANSI , comme par exemple DROP VIEW (3.0 supportait seulement une commande non standard DELETE VIEW).
• DROP TABLE RECYCLE place une copie de la table dans la corbeille quand elle est éliminée de la base de données.
• SQL Showplan: La fonction SYS(3054) est un excellent outil d’optimisation des requêtes. Elle montre à l’écran les différents niveaux d’optimisation Rushmore: complet, partiel, ou non optimisé.
• DBGETPROP(): comme on pouvait s’y attendre, les nouvelles propriétés ajoutés au "Table Designer" et au "View Designer" peuvent être retrouvées en code, comme par exemple "DisplayClass", "DisplayClassLibrary", "Format" et "Input Mask". Pour les vues, celles-ci incluent "CompareMemo", "FetchAsNeeded", "OffLine" et "Prepared". Pour les connections il y a "Database".

Une vue "offline" se crée avec la fonction CREATEOFFLINE Il faudra bien sûr prévoir le code qui gèrera les conflits qui pourraient surgir lors de la mise à jour de la base de données maître.

• TABLEUPDATE(): nouvelle méthode de mise à jour d’enregistrements multiples quand le "table buffering" est actif.
• Avec VFP 3.0, si le premier paramètre était un .T. (mettre à jour toutes les lignes) et le second un .F. (ne pas écrire sur les modifications d’un autre utilisateur), TABLEUPDATE s’arrêtait sur le premier enregistrement à avoir été changé par un autre utilisateur et générait une erreur. Il n’y avait plus de mise à jour possible au-delà de ce point.
• Avec VFP 5.0, le premier paramètre nRows accepte maintenant des valeurs numériques (0, 1 ou 2). Zéro et 1 sont équivalents à .F. et .T. en 3.0. Si 2 est spécifié, TABLEUPDATE ne s’arrêtera pas sur le premier enregistrement en conflit, mais tentera de mettre à jour tous les enregistrements suivants. Si un tableau est passé comme 4^ème paramètre, une liste des numéros d’enregistrement n’ayant pu être mis à jour est placée dans le tableau.
• COPY <tablename> TO DATABASE <databasename : Ce nouvel argument à la commande COPY TO place la copie dans une base de données en préservant tous ses attributs (noms de champs longs, règle de validation, etc.)

• Sélections multiples: vous pouvez sélectionner plusieurs objets d'un formulaire et changer globalement leurs propriétés.
• Propriétés modifiées: le panneau "propriétés" a une option permettant de n'afficher que celles qui ont été modifiées par rapport à la classe parent.
• Zoom: clic droit / Zoom sur un objet du panneau "propriétés" fait apparaître le contenu dans une fenêtre d'édition plus grande.
• Polices: le panneau "propriétés" peut maintenant être affiché dans trois tailles de police différentes.
• Hide descriptions: la zone description au bas du panneau "propriétés" peut être enlevée pour permettre la visualisation d'un plus grand nombre de propriétés à la fois.
• A l'ajout d'une nouvelle propriété ou méthode à un formulaire, le dialogue "New Property" ou "New Method" reste actif de façon à permettre l'ajout rapide de nouvelles propriétés ou méthodes.
• Quand le panneau "propriétés" est actif, il est possible de passer à l'objet suivant d'un formulaire par la combinaison de touches <Ctrl+PgDn>; pour passer à l'objet précédent, il suffit de presser <Ctrl+PgUp>.
• A l'édition des méthodes, toutes celles qui contiennent du code sont placées au dessus de la liste déroulante pour un accès plus aisé.
• Il y a une option pour sauvegarder les changements automatiquement sans dialogue de confirmation.
• Les librairies de classe que vous ajoutez à la barre d'outils de contrôles de formulaires sont présentes quand vous utilisez VFP à nouveau.
• Un nouveau bouton sur la barre d'outils permet de modifier un formulaire en cours d'exécution.
• Quand on choisit de faire exécuter un formulaire au départ du "form designer", puis qu'on le ferme, celui-ci est automatiquement réouvert pour être modifié.

• Les objets tirés du Data Environment ou de l'onglet Data du Project Manager et déposés sur un formulaire peuvent être basés sur vos propres classes. (En 3.0, il s'agissait toujours des classes de base de VFP). C'est ce que Microsoft appelle l'Intellidrop. Les classes à utiliser par défaut pour chaque type de champ sont à spécifier dans "Tools/Options". Ces valeurs peuvent être remplacées au niveau du Table Designer (voir à ce sujet la section Amélioration à la gestion des données / Table Designer).
• Si vous déposez un champ sur un formulaire par un clic gauche de la souris, VFP copie les propriétés InputMask, Format et Comment spécifiées pour le champ dans le Table Designer. Chacune de ces fonctionnalités peut être désactivée dans "Tools/Options". VFP peut aussi créer une étiquette à gauche du contrôle, reflétant sa propriété Caption, si elle existe, ou le nom de champ dans le cas contraire. Si une classe Label a été définie dans "Tools/Options", c'est celle-ci qui sera utilisée plutôt que la classe de base de VFP.
• Les contrôles sont mis automatiquement à dimension en fonction de leur taille et de la propriété MaxLength pour les textboxes.
• Des conventions de dénomination standard sont maintenant utilisées pour les contrôles. Ainsi un textbox sera dénommé "txt" plus le nom de champ.
• Un clic gauche accompagné du déplacement de plusieurs champs crée une grille composée de ces champs uniquement. Les captions sont utilisés comme entêtes pour les colonnes. Malheureusement on ne retrouve ici que les classes de base de VFP, ignorant les propriétés InputMask et Format.
• Un clic droit accompagné du déplacement d'un champ provoque l'apparition d'un menu avec les options suivantes:
• "Create <classname> here" (dans lequel <classname> est la classe spécifiée au niveau du mappage des champs);
• "Create other control here". Ce dernier choix provoque l'apparition d'un dialogue permettant de choisir la librairie et la classe à associer au contrôle.
• Un clic droit accompagné du déplacement de plusieurs champs provoque l'apparition d'un menu avec les options suivantes:
• "Create grid here" pour la création d'un grille (correspond au choix du clic gauche);
• "Create multiple controls here". Ce dernier choix provoque l'apparition d'un dialogue permettant de choisir la librairie et la classe à associer aux contrôles. Des contrôles multiples sont alignés à gauche lorsqu'ils sont placés sur un formulaire.

• Des formulaires de type SDI "top-level" peuvent maintenant être créés en jouant sur la propriété ShowWindow. Ces formulaires sont indépendants du bureau VFP, apparaissent comme éléments séparés dans la barre de tâches et sont visibles quand le bureau VFP est minimisé. De tels formulaires disposent de leur propre menu. Malheureusement, ils ne tournent pas comme des tâches séparées.

• Celle-ci peut être utilisée pour empêcher l'ouverture automatique de vues locales ou distantes quand un formulaire est lancé

• En VFP 3.0, si la code de la méthode Init() d'un seul contrôle retournait un .F., la méthode Init() du formulaire échouait, et celui-ci n'apparaissait jamais à l'écran. En 5.0, le formulaire apparaîtra. Seul le contrôle dont l'Init() a retourné .F. n'apparaîtra pas.
• En VFP 3.0, si l'objet A d'un formulaire faisait référence à l'objet B comme étant son ControlSource, une erreur apparaissait si l'objet A était créé avant l'objet B. En VFP 5.0 le lien entre les objets a été différé de manière telle que l'arrangement décrit ci-dessus fonctionne parfaitement.

• De nouveaux menus contextuels peuvent être créés dans le Menu Designer. Ils s'affichent lorsque l'utilisateur effectue un clic droit sur un objet. La mise en œuvre est simple, puisqu'il suffit d'ajouter la ligne "DO xxx.mpr" à la méthode RightClick() de l'objet concerné.
• Normalement, la code Cleanup() d'un menu contextuel est exécuté quand le menu est désactivé. L'ajout de la directive #PrePop au code Setup() d'un menu place le code Cleanup() avant la commande ACTIVATE POPUP dans le menu généré (.MPR). Cela permet l'ajout de code modifiant le contenu du menu contextuel avant son apparition.

• Il s'agit de menus attachés aux formulaires SDI, plutôt qu'au bureau VFP.

• Permet l'exécution de tout élément du menu système VFP disponible (par exemple _MED_COPY) sans devoir recourir aux commandes KEYBOARD dont l'usage n'est pas recommandé.

• Le Menu Designer propose une nouvelle option, "Menu/Insert Bar". Celle-ci affiche une liste de tous les éléments du menu système VFP. Si on sélectionne un élément, il est automatiquement inséré dans le menu en création, avec ses propriétés Prompt, Bar Number et Message.

• DODEFAULT(): cette commande a pour effet d'exécuter la méthode du même nom dans la classe parent. Elle remplace la notation en "::" utilisée en VFP 3.0, comme par exemple dans CommandButton::Init() qui imposait de connaître le nom exact de la classe parent.
• RightToLeft: spécifie que le texte est entré et affiché de droite à gauche ( réservé aux versions Middle East de Windows 95 et NT).
• IMEMode: détermine de quelle manière la fenêtre Input Method Editor se comporte (réservé aux versions Far East de Windows 95 et NT)
• ColorSource: une nouvelle option a été ajoutée, il s'agit de "Windows Control Panel (Windows Colors)". Celle-ci a pour effet de d'adapter les couleurs d'un formulaire au jeu de couleurs utilisé par Windows.
• Hours: détermine si les valeurs DateTime sont affichées en format 12 ou 24 heures.
• NullDisplay: spécifie le texte à afficher (par exemple "Rien à afficher") quand la valeur d'un contrôle est .NULL.; cette valeur remplace celle définie plus globalement dans SET("NULLDISPLAY")
• SelectOnEntry: détermine si le contenu d'un contrôle est mis en surbrillance quand il reçoit le foyer (même effet que "K" en format).
• Text: similaire à la propriété Value, mais contient exactement ce que l'utilisateur a entré, toujours en format caractère (ignore le type de données et les formatages @R).

• AllowAddNew: si cette propriété est .T., de nouveaux enregistrements peuvent être ajoutés à la table en pressant la flèche Å sur la dernière ligne de la grille.
• AllowHeaderSizing, AllowRowSizing: peut empêcher l'utilisateur de redimensionner les entêtes des colonnes ou la hauteur des lignes.
• InputMask, Format, et DynamicInputMask: peuvent maintenant être spécifiés pour une colonne, et fonctionnent même si celle-ci est Sparse. (En 3.0, il fallait définir un InputMask pour le contrôle contenu dans la colonne et mettre le Sparse à .F., ce qui avait pour effet de ralentir l'exécution).
• HighlightRow: permet de supprimer la surbrillance de la ligne et de la cellule sélectionnée.
• SplitBar: utile pour enlever la split-bar d'une grille, réduit l'utilisation de la mémoire.
• Alignment: les colonnes et les entêtes on maintenant 10 choix d'alignement par la combinaison de "bas", "milieu", et "haut" avec, "à gauche", "centré" ou "à droite".
• DynamicAlignement: ici aussi, dix choix sont possibles.

• BoundTo: en VFP 2.6 et 3.0, une combobox dont la colonne liée était un champ numérique retournait le numéro de la ligne sélectionnée, pas la valeur du champ. Maintenant si BoundTo est .T., la combobox retournera la valeur du champ numérique, plutôt que le numéro de la ligne.
• InputMask, Format et ReadOnly: maintenant disponibles.
• ItemTips: Si .T., et que l'on postionne le curseur sur une ligne d'un combobox, une info-bulle apparaîtra pour montrer le contenu complet de la ligne si celle-ci est trop large par rapport au combobox.
• BorderStyle: si 0, aucun bord n'apparaît, ce qui rend l'intégration dans une grille plus propre.

• Century: détermine si le siècle est affiché en 2 ou 4 digits; remplace la valeur définie globalement dans SET CENTURY.
• DateFormat: remplace pour ce contrôle la valeur définie globalement dans SET DATE .
• DateMark: remplace pour ce contrôle la valeur définie globalement dans SET MARK (par exemple 99/99/99 au lieu de 99-99-99).
• StrictDateEntry: si ‘0-Loose’ est choisi, l'utilisateur peut entrer sa date de manière incomplète ("31 12" sera stocké de manière interne comme "31/12/97").
• Seconds: spécifie si la portion "secondes" d'une valeur DateTime est affichée.
• MaxLength: spécifie le nombre maximum de caractères qui peuvent être entrés, évitant le recours aux formatages de type "XXXXXXXX". Cette valeur est définie automatiquement quand un champ est déposé du Data Environment ou de l'onglet Table du Project Manager sur un formulaire. (En 3.0, MaxLength n'était disponible que pour les Editboxes).
• IntegralHeight: si .T., adapte la hauteur d'un contrôle à un nombre de lignes entières, de façon telle que la dernière ligne soit entièrement visible.

• IntegralHeight: si .T., la taille de la boîte est ajustée à une valeur multiple du nombre de lignes, de façon telle que la dernière ligne soit entièrement visible.

• IntegralHeight: si .T., la taille de la boîte est ajustée à une valeur multiple du nombre de lignes, de façon telle que la dernière ligne soit entièrement visible.
• ItemTips: Si .T., et que l'on positionne le curseur sur une ligne d'une listbox, une info-bulle apparaîtra pour montrer le contenu complet de la ligne si celle-ci est trop large par rapport au listbox.
• MultiSelect: en VFP 3.0, celui-ci était limité à 60 lignes. Il n'y a plus de limite.

• InputMask: maintenant disponible
• BorderStyle: si 0, aucun bord n'apparaît, ce qui rend l'intégration dans une grille plus propre.

• Wrap: permet à un commandbutton d'avoir un caption de plusieurs lignes.

• Les pages peuvent maintenant recevoir le foyer; en VFP 3.0, seuls les objets se trouvant sur une page pouvaient le recevoir.
• Quand une page a le foyer, on passe à la suivante par la flèche Ä et à la précédente par la flèche à .
• TabStyle: l'onglet d'un page frame peut être non justifié; sa taille s'adapte à la taille du titre (caption). L'ensemble des onglets n'occupe pas nécessairement toute la largeur de la page.
• TabStretch: permet l'usage d'onglets à lignes multiples.

• La barre d'outils de l'option preview a maintenant un bouton "Print" qui permet d'imprimer directement.

• La commande REPORT FORM accepte de limiter l'impression à un nombre de pages déterminés.

• Un contrôle ActiveX peut maintenant être lié à un champ ou une variable. Attention, le complex data binding, comme par exemple le lien à plusieurs lignes / colonnes d'une grille, n'est pas encore supporté.

• Un click droit sur une objet OLE (en phase de développement) fait apparaître un menu contextuel contenant les propriétés, méthodes et l'accès au fichier d'aide d'un objet OLE.

• Un contrôle ActiveX placé sur un formulaire VFP tourne de manière asynchrone. Il peut provoquer des événements qui doivent être traités par VFP alors que celui-ci est occupé à l'exécution d'une méthode. En VFP 3.0, ces événements soit étaient simplement ignorés, soit venaient interrompre l'exécution de la méthode! En mettant la propriété AutoYield de l'application à .F., les événements provoqués par le contrôle ActiveX sont mis dans une queue et seront traités soit quand la commande DOEVENTS sera exécutée, soit la prochaine fois que VFP s'arrêtera en attente d'une action de l'utilisateur..

• Certains contrôles ActiveX ont besoin d'une référence pour accéder à des fichiers contenant des images (BMP, .ICO, et .WMF), plutôt que simplement le nom du fichier. LOADPICTURE() crée une référence pour l'objet au départ de son nom de fichier. SAVEPICTURE() crée un fichier BMP au départ de la référence retournée par un contrôle ActiveX.

• Cette fonction convertit des données de type caractère créées en VFP en une chaîne type binaire que l'on peut passer un à contrôle ActiveX.

• FoxDoCmd(): exécute une commande VFP passée sous forme de chaîne de caractères comme dans FoxDoCmd("SELECT * FROM customer"). Un second paramètre permet de déterminer si la fenêtre VFP apparaît quand la commande est exécutée ou si celle-ci est exécutée de manière invisible.

• FoxEval(): évalue une expression VFP et renvoit le résultat via un paramètre passé par référence, par exemple oApp.FoxEval("PROPER(‘jim’)", @lcBuffer ,lnBuflen)
• SetErrMode(): spécifie si les erreurs de VFP5.DLL sont affichées dans un message ou invisibles.
• GetLastErr(): le dernier message d'erreur survenu dans VFP5.DLL, renvoyé dans un paramètre passé par référence.
• SetOleObject(): permet à VFP5.DLL d'appeler une application OLE ne supportant pas l'automation.
• CloseIt(): ferme l'objet OLE créé par FoxDoCmd() ou FoxEval().

• Vous pouvez maintenant au départ d'un projet VFP construire une .DLL qui va être utilisée comme serveur d'automation OLE. Cette .DLL, et quelques autres .DLL's de support peuvent être installées sur une machine ne disposant pas de VFP complet. Les méthodes de cette .DLL peuvent être appelées directement par des applications clientes, comme Excel par exemple.
• Pour créer un serveur d'automation OLE en VFP, vous créez d'abord une classe qui contrôle l'application et contient les méthodes à exposer. Vous la marquez comme 'OLE Public' dans le Class Designer. Vous la placez dans un projet et sélectionnez 'Build DLL'. Cette .DLL est automatiquement enregistrée sur votre machine. Si vous l'installez sur une autre machine, elle peut y être enregistrée par la commande REGSVR32.EXE ma.dll.
• Trois propriétés contrôlent la façon dont le serveur répond à des demandes multiples:
• OLERequestPendingTimeout: spécifie le temps pendant lequel une requête peut attendre avant que le message "occupé" n'apparaisse.
• OLEServerBusyTimeout: spécifie le temps pendant lequel une requête peut attendre avant qu'une erreur "temps dépassé" ne soit renvoyée à l'application appelante.
• OLEServerBusyRaiseError: spécifie si un message d'erreur visible est affiché quand une requête dépasse le temps qui lui est imparti.

• FullName: le nom de fichier et le répertoire au départ desquels l'application a été lancée.
• StartMode: la manière dont l'application a été lancée (session VFP interactive, out-of-process OLE server, runtime out-of-process OLE server, ou in-process OLE server).
• DefaultFilePath: le répertoire par défaut utilisé par l'application.
• Objects collection: une collection des objets utilisés dans l'application.
• Help(): ouvre la fenêtre d'aide de l'application.
• Quit(): ferme l'application.
• DoCmd(): exécute une commande VFP passée sous forme d'une chaîne de caractères.
• Eval(): évalue une expression VFP passée sous forme d'une chaîne de caractères.
• SetVar(): crée une variable et lui assigne une valeur (ApplicationObject.SetVar(cVariableName, eValue))
• RequestData(): renvoie un tableau contenant un certain nombre d'enregistrements d'une table ou d'un curseur.
• DataToClip(): copie un nombre donné d'enregistrements d'une table ou d'un curseur sur le presse-papiers de Windows en texte délimité.

• CD ? appelle le dialogue GetDir() exactement comme dans SET DEFAULT TO GETDIR()
• CD "C:\VFP5" définit le répertoire par défaut

Convertit des valeurs d'integer en chaîne de caractères binaires et vice-versa. Utile dans la création d'index complexes comportant des champs de type integer. Il ne s'agit pas d'une notation hexadécimale, mais bien plutôt des bytes dans l'ordre haut Ä bas. Ainsi BINTOC(255) retourne CHR(128)+CHR(0)+CHR(0)+CHR(255) et non pas "000000FF".

Exemple: y = 100 * 0x06FB

Voici une nouvelle commande pour régler le problème du passage au prochaine millénaire. FoxPro, depuis sa version 1.0 a toujours stocké les dates sur 8 caractères. Pas de souci à se faire sur l'intégrité de nos données! Cependant, nous avons pour la plupart utilisé SET CENTURY OFF dans notre code, de façon à limiter la saisie d'une année à deux digits. Le problème, c'est que ? {01/01/00} retourne 1900. Cette fonctionnalité place VFP loin devant la plupart des autres plates-formes de développement dans le traitement du problème lié au passage du prochain millénaire.

Notez que dans le scénario précédent, ? {31/12/95} retourne 31/12/2095. Donc, si vous avez un mélange de dates récentes et futures, vous choisirez un rollover, comme 47 par exemple (97-50). Si vous savez que vous ne devrez aller que 10 ans dans le futur, mais souhaitez avoir accès à des dates du passé, vous choisirez un ROLLOVER de 07 (97-90).

• Evénement MiddleClick.
• Evénement Mouse wheel: déclenché quand l'utilisateur fait tourner la roue de la nouvelle souris Microsoft ou d'un joystick.
• MousePointer: permet de changer l'icône de la souris quand la souris est positionnée au-dessus d'un objet particulier.

Exemple: ERASE \windows\temp\*.tmp

Exemple: MyFunction()

Par défaut, VFP ne place un fichier dans la corbeille quand il le supprime. RECYCLE a pour effet de placer une copie dans la corbeille.

Placée dans CONFIG.FPW, cette directive cache le bureau de VFP au démarrage. On peut le rendre visible par la suite avec _screen.visible=.T. dans la routine de démarrage de l'application.

Si SCREEN=OFF est utilisé en conjonctions avec des formulaires SDI, toute une application VFP peut tourner sans bureau.

SET CLASSLIB permet maintenant de spécifier l'application ou l'exécutable contenant la classe. En 3.0 on ne pouvait effectuer un SET CLASSLIB que sur un fichier .VCX existant physiquement, ou sur une librairie incluse dans l'application courante.

• -A : ignore le fichier CONFIG.FPW et les configurations définies dans le registre de Windows. Cette option est utile en cas de problèmes de démarrage.
• -D<filename> : force VFP à utiliser une .DLL de runtime différente. (La librairie de runtime .ESL a été remplacée maintenant par VFP500.DLL située dans WINDOWS\SYSTEM).
• -L<filename> : force VFP à utiliser un fichier ressource spécifique.
• -R : reconstruit la configuration de base de VFP dans le registre Windows.

? SET("PRINTER", 2) retourne le nom de l'imprimante Windows par défaut.

Ces trois nouvelles variations sur la commande COMPILE permettent de recompiler le code d'une librairie de classes, d'étiquettes et de rapports. Elles sont utiles lors du portage d'applications de 3.0 vers 5.0 si la conversion automatique échoue. Rappelons que COMPILE supporte les jokers.

Exemple: COMPILE REPORT *.FRX

• Nettoyez la fenêtre de commande (clic droit/Clear);
• Ouvrez le menu Tools/Options.
• Maintenez enfoncée la touche Shift et cliquez sur le bouton OK du dialogue des options.
• Toutes vos commandes SET apparaissent dans la fenêtre de commande.

• L'ouverture d'un projet 3.0 le convertit automatiquement.
• Tous les DBC's, VCX's et SCX's 3.0 contenus dans le projet sont recompilés automatiquement. Les anciennes versions (DBC's, VCX'S, SCX's, PJX's) sont conservées dans un répertoire OLD.
• Les étiquettes et les rapports 3.0 sont convertis, mais ne sont pas recompilés, ce qui ne présente pas de problème tant qu'il n'y a pas de code dans les méthodes du DataEnvironment, comme dans BeforeOpenTables par exemple). S'il se trouve du code dans ces méthodes, les rapports ou étiquettes doivent être recompilés avec un COMPILE REPORT/COMPILE LABEL explicite. Le fait de faire un build du projet, avec l'option "Recompile all files" ne compile pas le code des étiquettes et des rapports. Si un rapport ou une étiquette n'est pas recompilé, l'erreur suivante apparaît: Error loading file - record number <n> Alias="tablename" Database=<databasename>.dbc CursorSource="tablename" Name="Cursor1" <or one of its members> Methods - Object file <path\filename>.frx was compiled in a previous version of FoxPro
• Si un VCX, DBC ou SCX se trouve en dehors d'un projet et est ouvert en 5.0, l'erreur "Object file <path\filename> was compiled in a previous version of FoxPro" apparaîtra si le fichier comporte du code. Il devra être recompilé explicitement sous 5.0 avec COMPILE. Si le DBC ne contient pas de stored procedures ou si le VCX/SCX ne contient pas de code dans ses méthodes, il n'y aura pas d'erreur, aucune compilation ne sera nécessaire.
• Le même phénomène apparaîtra pour des rapports ou des étiquettes ouverts en dehors d'un projet.
• Les menus n'ont pas besoin de conversion. Tant que le fichier .MPR est présent, le fichier .MPX sera créé de manière transparente quand le .MPR sera exécuté. Les PRG's se comportent de la même manière. Un fichier FXP est créé de manière transparent, tant qu'un PRG existe. Si le .MPR ou le .PRG sont absents, l'erreur suivante apparaîtra au lancement "Object file <path\filename> was compiled in a previous version of FoxPro"