PC SOFT

BLOGS OFFICIELS 
SUR TOUS LES SERVICES ET PRODUITS DE PC SOFT

Publié par
16:04 Jeudi
23 Juin 2016

Le champ carte d'une application WINDEV ou d'un site WEBDEV peut afficher le message "Oops! Something went wrong", à la place de la carte attendue :




C'est un changement datant du 22 juin 2016 dans les conditions d'utilisation des API Google Maps qui est à l'origine de cet affichage. Afin de rétablir l'affichage de la carte, Google impose maintenant de spécifier une "clé d'API" pour toutes les interrogations. 


Aucune mise à jour de WINDEV ou WEBDEV n'est requise, il suffit d'utiliser les possibilités existantes afin de spécifier une clé d'API Google :

  • dans le cas d'une application WINDEV, appeler la fonction CarteLicenceGGL avant l'ouverture de la fenêtre contenant le champ carte : FAQ 13 035
  • dans le cas d'un site WEBDEV, appeler la fonction CarteLicenceGGL dans la page, ou spécifier la clé dans le volet "Avancé" de la description du projet : FAQ 13 033

Une clé d'API pour l'utilisation des API Google Maps peut être obtenue directement dans la console développeur de Google. Voici un mode opératoire valable sur le site actuel de Google (s'il est actualisé les libellés ou menu pourront changer, mais le principe restera le même) : 


  • accéder à la console développeur de Google
  • se connecter si besoin avec un compte Google,
  • créer un projet si nécessaire, 
  • accéder au "Gestionnaire d'API" par le bouton "hamburger - Produits et Services" en haut à gauche,  
  • dans la rubrique "Présentation",
  • suivre le lien "Google Maps JavaScript API" dans la zone "API Google Maps",
  • cliquer "Activer" si besoin afin d'activer l'API Google Maps Javascript API, 
  • dans la rubrique "Identifiants",
  • dérouler le bouton "Créer des identifiants",
  • sélectionner "Clé d'API",
    • dans le cas d'un site WEBDEV sélectionner "Clé navigateur". Il est recommandé de préciser le domaine qui utilisera la clé pour le suivi des requêtes et éviter toute usurpation.
    • dans le cas d'une application WINDEV, sélectionner "Clé serveur". Il est recommandé de préciser l'adresse qui utilisera la clé pour le suivi des requêtes et éviter toute usurpation.
  • valider par le bouton "Créer" ou "Créer la clé d'API",
  • copier la clé à spécifier dans les applications et/ou sites.

Il faut souligner que les conditions et quotas ont évolué, il faut donc les vérifier en fonctions des sites et applications qui utilisent les services.


Les applications WINDEV Mobile pour iOS ou Android ne sont pas impactées par ces changements au niveau de l'affichage de la carte, car une licence était déjà indispensable pour la génération de l'application.

Publié par
17:58 Vendredi
17 Juin 2016

A partir de la version "Update 3" de WEBDEV 21, l'éditeur de pages lorsque l'édition est faite en mode Responsive Web Design, permet de visualiser les blocs de positionnement des champs.

Pour afficher les blocs de positionnement, sous le volet "Affichage", dans le groupe "Aide à l'édition", cliquez sur "Bloc de positionnement". 

Il est très important de toujours conserver l'option active, afin de visualiser les blocs de positionnement, et les positions des champs les uns par rapport aux autres. Rappelons en effet que le principe d'une page Responsive Web Design, et d'avoir ses champs qui vont se positionner les uns par rapport aux autres en fonction de la taille du navigateur, des règles définies via les ancrages et la grille de positionnement.

Dans la page illustrée ci-dessous, grâce à l'activation de la visualisation des blocs de positionnement, on voit pour le champ sélectionné :


  1. le rectangle pointillé dans lequel l'éditeur regroupe les champs (le bloc de positionnement), 
  2. à droite de quel élément sera placé le champ : ici l'image sera toujours et dans tous les tranches alignée sur le bord gauche de la page, 
  3. en dessous de quel élément sera placé le champ : ici l'image sera toujours placée sous le libellé "Connexion" de la page. Attention, "au dessous" ici doit être pris au sens de la verticalité dans la page, pas de la superposition.

Ces informations sont très importantes, car la position des champs les uns par rapport aux autres est figée dans toutes les tranches : dans la tranche bureau, la tranche de référence, l'image est placée dans la page en appliquant ses ancrages et en fonction du libellé "Connexion". Dans toutes les tranches, l'image sera placée en fonction de la position du libellé "Connexion". On sait donc grâce à la visualisation des blocs de positionnement :

  • de quoi dépend la position d'un champ, 
  • où un champ ne pourra pas être placé dans la tranche tablette, ou la tranche mobile.

Les erreurs d'IHM mentionnent les éventuelles erreurs de positionnement.



Astuce 
: l'ordre des champs les uns par rapport aux autres est figé dans toutes les tranches. Par contre, la visibilité des champs ainsi que leurs positions peuvent être surchargés. Dans un exemple comme ci-dessus, si l'on souhaite avoir dans une tranche un champ qui ne conserve pas sa position de référence définie par la tranche bureau, on peut utiliser deux champs et jouer sur leurs visibilités. Exemple pour avoir dans la tranche mobile une image placée avant le libellé "Connexion", alors qu'elle est après dans la tranche bureau :

  • l'image placée sous le libellé "Connexion" est rendue invisible dans la tranche mobile :


  • dans la tranche mobile, l'image créée spécifiquement pour cette tranche est rendue visible, l'inverse de l'image utilisée dans la tranche bureau.






Publié par
08:12 Lundi
13 Juin 2016

Un nouveau Webinaire est programmé jeudi 16 juin à 11h. 


Dans cette session de 20 minutes, vous découvrirez comment utiliser des ressources externes (JQueryUI, Javascript widgets, ...) dans une page WEBDEV, et les manipuler en WLangage.

Après la diffusion en direct, la vidéo restera disponible avec ce même lien.


Retrouvez l'ensemble des webinaires sur notre site :

http://www.pcsoft.fr/webinaires.htm


Publié par
18:30 Mercredi
08 Juin 2016

La version version "Update 3" de WINDEV, WEBDEV et WINDEV Mobile 21 est disponible en téléchargement en niveau 2 de validation par le service Qualité. Il s'agit de la version 210065n.





Accéder à l'espace téléchargement ...


Bons développements ! 

Publié par
18:52 Mardi
31 Mai 2016

Une nouvelle version 210065j de WINDEV, WEBDEV et WINDEV Mobile 21 est disponible en téléchargement :

http://www.pcsoft.fr/st/telec/index.html


Cette version n'a pas encore subi le deuxième niveau de validation par le Service Qualité. Vous pouvez trouver une information complète sur les niveaux de validation sur notre site : 

http://www.pcsoft.fr/st/telec/validation-vi.htm


Publié par
17:22 Lundi
23 Mai 2016

Un nouveau Webinaire est programmé jeudi 26 mai à 11h. 


Dans cette session de 20 minutes, vous découvrirez comment utiliser les classes abstraites du WLangage pour réaliser des interfaces et définir des conventions de programmation.


Après la diffusion en directe, la vidéo restera disponible avec ce même lien. 


Retrouvez l'ensemble des webinaires sur notre site :

http://www.pcsoft.fr/webinaires.htm


Publié par
13:23 Mardi
17 Mai 2016

L'aide de la fonction WiFiInfoConnexion vient d'être modifiée, suite à un changement apporté par Google à Android 6. 


WiFiInfoConnexion permet de connaître l'adresse MAC par laquelle transite la connexion WI-FI, grâce au paramètre wifiAdresseMac. Cela reste vrai lorsque l'exécution se fait sous Android 4.x ou Android 5.x. Par contre à partir de la version 6 de Android, l'adresse MAC n'est plus accessible  :



https://developer.android.com/about/versions/marshmallow/android-6.0-changes.html#behavior-hardware-id


Si une application Android utilisait WifiInfoConnexion afin d'identifier le périphérique qui exécutait l'application, il est conseillé d'utiliser à la place la fonction SysIdentifiant.

Publié par
08:11 Mardi
10 Mai 2016

Un nouveau Webinaire est programmé jeudi 12 mai à 11h. 


Dans cette session de 20 minutes, vous découvrirez comment appeler un webservice REST pour récupérer les taux de change publiés par la BCE (Banque Centrale Européenne). Les taux de change sont actualisés tous les jours.?


Après la diffusion en directe, la vidéo restera disponible avec ce même lien.

Retrouvez l'ensemble des webinaires sur notre site :
http://www.pcsoft.fr/webinaires.htm 


Publié par
12:55 Lundi
09 Mai 2016

L'éditeur de pages de WEBDEV propose à partir de la version 21 un mode d'édition "Responsive Web Design". Ce mode d'édition est une des solutions permettant d'avoir un site "mobile friendly", l'alternative étant le "dynamic serving". Dans ce mode, plutôt que de donner une position précise et fixe aux champs comme on peut avoir l'habitude de le faire dans des sites web existants, les champs sont répartis sur une "grille" et des "tranches". Cela n'ajoute pas de difficulté particulière, mais impose de bien réaliser les pages en gardant à l'esprit les mécanismes qui positionneront les champs à l'exécution. 


Après "Les 5 recommandations fondamentales à respecter pour la création et la mise à jour des pages des sites WEBDEV" pour l'édition "zoning", voici les recommandations pour l'édition "Responsive Web Design"...


Incontournable avant tout, les pages dédiées de l'aide en ligne, déjà données dans le billet "Mise à jour de l'aide en ligne pour WEBDEV : Responsive Web Design...".


Ensuite toujours garder à l'esprit les fondamentaux suivants :


1. Limiter la mise en page aux dimensions réellement utilisables. Cela va sans dire, mais ça va mieux en l'écrivant ! En effet comme une page Responsive Web Design s'adapte à la largeur du navigateur, au premier abord on se laisse tenter à vraiment vouloir un résultat "responsive" dans toutes les largeurs, mais vraiment toutes y compris celles qui rendront le site inexploitable car trop petit, ou trop grand !


Donc avant tout pour éviter de gérer les cas extrêmes, très petits et très grands il est conseillé dans la page de :

  • fixer une largeur minimale, dans l'onglet IHM, partie "largeur min". A ce jour 320px est adapté pour que la visualisation soit parfaite même sur les mobiles les plus petits. 
  • indiquer une largeur au delà de laquelle la page sera centrée, et non plus étirée. Par exemple 980px pour la navigation depuis un poste de bureau : l'onglet IHM, partie ancrage, définir un ancrage en largeur adapté à la grille sans agrandissement. 


2. La tranche bureau est la tranche de référence : dans cette tranche tous les champs doivent être bien positionnés...


Pour l'édition en mode mode Responsive Web Design, il est capital de bien dimensionner et positionner les champs dans la tranche bureau, car elle sert de tranche de référence. Tous les calculs pour la taille et la position partent de cette tranche de référence.


En particulier, dans cette tranche bureau les champs qui seront visibles dans la tranche mobile et/ou tablette mais invisibles en dans la tranche bureau, doivent tout de même être bien positionnés sans superposition invalide. L'ordre des champs (de gauche à droite puis de haut en bas) est très important, les champs doivent être dans le même ordre dans toutes les tranches (cf. FAQ 12 790)


Rappel, un clic sur la tranche bureau permet de positionner la page dans sa largeur de référence. Pour modifier si besoin cette largeur il faut d'abord se mettre dans la tranche bureau, puis modifier la largeur de la page via la poignée bleue à droite et au centre de la page.


3. En mode Responsive Web Design tout bouge, et/ou change de taille en fonction de la taille du navigateur, et des autres champs présents dans la page. Ensuite il y a plusieurs "tranches" et dans chaque "tranches" les champs peuvent avoir une taille, une position et une visibilité différente grâce aux surcharges. A retenir :



  • La position d'un champ est directement liée à la position du champ juste à côté, et cela dans toutes les tranches. Donc nécessairement, indépendamment des surcharges et des tranches, deux champs qui sont à côté auront leurs déplacements liés. Il n'est jamais possible d'insérer un champ entre deux lors d'un changement de tranche. 
  • Les champs avec une taille adaptée à la grille se positionnent toujours sur le même nombre de colonnes de la grille, quelque soit la tranche. Si par exemple en édition un champ occupe 6 colonnes de la grille dans la tranche bureau, il occupera également 6 colonnes dans la tranche tablette, et 6 colonnes dans la tranche mobile. Lorsque la largeur du navigateur change, c'est la largeur des colonnes de la grille qui est adaptée, provoquant ainsi l'ajustement des champs puisqu'ils restent toujours sur un même nombre de colonnes. 
  • les champs qui ont une taille fixe occupent un nombre de colonnes variables, l'inverse des champs ancrés en largeur sur la grille, puisqu'ils ne changent pas de taille lorsque la largeur de la page change. 


Pourquoi est-ce si important ? Parce que tous les champs ont leurs positions liées, et que l'on se retrouve rapidement dans une situation ou "un champ passe à la ligne tout seul" sans que l'on ne sache au départ pourquoi...

En effet, lorsque l'on édite sa première page en mode Responsive Web Design, on est généralement très vite confronté à ce résultat : un champ passe sous un autre au lieu de rester à sa droite comme l'on s'y attend. Exemple :


  • un champ de saisie pour une recherche a son ancrage en largeur adapté à la grille, sa taille est donc variable en fonction de la largeur du navigateur, 
  • à sa droite un bouton permet de lancer une recherche, il a une taille fixe, 
  • le champ de recherche qui est adapté à la grille occupe 40 colonnes sur les 48 de la page, 
  • le bouton de recherche à la droite du champ occupe lui 4 colonnes en édition, sa largeur est fixe. 



Lorsque la taille du navigateur va être plus petite que la taille d'édition (réduction de sa largeur pour passer successivement de la tranche bureau à la tranche tablette puis mobile), comme la largeur des colonnes de la grille se réduit proportionnellement à la largeur de la page dans le navigateur, le bouton de taille fixe va occuper 5 colonnes de la grille au lieu des 4 en édition, puis 6 colonnes, puis 7 (...) provoquant ainsi une réduction de l'espace entre le champ de saisie, et le bouton. Puis le bouton de taille fixe va prendre 9 colonnes, et là il ne rentre plus. L'espace devient insuffisant le bouton est "poussé" par le champ de recherche à la ligne du dessous.




Pour éviter ce cas extrême provoquant un passage à la ligne à l'exécution, il est donc important de bien positionner tous les champs dans la tranche bureau (tranche de référence) puis d'ajuster position et visibilité des champs au fur et à mesure que l'on change de tranche et/ou que l'on réduit la largeur du navigateur. Dans le volet "Affichage" du ruban, toujours cocher "Erreurs de superposition". De cette manière si un champ peut être "poussé" faute d'espace en exécution dans les navigateurs, un débordement sur un autre champ sera visible dans l'éditeur, avec une superposition invalide :



4. Le champs spécifique pour le placement des champs en mode Responsive Web Design : le champ barre de navigation.


Le champs barre de navigation permet de gérer spécifiquement la position de certaines zones, en dérogeant aux règles de placement des champs évoquées en 2. Typiquement grâce au champ barre de navigation, il est possible d'avoir un champ de saisie type recherche, avec un bouton à sa droite qui ne pourra pas lui passer dessous si l'espace vient à manquer. Le champ barre de navigation n'est pas exclusivement réservé au menu, et sa substitution par un bouton "hamburger".


Le champ barre de navigation est découpé en 3 zones horizontalement :



  • deux zones à gauche et à droite qui sont au choix fixes ou adaptées à la grilles selon l'option du volet IHM du champ, 
  • une zone centrale dont la largeur sera déterminée en fonction de l'espace restant après placement de ses zones de gauche et de droite. 


La particularité de ce champ c'est qu'il est ancré tout entier avec ses deux extrémités qu'elles soient fixes ou non. Le champ barre de navigation entier suit toujours toute la grille, il occupe toujours le même nombre de colonnes. En fonction de ses réglages ses zones de gauche et de droite sont positionnées, puis la zone centrale est placée dans l'espace restant en largeur. Le champ barre de navigation permet donc de faire cohabiter sur une même ligne horizontale, des champs ancrés à la grille, et des champs ayant une largeur fixe.

Dans l'exemple ci-dessus, afin d'éviter qu'un bouton soit "poussé" à la ligne de dessous, on pourra le placer dans la zone de droite d'un champ barre de navigation : 



De cette manière à l'exécution quelque soit la largeur du navigateur, la zone du bouton ne sera pas réduite, le bouton aura toujours la place :



Les trois zones du champ barre de navigation, comme pour tout les champs de type conteneur, il y a à nouveau une grille avec le même nombre de colonnes que la grille de la page, ce qui permet l'ancrage des éléments qui se trouvent dans chaque zone.



5. Erreur d'IHM et/ou superposition (cf. FAQ 12 701, FAQ 12 790) : il faut les surveiller et corriger les erreurs d'IHM et de superposition constamment. Elles indiquent précisément tous les positionnements des champs qui pourraient provoquer un rendu inattendu dans certaines largeurs : 


  • volet "Erreur de compilation" enfoncer le bouton "Afficher les erreurs d'IHM",
  • volet "Affichage" du ruban, cocher :
    • "Erreur de superposition",
    • "Bloc de positionnement".

5. Utiliser un modèle prédéfini : lors de la création d'une nouvelle IHM "responsive web design", il est généralement plus simple de partir d'un modèle existant qui sera personnalisé. Dans l'assistant "Nouvelle page", sélectionner "Modèles prédéfinis" puis "Responsive Web Design". A ce jour les modèles "business" et "blog" sont proposés, ils seront rapidement complétés par d'autres modèles, principalement en fonction des besoins décrits à notre support.



Publié par
11:11 Lundi
09 Mai 2016

A partir du premier juin 2016, les applications pour iOS doivent utiliser exclusivement le protocole IPv6 afin d'être soumises à l'Apple Store :

https://developer.apple.com/news/?id=05042016a&1462389382 


Afin de publier une nouvelle application, ou une mise à jour d'une application WINDEV Mobile pour iOS, il faut donc bien vérifier que toutes les communications utilisent IPv6 :

  • remplacer toute utilisation d'une adresse IPv4 par un nom de serveur dans les communications :  
    • HOuvreConnexion vers un serveur HFSQL client/serveur, 
    • ..Adresse pour consommer un webservice, 
    • adresse donnée à HTTPRequete, 
    • ouverture de sessions emails... 
  • vérifier que les adresses IP stockées en base de données ne sont pas limitées aux 16 caractères des adresses IPv4. 
  • rechercher tout ce qui peut utiliser une IPv4 ...