| |
Membre enregistré
150 messages
Popularité : +15 (15 votes) |
|
Posté le 20 mai 2020 - 11:50 |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
2 572 messages
Popularité : +222 (260 votes) |
|
Posté le 20 mai 2020 - 12:44 |
Bonjour,
Il faut créer une procédure globale et cliquer sur WL qui va passer à C#
--
Cordialement,
Philippe SAINT-BERTIN |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
150 messages
Popularité : +15 (15 votes) |
|
Posté le 20 mai 2020 - 14:01 |
Bonjour Philippe
Merci pour votre réponse, j'ai lu la documentation et c'est exactement ce que je fais.
Chez moi çà provoque un arrêt brutal dès qu'on exécute le code C#.
Je précise que j'utilise en // les dernières versions de Visual Studio 2019, le framework dot.NET est donc bien installé sur ma machine.
Etant passé directement de WD17 à WD25, je n'ai pas pu tester avec les versions antérieures, mais on me dit que çà fonctionnait très bien en 23.
--
Patrice Terrier
www.zapsolution.com |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
2 572 messages
Popularité : +222 (260 votes) |
|
Posté le 20 mai 2020 - 15:07 |
Perso j'essaye de m'interdire l'utilisation de .Net dans Windev, le framework est trop lent pour que ce soit efficace, donc je ne saurais dire ça fonctionnait avant.
--
Cordialement,
Philippe SAINT-BERTIN |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
150 messages
Popularité : +15 (15 votes) |
|
Posté le 20 mai 2020 - 17:19 |
Etant développeur bas niveau, le code IL dot.NET n'est pas non plus ma tasse de thé,
cependant la syntaxe du C# est très proche de celle du C/C++ que j'utilise pour créer mes DLLs 64-bit,
ce qui dans mon cas faciliterai énormément le portage de mes fonctions Visual Studio dans WinDev surtout maintenant que l'on devrait pouvoir utiliser le code directement au format texte.
--
Patrice Terrier
www.zapsolution.com |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
2 572 messages
Popularité : +222 (260 votes) |
|
Posté le 20 mai 2020 - 17:27 |
Je comprends. Je me méfie toujours des fonctionnalités on peut utiliser .Net sans problème en saisissant le code...
--
Cordialement,
Philippe SAINT-BERTIN |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
15 messages |
|
Posté le 24 mai 2020 - 15:51 |
Patrice TERRIER a écrit :
Bonjour Philippe Merci pour votre réponse, j'ai lu la documentation et c'est exactement ce que je fais. Chez moi çà provoque un arrêt brutal dès qu'on exécute le code C#. Je précise que j'utilise en // les dernières versions de Visual Studio 2019, le framework dot.NET est donc bien installé sur ma machine. Etant passé directement de WD17 à WD25, je n'ai pas pu tester avec les versions antérieures, mais on me dit que çà fonctionnait très bien en 23. -- Patrice Terrier www.zapsolution.com
Bonjour,
chez moi, tout projet contenant ne serait-ce qu'une déclaration de procédure en C# fait crasher windev à l'ouverture du projet.
sur un projet vierge, le fait d'en déclarer une fait crasher à la sauvegarde ou à la compilation du projet.
Problème remonté au ST. incident référencé 117 303 (pour info). Je ne sais pas si c'est résolu avec l'update 3...
Bon courage...
Grégoire |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
150 messages
Popularité : +15 (15 votes) |
|
Posté le 24 mai 2020 - 21:47 |
Grégoire
L'update 3, ne change rien, malheureusement çà plante toujours autant...
--
Patrice Terrier
www.zapsolution.com |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
286 messages
Popularité : +24 (28 votes) |
|
Posté le 25 mai 2020 - 10:16 |
Pourquoi alors ne pas migrer complètement le projet vers le C# ... ?
C'est ce que j'ai fait et je ne le regrette nullement  |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
160 messages
Popularité : +18 (22 votes) |
|
Posté le 25 mai 2020 - 10:34 |
Gemin1961 a écrit :
Pourquoi alors ne pas migrer complètement le projet vers le C# ... ?
C'est ce que j'ai fait et je ne le regrette nullement
Parce que le développement en Windev est 10 fois plus vite  voir 100  |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
150 messages
Popularité : +15 (15 votes) |
|
Posté le 25 mai 2020 - 12:33 |
Bonjour Monsieur Gemin1961
J'utilise d'ores et déjà plusieurs langages de programmation, c'est justement pour cette raison que le fait de pouvoir utiliser la syntaxe [C#] en lieu et place du code [WL] m'intéresse, car je pourrai ainsi éviter des transpositions fastidieuses.
Pour créer des interfaces complexes, je vais effectivement beaucoup plus vite avec WinDev qu'avec n'importe quel autre langage.
--
Patrice Terrier
www.zapsolution.com |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
946 messages
Popularité : +102 (110 votes) |
|
Posté le 25 mai 2020 - 19:28 |
Bonjour
Je suis tout à fait d'accord avec Mr Terrier quant il écrit "...car je pourrai ainsi éviter des transpositions fastidieuses..."
On trouve souvent du code C++, C# surtout sur GitHub qui ne sont pas forcément facilement traduisible en WDLangage.
Exemple : calculs de CRC64 avec possibilité de donner la valeur du polynôme générateur, fonction de hachage cryptographique
J'ai essayé en V24 :
public static int ProcedureCsharp(int n)
{
return n++;
}
De l'appeller avec le code :
Trace(ProcédureCsharp(4))
Et j'ai cette erreur :
Erreur à la ligne 39 du traitement Clic sur Bouton17.
L'invocation de la méthode <ProcédureCsharp()> du type <ProcéduresGlobales> a échoué
L'assemblage <D:\Program Files (x86)\PC SOFT\WINDEV 24\Programmes\FrameWork\Win64x86\Essais.dll> n'a pas pu être ouvert
Le framework .NET a renvoyé l'erreur suivante :
Impossible de charger le fichier ou l'assembly 'file:///D:\Program Files (x86)\PC SOFT\WINDEV 24\Programmes\FrameWork\Win64x86\Essais.dll' ou une de ses dépendances. Le fichier spécifié est introuvable.
----- Informations techniques -----
Projet : Essais
Appel WL :
Traitement de 'Clic sur Bouton17' (MainForm.Bouton17), ligne 39, thread 0
Que s'est-il passé ?
L'invocation de la méthode <ProcédureCsharp()> du type <ProcéduresGlobales> a échoué
L'assemblage <D:\Program Files (x86)\PC SOFT\WINDEV 24\Programmes\FrameWork\Win64x86\Essais.dll> n'a pas pu être ouvert
Le framework .NET a renvoyé l'erreur suivante :
Impossible de charger le fichier ou l'assembly 'file:///D:\Program Files (x86)\PC SOFT\WINDEV 24\Programmes\FrameWork\Win64x86\Essais.dll' ou une de ses dépendances. Le fichier spécifié est introuvable.
Je cherche sur mon disque : D:\Program Files (x86)\PC SOFT\WINDEV 24\Programmes\FrameWork\Win64x86\Essais.dll
Je le trouve dans : D:\Mes Projets\Essais\Exe\Exécutable Windows 64 bits
je fait une copie et je relance
Nouvelle erreur :
Erreur à la ligne 39 du traitement Clic sur Bouton17.
L'invocation de la méthode <ProcédureCsharp()> du type <ProcéduresGlobales> a échoué
Quelle est mon erreur ?
--
« L'erreur ne devient pas vérité parce qu'elle se propage et se multiplie ; la vérité ne devient pas erreur parce que nul ne la voit. » Gandhi |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
946 messages
Popularité : +102 (110 votes) |
|
Posté le 25 mai 2020 - 19:58 |
Résolu,
j'ai complétement isolé la procédure dans une collection de procédure globale et modifié le code C
public static int IncC(int n)
{
n++;
return n;
}
par contre il faut toujours copier le fichier dll après compilation
--
« L'erreur ne devient pas vérité parce qu'elle se propage et se multiplie ; la vérité ne devient pas erreur parce que nul ne la voit. » Gandhi |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
286 messages
Popularité : +24 (28 votes) |
|
Posté le 25 mai 2020 - 22:59 |
C'est assez étrange ...
public static int IncC(int n)
{
n++;
return n;
}
Le même code en 24 génère l'erreur suivante :
Erreur :PPi_CSharp.cs(43,21): (Emplacement du symbole par rapport à l'erreur précédente) |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
286 messages
Popularité : +24 (28 votes) |
|
Posté le 25 mai 2020 - 23:08 |
C'est une erreur de compilation mais le code s exécute correctement, il affiche bien la trace ...
Trace(IncC(3))
De plus en plus étrange ... |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
946 messages
Popularité : +102 (110 votes) |
|
Posté le 25 mai 2020 - 23:51 |
Bonsoir Gemin1961
Maintenant cela fonctionne et je continue mes tests en faisant appel à de petites fonctions que j'ai complétement isolées des procédures globales écrites en WDlangage. Néenmoins je dois quand même après chaque compilation du projet copier la dll générée par Windev. pour ne plus "m'em...." avec ça j'ai fait un batch que j'éxécute avant de tester le programme windev.
Je teste sur Windows10pro à jour + Windev24 01F240042h et je génére du 64 bits (je ne sais pas si c'est utile mais j'ai aussi d'installé sur ce poste Visual Studio Community 2017 à jour)
--
« L'erreur ne devient pas vérité parce qu'elle se propage et se multiplie ; la vérité ne devient pas erreur parce que nul ne la voit. » Gandhi |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
946 messages
Popularité : +102 (110 votes) |
|
Posté le 26 mai 2020 - 00:32 |
Je viens de remarquer qu'il ne faut surtout pas mettre de ligne de commentaire avant la déclaration de la fonction !!
/* test 04 */
public static string Try04C(string DataString)
{
string ListeCodeASCII = "";
char MyChar;
if (DataString.Length > 0) {
for (int i = 0; i < DataString.Length; i++) {
if (ListeCodeASCII.Length > 0)
ListeCodeASCII += "\t";
ListeCodeASCII += (int) DataString[i];
}
}
return ListeCodeASCII;
}
La compilation génére l'erreur : Erreur :L'expression ne renvoie pas de résultat.
Si on enleve la ligne /* test 04 */ plus de problème
(ça beug aussi avec // qui est pourtant préconisé sur https://doc.pcsoft.fr/fr-FR/?2012008&name=Saisir_du_code_C#)
--
« L'erreur ne devient pas vérité parce qu'elle se propage et se multiplie ; la vérité ne devient pas erreur parce que nul ne la voit. » Gandhi |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
286 messages
Popularité : +24 (28 votes) |
|
Posté le 26 mai 2020 - 08:48 |
Bonjour Philippe .
Quelle DLL dois-tu recopier manuellement ?
De mon côté j'ai une dll qui porte le nom de mon projet et celle-ci se trouve déjà dans le répertoire exe
Bien belle journée à toi |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
286 messages
Popularité : +24 (28 votes) |
|
Posté le 26 mai 2020 - 08:51 |
Pour info je suis en Win 10 Pro à jour avec WD 24 77f / 32 |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
286 messages
Popularité : +24 (28 votes) |
|
Posté le 26 mai 2020 - 09:03 |
Par contre j'ai toujours l'erreur suivante :
PPi_Tools.cs(43,21): error CS0101: L'espace de noms 'WL' contient déjà une définition de 'PPi_Tools'
PPi_CSharp.cs(43,21): (Emplacement du symbole par rapport à l'erreur précédente) |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
286 messages
Popularité : +24 (28 votes) |
|
Posté le 26 mai 2020 - 09:07 |
Je me demande si il n'est pas nécessaire de joindre un fichier texte avec les prototypes des fonctions comme en C |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
286 messages
Popularité : +24 (28 votes) |
|
Posté le 26 mai 2020 - 09:37 |
As-tu déjà fais un tour dans le répertoire Mes Projets\24\WD\Mon_Project\.NET\Compile\ ... ?
C'est assez intéressant |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
286 messages
Popularité : +24 (28 votes) |
|
Posté le 26 mai 2020 - 09:45 |
Pour l'erreur WL,... j'avais une fonction écrite en C# mise en commentaire dans une autre collection ...
je l'ai déplacé dans la collection écrite uniquement C# et je n'ai plus d'erreur ... |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
946 messages
Popularité : +102 (110 votes) |
|
Posté le 26 mai 2020 - 18:28 |
Après différents essais j'ai noté les points suivants :
- il ne doit y avoir qu'une seule et unique collection de procédures pouvant contenir des procédures écrite en C#
- il ne doit pas y avoir de commentaire avant la ligne de déclaration d'une procédure (Sur la même ligne ca passe que ce soit avec // ou /**/)
Suite à la remarque de Gemin1961 :
PCsoft utilise le compilateur situé dans le répertoire : C:\Windows\Microsoft.NET\Framework\<version de framework>\csc.exe
pour générer <nom du projet.dll> (voir dans le répertoire <répertoire du projet>\.NET\Compile\Compile.bat).
On y retrouve :
- un fichier pour la collection de procédure globales contenant le code en C# : <nom de la collection de procédure globale>.cs
- le fichier Compile.bat contenant l'ordre pour créer nom du projet>.dll
Note : En cas de bonne compilation le répertoire <répertoire du projet>\.NET est supprimé
pour éviter son effacement, créer une petite erreure comme ".lengt" au lieu de ".length"
--
« L'erreur ne devient pas vérité parce qu'elle se propage et se multiplie ; la vérité ne devient pas erreur parce que nul ne la voit. » Gandhi |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
946 messages
Popularité : +102 (110 votes) |
|
Posté le 27 mai 2020 - 21:02 |
Suite des tests :
- Faire trés attention en cas de renomage d'une procédure C#
Quand la déclaration de la procédure est en première ligne :
Exemple :
1 - public static byte[] csCrypte(string text, byte[] key, byte[] iv)
2 - {
et que l'on renome csCrypte en Crypte on aura dans le code :
1 - PROCEDURE Crypte()
2 - public static byte[] csCrypte(string text, byte[] key, byte[] iv)
3 - {
Quant la déclaration de la procédure C# est précédée de clause using :
Exemple on a :
1 - using System.Text;
2 - public static byte[] Crypte(string text, byte[] key, byte[] iv)
3 - {
et que l'on renome Crypte en csCrypte on aura dans le code :
4 - Procédure csCrypte()
2 - using System.Text;
3 - public static byte[] cCrypte(string text, byte[] key, byte[] iv)
4 - {
- Vu que dans la documentation https://doc.pcsoft.fr/fr-FR/?2012008&name=Saisir_du_code_C# il est spécifié que :
«Les déclarations "using" situées avant les prototypes des procédures en C# sont prises en compte pour toute la collection.»
On peut créer une procédure «bidon» sans aucun code :
public static void BidonForUsing()
{
}
dans laquelle on y met la liste des «using» dont on a besoin
--
« L'erreur ne devient pas vérité parce qu'elle se propage et se multiplie ; la vérité ne devient pas erreur parce que nul ne la voit. » Gandhi |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
286 messages
Popularité : +24 (28 votes) |
|
Posté le 28 mai 2020 - 08:42 |
Dans le cas du renommage de fonction serait donc de récréer la fonction avec le nom souhaité et de récupérer le code de l'ancienne fonction |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
286 messages
Popularité : +24 (28 votes) |
|
Posté le 28 mai 2020 - 08:47 |
Très intéressant tes remarques Philippe, surtout pour la clause "using" ... je buttais la dessus depuis un moment ... 
Bien cordialement
Gemini1961 |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
946 messages
Popularité : +102 (110 votes) |
|
Posté le 28 mai 2020 - 12:37 |
Voici la méthode que j'ai trouvée pour integrer le code C# de sur la page : https://gist.github.com/maxpert/c544fade7be86270021ef8799cff73f6
- Copie des lignes dans le fichier «crc64.cs» dans le repertoire du projet (à tester l'importance case sensitif ou pas).
- Modifications de façon à avoir :
namespace Phil
{
public static class
Crc64
{
public static ulong compute_crc(string DataString, ulong crc = 0) {
ulong[] TableCrc = {
... ici les valeurs de la table ...
};
for (int i = 0; i < DataString.Length; i++){
crc = TableCrc[(byte)(crc ^ (ulong) DataString[i])] ^ (crc >> 8);
}
return crc;
}
}
}
notes :
- Renomage des variables pour plus de lisibilité du code C# (pas obligatoire...)
- Modifier le type byte[] en string ne sachant pas encore comment passer ce type de variable de Windev au C#
- je crois qu'il faut faire attention à la case
- pour le namespace j'ai évité "WL" c'est déjà pris par PCSoft
- Intégration du fichier source "crc64.cs" directement dans la liste des éléments du projet :
- soit par la liste des éléments,
- soit en sélectionnant "Autres" dans le bouton droit de l'explorateur de projet.
- Dans la collection de procédure globale contenant les fonctions C# ajout d'une procédure Try07C avec le code :
using Phil;
public static ulong Try07C(string DataString, ulong InitCrc)
{
return Crc64.compute_crc(DataString, InitCrc);
}
- Compilation ok
- Copie du fichier <nom du projet.dll>
- Teste en faisant en WLangage :
Trace(Try07C("ABCDEF", 0x00))
--
« L'erreur ne devient pas vérité parce qu'elle se propage et se multiplie ; la vérité ne devient pas erreur parce que nul ne la voit. » Gandhi |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
150 messages
Popularité : +15 (15 votes) |
|
Posté le 29 mai 2020 - 09:36 |
Bonjour Mr Pasquali
Avez-vous réussi à écrire { directement } une procédure en [C#] sans passer par un assemblage ?
--
Patrice Terrier
www.zapsolution.com |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
946 messages
Popularité : +102 (110 votes) |
|
Posté le 29 mai 2020 - 12:33 |
Bonjour,
Voici un tout petit exemple en image
--
« L'erreur ne devient pas vérité parce qu'elle se propage et se multiplie ; la vérité ne devient pas erreur parce que nul ne la voit. » Gandhi |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
150 messages
Popularité : +15 (15 votes) |
|
Posté le 29 mai 2020 - 12:42 |
Merci du retour.
D'après la capture d'écran vous êtes en version 24, alors que moi j'utilise la dernière version 25 ...
--
Patrice Terrier
www.zapsolution.com |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
946 messages
Popularité : +102 (110 votes) |
|
Posté le 29 mai 2020 - 12:46 |
Mon environement :
Windows10 pro version 1909 (version du système d'exploitation 18363.836)
Windev 24 version 01F240042h installé en 32bits (pas testé installé en 64 bits))
Version du framework utilisé par PCSoft : C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319
--
« L'erreur ne devient pas vérité parce qu'elle se propage et se multiplie ; la vérité ne devient pas erreur parce que nul ne la voit. » Gandhi |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
946 messages
Popularité : +102 (110 votes) |
|
Posté le 29 mai 2020 - 13:14 |
@Ptarice Terrier : Votre Windev est-il installé en 32 ou en 64 bits ? Certaines fonctionalités fonctionnaient en 32 mais pas en 64...
--
« L'erreur ne devient pas vérité parce qu'elle se propage et se multiplie ; la vérité ne devient pas erreur parce que nul ne la voit. » Gandhi |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
150 messages
Popularité : +15 (15 votes) |
|
Posté le 29 mai 2020 - 15:46 |
WinDev 64-bit
Car je suis sous Windows 10 Pro 64-bit, et ce depuis que le mode 64-bit et UNICODE sont les modes natifs de l'OS.
Sinon on passe par l'émulateur Wow64, ce qui est moins rapide.
En moyenne je constate une accélération de 30% de mes DLLs codées en C++, sans parler de l'espace mémoire accessible qui s'avère bien utile pour mes applications 3D.
--
Patrice Terrier
www.zapsolution.com |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
946 messages
Popularité : +102 (110 votes) |
|
Posté le 29 mai 2020 - 17:24 |
Reste plus qu'à attendre qu'une bonne âme, ayant installé Windev25 en 32 bits veuille bien testé la saisie de code C#...
--
« L'erreur ne devient pas vérité parce qu'elle se propage et se multiplie ; la vérité ne devient pas erreur parce que nul ne la voit. » Gandhi |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
286 messages
Popularité : +24 (28 votes) |
|
Posté le 29 mai 2020 - 17:37 |
Je pense que depuis la dernière MaJ de WinDEV 25, la version 32 bits rencontre des problèmes ( à vérifier ) , de mon coté je suis en 64 bits sur la V25 |
| |
| |
| | | |
|
| | |
| |
Posté le 02 juin 2020 - 16:44 |
Bonjour,
Sur mon windev 25 à jour 32 bits j'ai tenté de créer la fonction Crc64
proposée par Philippe,
un passage à la ligne pour décaler le commentaire par défaut proposé par
windev, un plantage de windev
eric l.
> Le 29/05/2020 à 15:24, Philippe Pasquali a écrit :
Reste plus qu'à attendre qu'une bonne âme, ayant installé Windev25 en 32
bits veuille bien testé la saisie de code C#...
--
« L'erreur ne devient pas vérité parce qu'elle se propage et se
multiplie ; la vérité ne devient pas erreur parce que nul ne la voit. »
Gandhi |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
946 messages
Popularité : +102 (110 votes) |
|
Posté le 02 juin 2020 - 20:16 |
Bonjour
Il semblerais que la version 25 ne suporte plus cette fonctionalité. Reste à savoir à partir de quelle release cela ne fonctionne plus car sauf erreur de ma part chez «Gemin1961» (qui est en V25 installé en 64 bits) cela semble fonctionner.
--
« L'erreur ne devient pas vérité parce qu'elle se propage et se multiplie ; la vérité ne devient pas erreur parce que nul ne la voit. » Gandhi |
| |
| |
| | | |
|
| | |