Blogs officiels sur tous les services et produits de PC SOFT
Publié par
13:41 Jeudi
24 Juil. 2014

[Billet publié dans le blog Le blog du ST]

Comme le précise l'aide de la présentation du GDS : 

Les sources de vos applications sont primordiales.
Ces sources doivent être traitées avec l'attention qu'elles méritent !

Comme les données des applications déployées, les codes sources des projets développés sont on ne peut plus précieux ! Cela semble évident, mais pourtant au quotidien il n'est pas rare pour notre support de découvrir des bases GDS simplement en partage sur un OS inadapté et/ou une machine sous dimensionnée sans protection de son alimentation...

J'ai complété dans l'aide les conseils qui s'appliquent au serveur qui héberge les sources, voici un rappel (non exhaustif) : 
  • Utilisez un serveur dédié avec un disque de taille confortable (au moins 200 Go). 
  • Utilisez le Gestionnaire de Sources (GDS) en mode Client/Serveur, en utilisant une version du moteur au moins égale à celle de l'environnement.
  • Les outils de l'administrateur du GDS permettent de convertir une base GDS au format HFSQL Classic en base HFSQL Client/Serveur. 
  • Les disques durs peuvent avoir des problèmes physiques : utilisez si possible un système RAID I sur votre serveur (plusieurs disques stockant les mêmes informations en double). 
  • Protégez l'alimentation de votre serveur par un onduleur. 
  • Faites des sauvegardes régulières de la base de sources. 
  • Placez le serveur dans une zone "sécurisée", en utilisant un firewall. 
  • Lorsque la base est dans un CLOUD : 
    - vérifiez avec son administrateur que les connexions TCP sont permanentes (c'est le cas pour les plateformes de développement de PCSCLOUD). Même si le GDS se reconnecte automatiquement, pour votre confort, il ne doit pas y avoir une coupure automatique des connexions TCP toutes les minutes par exemple. 
    - en cas de déconnexions fréquentes (alors que les connexions TCP sont permanentes), réduisez la taille des paquets dans les outils de l'administrateur du GDS.
  • Vérifiez que la copie locale des sources ne peut pas être manipulée par des processus externes (antivirus, sauvegarde automatique...) pendant le développement. 
  • Préférez l'utilisation du mode "Gérer automatiquement l'extraction du projet" lorsque les modifications de plusieurs développeurs portent sur le projet (code projet, liste des éléments...).

Bien sûr toutes les recommandations de sécurité données pour le moteur HFSQL Client/Serveur s'appliquent intégralement, et constituent un bon point de départ ...


Publié par
10:00 Jeudi
03 Juil. 2014

[Billet publié dans le blog Le blog du ST]

L'impression physique d'un état et son aperçu sont des processus dépendants : 
  • des API de Windows qui peuvent donc présenter des variantes d'une version à l'autre,
  • du pilote de l'imprimante et de son adéquation avec l'imprimante utilisée, 
  • du mode de compilation 32 ou 64 bits,
  • des processus lancés en parallèle sur la station qui imprime...
Combiné au fait que chaque état a ses propres particularités en fonction de la disposition et du type de ses champs, et de ses blocs, chaque impression devient pratiquement un cas d'utilisation unique.

Dans la majeure partie des cas, cela n'a aucune incidence et une même édition donne toujours le même résultat. Mais, en fonction d'un état et/ou d'un pilote et/ou d'une version de Windows, un comportement inattendu peut survenir, c'est "l'exception qui va confirmer la règle" :
  • un rendu inattendu : espacement trop important de caractères, ou à l'inverse superposition, 
  • message "l'état est trop large..."
  • une instabilité : processus figé "pas de réponse", processus arrêté sans message, RAM occupée par le processus ou dans le spool de Windows plus importante que sur d'autres stations ... 
Le processus d'impression repose sur les api de Windows, qui vont s'appuyer sur le pilote de l'imprimante, la conduite à tenir en cas de difficulté consiste donc à suspecter en tout premier lieu le pilote de l'imprimante ! En effet, généralement une simple mise à jour du pilote à partir du site de son fabricant, ou parfois à l'inverse l'utilisation d'un pilote générique, supprime le défaut.

Lorsque ça n'est pas le cas, voici les actions pouvant être tentées au niveau de l'état en question. Sachant que la plupart des difficultés sont liées à la consommation mémoire, surtout si la compilation est en 32 bits car dans ce cas le système limite les possibilités d'allocation, elles visent principalement à réduire la consommation :

  • recompiler l'application avec la version 19 s'il s'agit d'une version antérieure, l'occupation mémoire étant moindre (nouveauté 75).
  • appeler la fonction iRAZ avant le lancement de l'édition.
  • augmenter sensiblement les marges de l'état si elles sont très proches des marges physiques de l'imprimante.
  • éviter de stocker tout le document à imprimer dans le spool de Windows. Cocher pour cela dans le volet "Options" de la description de l'état, l'option "Envoyer chaque page séparément à l'imprimante" 

  • supprimer la transparence des images, si elle n'est pas utilisée. En effet à partir de la version 19 (nouveauté 73) la transparence est gérée ce qui peut avec certains pilotes augmenter la taille du travail d'impression dans le spool. Il suffit pour cela d'intervenir sur la description des images, volet "Style", afin de remplacer la transparence demandée dans la couleur de fond : 

  • si la non conformité concerne la mise en forme de données en RTF, inverser l'utilisation faite de l'option iRTFAvecImagesEtTableaux de la fonction iParamètre (l'avoir en paramètre des réglages des applications peut être un plus). 
  • si des caractères se superposent, effectuer une recherche sur le site de Microsoft avec le nom de la polices de caractères. Des effets sont parfois spécifiques à certaines polices, et nécessitent la mise en place de contournement spécifiques. L'appel suivant avant l'état peut apporter une solution : iParamètre("PLACEMENTCARACTERE=VRAI")
  • dans le cas d'une imprimante relativement lente, ralentir l'envoi de l'impression par une temporisation de quelques secondes, après impression du bas de page, toutes les 10 pages par exemple. Idéalement le délai de temporisation sera paramétrable via les options de configurations de l'application. Cela permet une adaptation en situation en fonction des périphériques rencontrés, dans tous les cas où le matériel n'est pas connu à l'avance.
  • la prévention d'exécution des données peut également impacter les processus d'impression.
  • ...

_________________________________

Si aucune solution ne s'applique, et qu'il ne s'agit pas d'une imprimante pour laquelle le fabricant ne propose plus de pilote, n'hésitez pas à soumettre le cas à notre support. Il suffit de formuler une demande par le menu "Aide" du volet "Accueil" de WINDEV. La demande doit nécessairement contenir :
  • détail du cas de figure (copie message, symptôme, configuration système, défaut en aperçu ou en impression physique ou les deux...),
  • constat au niveau de l'occupation mémoire du processus, et de l'impression dans le spool de Windows, 
  • lien permettant d'obtenir le pilote d'imprimante concerné, 
  • lien vers un serveur web ou ftp permettant de télécharger une archive zip contenant : 
  • un projet de test, 
  • une fenêtre commentée lançant le traitement d'édition (libellés explicatifs "cliquez ici, "observez que"...) 
  • l'état en question lancé par la fenêtre, 
  • si l'état ne peut pas être adapté pour imprimer des données statiques, "en dur", ajouter :  
  • l'analyse (dossier \NomAnalyse.wdx\ ou \NomAnalyse.ana\ sans ses sous-dossiers) 
  • un jeu de données *.FIC permettant l'exécution dans le cas d'une base HFSQL , un script SQL (fichier texte avec Create table et Insert) dans le cas d'une autre base. 

Publié par
08:47 Mardi
24 Juin 2014

[Billet publié dans le blog Le blog du ST]

Le sommaire de la LST 97 est en ligne : 



Disponibilité :
  • France métropolitaine : 7 Juillet 2014
  • DOM-TOM et hors France : prévoir une semaine supplémentaire

Publié par
11:10 Jeudi
19 Juin 2014

[Billet publié dans le blog Le blog du ST]

Une nouvelle version de WINDEV, WEBDEV et WINDEV Mobile 19 est disponible en téléchargement. Il s'agit de la version 190056N, disponible à partir de l'espace téléchargement de notre site : 

Cette version a passé tous les niveaux de validation :
Publié par
12:07 Vendredi
06 Juin 2014

[Billet publié dans le blog Le blog du ST]

Une nouvelle version de WINDEV, WEBDEV et WINDEV Mobile 19 est disponible en téléchargement. Il s'agit de la version 190056j, disponible à partir de l'espace téléchargement de notre site :


Cette version est en niveau 1 de validation :



Publié par
09:42 Mercredi
21 Mai 2014

[Billet publié dans le blog Le blog du ST]

L'éditeur de code propose une complétion automatique simplifiant l'appel de toutes les fonctions du Wlangage, ainsi que l'appel des procédures et fonctions ajoutées au projet.
Par exemple lors de l'appel d'une fonctions Wlangage qui attend en paramètre le nom d'une fenêtre du projet, la complétion automatique propose automatiquement la liste de toutes les fenêtres :


A partir de la version 19, il est possible d'avoir une complétion identique pour les procédures et fonctions ajoutées au projet (nouveauté 100). Illustration avec une fonction "ContrôleSaisie" ajoutée dans une collection de procédures du projet :


Afin d'obtenir ce résultat, il suffit d'ajouter à la déclaration de la procédure l'attribut d'extension "<nom de fenêtre>". Exemple : 

Procedure ContrôleSaisie(sNomFenêtre est une chaîne <nom de fenêtre>)

soit i = 1
soit ResChamp = EnumèreChamp(sNomFenêtre, i)
TANTQUE ResChamp <> ""
 i++
 Trace("Traitement du champ "+ResChamp+" de la fenêtre "+sNomFenêtre)
 ResChamp = EnumèreChamp(sNomFenêtre, i)
FIN

Il est également possible sur le même principe de forcer la complétion sur un <nom de page>, <nom d'état>.

Publié par
10:14 Jeudi
15 Mai 2014

[Billet publié dans le blog Le blog du ST]

Un exécutable 32 ou 64 bits exécuté sous Windows doit effectuer dans un tout premier temps le chargement de modules du framework de WINDEV. En effet le framework intègre toutes les fonctionnalités utilisées par l'application.

Il peut être utile en phase de mise au point de vérifier la localisation du framework, ou de comprendre pourquoi son téléchargement est lancé. Ce thème a été détaillé sur les forums développeurs en 2006, mais reste d'actualité le "principe" de lancement d'un exécutable sous Windows restant toujours le même. Voici donc une reprise du forum sur ce sujet :

[...]
L'exécutable lors de sa création intègre en fonction de vos choix dans l'assistant les informations suivantes :
  • la version interne de WINDEV utilisée pour sa création, 
  • si le Framework est inclus dans l'exécutable ou non (défaut), 
  • si le Framework garde son nom d'origine (défaut), ou s'il est renommé. 
  • si le Framework utilisé est commun ou non (défaut) 
Ces informations sont directement utilisées par le processus de lancement qui se déroule de la façon suivante :
L'exécutable commence par vérifier s'il intègre le Framework, deux possibilités :
  1. l'exécutable inclus le Framework, il l'extrait sur le disque (même répertoire que l'exécutable) avec son nom d'origine, ou en le renommant si cela a été précisé lors de sa création. Le lancement du Framework est alors demandé par l'exécutable à Windows (1). Si le lancement est réussi, l'application démarre. Si le chargement du Framework échoue, il y a téléchargement du Framework (2). 
  2. l'exécutable n'inclus pas le Framework, il tente un chargement du Framework directement dans son répertoire. S'il est présent, l'application démarre. En cas d'échec, on distingue à nouveau deux cas possibles : 

    2-1. L'exécutable peut utiliser un Framework commun : dans ce cas il est chargé dans le dossier \Program Files\Fichiers communs\PC SOFT\10.0\. Si ce chargement est réussi, l'application démarre. En cas d'échec, il y a téléchargement d'un Framework (3). 

    2-2. L'exécutable ne peut pas utiliser un Framework commun : il télécharge (4) un Framework qui sera ensuite utilisé pour lancer l'application. 

J'ai synthétisé au maximum le processus, vous pourrez ainsi maîtriser tous les cas pouvant aboutir au téléchargement d'un Framework avant le lancement effectif de l'application. N'hésitez pas à nous interroger sur ce sujet, via le "? ... Requête au Support Technique Gratuit". Mais précisez bien les options que vous retenez pour la création de l'exécutable, vous l'avez compris elles sont capitales !


(1) : le lancement est fait par "LoadLibrary", le Framework est donc recherché dans le répertoire de l'exécutable, de Windows, et les chemins contenus dans la variables d'environnement PATH.
(2) : la version du Framework téléchargé est exactement celle mémorisée dans l'exécutable. Son installation sera faite dans le même répertoire que l'exécutable, avec son nom d'origine ou en le renommant si cela a été demandé à la création de l'exécutable.
(3) : ce Framework est placé dans le répertoire commun : \Program Files\Fichiers communs\PC SOFT\10.0\ Il sera dans la version interne de WINDEV la plus récente.
(4) : ce Framework est placé dans le répertoire de l'exécutable, il s'agit du Framework de version interne identique à celle de WINDEV sur le poste qui a créé l'exécutable.
[...]

A noter que le "Moniteur des ressources" depuis Windows 7 permet de voir immédiatement où sont les modules chargés par un exécutable donné :
  • lancer le "Moniteur des ressources" via le menu "Démarrer", ou le volet "Performances" du gestionnaire de tâches,
  • sélectionner le volet "Processeur",
  • sélectionner l'exécutable dans les processus listés,
  • dérouler la zone "Modules associés" : elle contient toutes les DLL chargées par l'exécutable.
Illustration pour un exécutable nommé EXE32.EXE : 


Pour aller plus loin il est possible d'utiliser l'utilitaire ProcMon. Ce dernier permet de suivre toutes les entrées/sorties d'un processus donné, et donc de voir tous les accès aux modules utilisés. Il a été décrit dans un précédent billet.
Publié par
18:39 Jeudi
24 Avr. 2014

[Billet publié dans le blog Le blog du ST]

Voici une astuce bien pratique dans les états, qui permet de réduire le nombre de champs lorsque l'on doit effectuer une mise en forme d'un texte incluant des informations provenant de la programmation. 

L'astuce consiste à utiliser les balises [% et %] non pas avec des rubriques ou variables comme on le fait couramment, mais directement avec des fonctions Wlangage. En effet, lors de l'exécution de l'état qu'il s'agisse de l'aperçu, l'impression, ou l'exportation (PDF,RTF,XLS...), la ou les fonctions Wlangages seront automatiquement compilées afin d'insérer leur résultat.

Par exemple avec un unique champ libellé, on peut ainsi demander à avoir la date avec une mise en forme donnée, ainsi que le poste en cours. Le tout sans avoir à programmer une concaténation de ces informations :


Attention, cette possibilité repose sur la compilation dynamique. Son utilisation nécessite donc que l'exécutable puisse utiliser le module de compilation, WD190CPL.DLL. Ce dernier ne doit donc pas être dans les modules inutilisés de l'étape de configuration du framework, dans l'assistant de création de l'exécutable. L'idéal est de demander son chargement à la "première utilisation", afin qu'il ne soit chargé que si l'instance de l'application utilise effectivement l'état concerné :



Publié par
09:42 Mercredi
16 Avr. 2014

[Billet publié dans le blog Le blog du ST]

Une faille de sécurité de la librairie OpenSSL, Heartbleed, a été trouvée le 7 avril 2014. Bien que totalement indépendante de PC SOFT et des produits PC SOFT, un point a été fait par nos équipes afin de situer très précisément l'impacte de cette faille : faille de sécurite heartbleed
Publié par
11:01 Vendredi
28 Mar. 2014

[Billet publié dans le blog Le blog du ST]

Une nouvelle option fait son apparition à partir de la version 190044 de WINDEV Mobile, dans l'assistant de création des applications Android : "réduire la taille du code généré". 


Cette option doit être utilisée dans le cas précis : 
  • de la compilation d'une application destinée à des périphériques avec Android 2.x ou 3.x, 
  • et si un message "INSTALL_FAILED_DEXOPT" apparaît à l'installation de l'application. 

Pour information, le retour "INSTALL_FAILED_DEXOPT" apparaît lorsqu'une limite imposée par Android est atteinte. Lors de l'installation d'une application APK, Android convertit automatiquement l'application Java en fichier DEX. Suivant la version de Android installée sur le matériel, la taille de la mémoire allouée à cette opération n'est pas identique :
  • 5 Mo au maximum pour la génération du fichier DEX avec Android 2.1,
  • 8 Mo au maximum pour la génération du fichier DEX avec Android 2.3,
  • 16 Mo au maximum pour la génération du fichier DEX avec Android 4.1, 
Cette nouvelle option "réduire la taille du code généré" peut donc permettre d'exécuter une application de taille importante adaptée aux versions actuelles de Android, sur des périphériques plus anciens. Elle nécessite de compiler avec une version 4 du SDK Android au minimum.

A noter que l'opération d'optimisation est une opération coûteuse en temps de création de l'application. Jusqu'à une minute sur les projets les plus importants. Par contre elle n'a pas d'incidence négative sur les performances à l'exécution, au contraire l'optimisation du code peut les améliorer. Il est donc conseillé de ne pas l'activer en phase de test, et de la cocher uniquement lorsque l'application doit être générée en vue de sa publication.