Des infos de debug dans le panneau de Trace

J'ai activé le panneau de trace de WinDev pour essayer, et c'est vrai que je me dis que je suis vraiment un âne de ne pas l'avoir utiliser avant. Alors voici les intérêts qui m'ont convaincus :

- Le contenu de la trace est visible à la fin du go

- On peut double cliquer sur une trace et ça se positionne à l'endroit de l'appel dans le code (manque plus que la pile ;-))

- On voit les erreurs non fatales non gérés (échec de l'ouverture d'un fichier par exemple).

Si vous n'avez jamais essayé, à mon humble avis, ce serait pas mal de le faire...

Temps d'exécution d'une requête

Alors que j'étais en phase d'optimisation, je suis tombé sur un problème que j'avais déjà rencontré : connaitre le temps total d'exécution d'une requête.

Sur une base client/serveur, c'est relativement facile (en tout cas on a les logs), mais sur une base locale "à l'ancienne" ça devient plus compliqué.

Sur une requête de comptage, tout se passe en effet simplement, un coup de profile ou deux appels aux fonctions chrono et l'affaire est dans le sac. Mais sur une requête classique de sélection, souvent c'est le premier appel "de lecture" qui prend du temps et non le temps d'exécution de la requête. Je suppose que ça doit être lié au positionnement dans les fichiers ou la montée en cache, mais j'aimerai en être sur : est-ce qu'en prenant le temps d'exécution de la requête et la première lecture par Hlitpremier on a le temps total d'exécution de la requête ?

Si vous avez une expérience sur le sujet je suis preneur !

Tâches plannifiées et windows 2008 Server

Alors que la journée se passait on ne peux mieux, il ne me restait plus qu'à mettre mon application en tâche planifiée, un administrateur réseau me demande si ça pose problème de déployer sur un windows 2008 server.

Un peu geek et intrépide, du tac-o-tac, je répond que ça ne me pose aucun problème à moi et mon application Windev.

Tout se passe bien, jusqu'au moment où tout doit fonctionner... M'étant déjà fait avoir par vista et l'UAC, je fais des tests dans le répertoire d'installation, et tout fonctionne.

Je valide donc la tâche planifiées et attend le résultat de l'exécution (compilation de stats diverses)... quand je constate que ma base n'est pas du tout mis à jour.... je relance la tâche planifiée en "manuel", pas de mise à jour... je relance mon exe à la main... et tout fonctionne ! au secours...

Et bien, c'est là que j'ai béni le débugage à distance : une messagebox dans mon exe pour avoir le temps de me connecter et quelques minutes plus tard la raison est sous mes yeux. Le répertoire courant de l'application lorsqu'une application est en tâche plannifié est... le répertoire de Windows où j'ai pu retrouver mes fichiers dans un sous-répertoire.

Moralité : vive fRepExe, à bas fRepEnCours !

Fenêtre interne ou modèle de champs ?

En reprenant un projet pour le remettre à plat, voila que je tombe sur un dilemne que j'ai déjà rencontré : faut-il mieux utiliser une fenêtre interne ou un modèle de champs (les super-champs ne permettant pas simplement de partager ce type de ressource) ?

D'un côté, la fenêtre interne que que je vois comme une sorte d'activeX, qui permet de découper ou partager des champs et des traitements comme une boite noire.

De l'autre, les modèles de champs, qui s'intègre à la fenêtre hôte et s'y adapte plus facilement grâce au mécanisme de surcharge.

de plus, les fenêtres internes peuvent être changées par programmation... mais ça reste un cas plus particulier et moins intéressant que la surcharge à mon goût, je donne donc l'avantage au modèle de champs... et sinon j'espère qu'il est possible de passer facilement de l'un à l'autre ;-)

Bonne année 2009

Bonne année 2009.

Certains l'annoncent difficile, moi je suis un optimiste de nature !

PS : j'ai pris le temps de supprimer les commentaires de type "gna gna gna" d'auteurs anonymes. Si vous n'êtes pas d'accord avec un post, vous pouvez mettre un commentaire pour le signaler (tant qu'il est poli), mais mettez au moins votre identité !

WinDev 14 - nouvel environnement et première utilisation

Comme tout bon geek, à peine mon windev 14 installé, j'ai voulu voir les nouvelles options de l'environnement avant d'aller voir la programmation en elle même.

 

Je pense que je ne suis pas le seul, au premier lancement j'ai demandé à récupérer tout mon environnement habituel... et puis je me suis dit que j'avais peut être des vieilles habitudes et qu'il fallait voir si je pouvais me mettre un peu au goût du jour... j'ai donc choisit de changer mon environnement pour l'environnement simplifié.

Premier constat : wouahhh, on gagne de la place. De nombreuses fonctionnalités sont carrément invisibles (plus de menu ni d'option), et les treeviews sont remplacés par une nouvelle palette "explorateur" qui regroupe tous les types d'éléments d'un projet.

Par contre, c'est un peu déroutant : on veut utiliser une option (sur l'uml) : et là plus d'option... on cherche dans les menus : rien... et oui, il m'a fallut 5 minutes pour me rendre compte que cette fonctionnalité était simplement désactivé de l'environnement : il faut l'activer pour récupérer les options de menus, la palette etc... j'avoue que je me suis fait peur, mais ça devrai me permettre de ne pas perdre de place pour des fonctionnalités que je n'utilise jamais et donc exploiter au mieux ma résolution écran... 

WinDev 14 disponible en téléchargement

Fichtre et fouchtre, on ne peut plus s'absenter une semaine...

la pré-version des versions 14 de windev, webdev et mobile est disponible en téléchargement.

Pour ceux qui avaient comme moi ont déjà reçu leur mail de mise à jour de dongle, il ne reste plus qu'à attendre la fin du téléchargement.

Edit : 5% ... je dois pas être le seul à télécharger ;-)