Discussion :

[Hibernatus34]

"internal_properties", du binaire codé en base64.
Il y en a de partout.
En fait, tout ce qui est descriptif (propriétés de champs, etc.).

La bonne blague...

[philouZ]

Vive l'ouverture du code chez PC Soft...

[Hibernatus34]

Je n'ai pas compris le principe des champs métiers.

J'en ai posé quelques uns sur une fenêtre et ça ressemblait à des modèles de champs sans héritage, sans conteneur, sans fonctions... Enfin ça ressemblait juste à un copier/coller code + champs.
Mais, surtout, je n'ai pas trouvé comment en créer moi-même.

C'est quoi l'idée ?
C'est juste une nouvelle manière de fournir des exemples ? (comme les quelques superchamps "sélecteur de fichier" et cie)

Merci d'avance si vous pouvez m'en dire plus. (mais je crains qu'il n'y ait pas plus à savoir)

[philouZ]

C'est quoi l'idée ?
C'est juste une nouvelle manière de fournir des exemples ? (comme les quelques superchamps "sélecteur de fichier" et cie)

C'est encore une fois remplir le magazine des nouveautés. Quand j'en avais discuté avec PC Soft ils m'avaient dit qu'ils avaient un pool de demandes qui était traité par ordre décroissant (les plus demandées en premier). Je me demande quels développeurs ont pu demander une telle c...nerie.

A mon avis y'a de la perte de vitesse chez PC Soft et un gros manque d'idée.

Je n'ai pas pu aller à la présentation de la 25. Est-ce qu'ils ont parlés des propriétés qu'on peut rajouter aux champs ? Là aussi j'ai un peu de mal à voir à quoi ça va servir étant donné qu'on ne peut pas hériter des objets. Admettons que je rajoute une propriété à une fenêtre, ce qui m'intéresserait ce serait de pouvoir affecter cette propriété avant d'ouvrir la fenêtre. Est-ce que ce sera possible ?

[Hibernatus34]

D'après la brochure, les propriétés de champs auront des "accesseurs" comme pour les propriétés de classes, et comme en interne pour les propriétés de champs existantes.
Là où c'est intéressant, c'est qu'on peut surcharger les propriétés existantes. Donc par exemple, à chaque fois que quelqu'un affecte une donnée à ..Visible j'affiche un toast, et quand on lit ..Visible je réponds Vrai que si je suis visible et aussi dans le plan en cours.
En revanche, il faudra probablement aussi un espace pour les données (l'état), et donc pouvoir définir des variables de champs comme on peut le faire sur des superchamp ?

Combiné avec les modèles de champs, qui ont déjà la surcharge de ..Valeur, ça peut augmenter leur potentiel...

[philouZ]

Moi je le voyais bien sur les fenêtres. Ca évite de passer X paramètres à la fenêtre, mais ces propriétés ne sont accessibles qu'à partir du moment où l'objet existe, ce qui est logique. Donc on ne pourra certainement pas faire quelque chose comme ça

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
MaFenetre est une FEN_FicheClient
Mafenetre..Mode = "Creation"
MaFenetre..ID = -1
...
MaFenetre.Ouvre()

Si on ne peut pas faire ça c'est bien dommage car là ça prendrait tout son sens.

[Hibernatus34]

Si ça peut aider : on peut déclarer une structure dans le code déclaration de fenêtre et s'en servir en dehors.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
PROCEDURE FEN_Toto(stParamètres est ST_Paramètres)
 
ST_Paramètres est Structure
   LePèreNoël est réel
FIN

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
stParams est FEN_Toto.ST_Paramètres
stParams.LePèreNo��l = 25.12
Ouvre(FEN_Toto, stParams)

Cependant, on en vient vite à "nettoyer" ça en créant une collection de procédure dédiée à la fenêtre pour y déclarer la structure, car souvent la compilation incrémentielle foire sur ce cas (parmi tant d'autres...) et sur un gros projet ça peut être pénible de recompiler régulièrement. Les composants internes sont ensuite la seule solution à ma connaissance pour ensuite "packager" la fenêtre avec son code...

[philouZ]

C'est pour ça que les propriétés seraient intéressantes dans ce cas là. Ca allégerait grandement la lecture du code.

[Jon Shannow]

Ce qui serait cool (mais c'est peut-être possible actuellement, je ne l'ai pas trouvé) ce serait de pouvoir créer un champ/fenêtre/état dérivé de ceux existants pour adapter leurs utilisations et pouvoirs les réutiliser.
Faire un peu ça

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
TMaFenetre est une Fenetre
 
  tout ce qu'on a envie de rajouter aux fenêtres windev classiques (propriétés, méthode, évènements, ...)
fin

et ensuite pouvoir créer une fenêtre dans l'éditeur, et première ligne d'initialisation

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
Moimeme..type = TMaFenetre

Et ainsi, la fenêtre prends tous les comportements que j'ai déclaré dans mon "type" fenêtre.

[Voroltinquo]

Bonjour,
C'est déjà possible avec les patterns depuis quelques versions déjà.
On crée le/la pattern (ça c'est comme combo, je n'ai jamais su si c'était masculin ou féminin ) et on réutilise le résultat via le RAD ou le RID

[lubinfo]

Bonjour,

Une solution pour le pb d'abandon de la compatibilité avec windows xp ?
Du coup quelle est la dernière version compatible ?

[frenchsting]

Logiquement WD24...

[juju26]

Bonjour,

Une solution pour le pb d'abandon de la compatibilité avec windows xp ?
Du coup quelle est la dernière version compatible ?

version 22 à 24 mais avec quelques incompatibilité...
https://blogs.pcsoft.fr/fr/support-w...e/164/read.awp

La version 21 est la plus stable pour XP.


Aussi pour Webdev 25 : la grande nouveauté des agencements n'est pas disponible en site statique et en PHP. C'est un traitement serveur (classic et awp) (avec une bonne latence au changement de tranche de résolution). J'ai eu confirmation du support technique.
Par contre la doc des nouveautés n'indique pas que c'est un traitement 100% serveur.... donc pas de statique/php et à oublier pour du SEO.

Bien dommage car le RWD c'est pas encore ça en version 24 avec des pages complexes, à voir dans la v25....