Discussion :

[Pierre GIRARD]

Pour préciser, ça coince ICI :

Code :

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

1
2
3
4
5
6
7
8
Ligne de commande dcc pour "JvStdCtrls.dpk"
...   
[DCC Erreur] JvRichEdit.pas(1994): E2003 Identificateur non déclaré : 'StrLCopyA'
[DCC Erreur] JvRichEdit.pas(1997): E2003 Identificateur non déclaré : 'StrLenA'
[DCC Erreur] JvRichEdit.pas(6448): E2003 Identificateur non déclaré : 'StrICompA'
[DCC Avertissement] JvRichEdit.pas(6448): W1023 Comparaison de types signés et non signés - opérandes élargis
[DCC Erreur fatale] JvDynControlEngineJVCL.pas(1917): F2063 Impossible de compiler l'unité utilisée 'JvRichEdit.pas'
Echec

Et le code :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
function FileNameToHGLOBAL(const AFileName: AnsiString): HGLOBAL;
var
  DataPtr: Pointer;
  Buffer: array[0..MAX_PATH] of AnsiChar;
  Len: Integer;
begin
  // DOC : Each entry point that accepts file names should expect all file name
  //       arguments from Word to be in the OEM character set (unless the character
  //       set is explicitly negotiated using RegisterApp).
  //
  //  For example: CharToOem will translate the copyright (c) symbol (=1 char)
  //  to C¸ (or something). Not doing so will result in errors.
 
  StrLCopyA(Buffer, PAnsiChar(AFileName), Length(Buffer));
...

Et dans JvDynControlEngineJVCL :

Code :

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

1
2
3
4
function TJvDynControlJVCLRichEdit.ControlGetValue: Variant;
begin
  Result := Text;
end;

[Pierre GIRARD]

D'ailleurs, j'ai exactement la même erreur avec Delphi 7 et en utilisant les outils fournis par JEDI :

[Pascal Jankowski]

Avec une simple recherche sur Google, (car je n'utilise pas cette bibliothèque), on retombe sur ce lien reportant l'erreur de compilation de l'unité JvRichEdit.pas.

[Pierre GIRARD]

Avec une simple recherche sur Google, (car je n'utilise pas cette bibliothèque), on retombe sur ce lien reportant l'erreur de compilation de l'unité JvRichEdit.pas.

Oui ??? et c'est quoi la solution ? J'ai remplacé le "JclAnsiStrings.pas" par celui du lien, et c'est toujours pareil. Et dans tous les cas, le fait de mettre en téléchargement un truc qui échoue à 100% me semble assez léger.

Décidément, JEDI, c'est lourd, pénible à installer ... et en plus, ça ne marche pas.

Conclusion : Je viens de commander "LMDRichPack". Pour environ 71€, on a un truc qui s'installe en quelques minutes (en tous cas la version Démo) et qui marche du premier coup . Les composants sont directement ajoutés à XE2 sans passer par des compilations hasardeuses ou autres manipulations foireuses qui imposent la réinstallation complète de XE2.

Bref, à part à mes ennemis intimes, je ne recommanderais jamais l'installation de JEDI.

[Pascal Jankowski]

Oui ??? et c'est quoi la solution ? J'ai remplacé le "JclAnsiStrings.pas" par celui du lien, et c'est toujours pareil. Et dans tous les cas, le fait de mettre en téléchargement un truc qui échoue à 100% me semble assez léger.

D'après le lien que je t'ai donné, qui est un report du dit bug, il apparaît que cette bibliothèque ne peut pas être installée sur un XE

[Pierre GIRARD]

D'après le lien que je t'ai donné, qui est un report du dit bug, il apparaît que cette bibliothèque ne peut pas être installée sur un XE

Ah oui ???

Salut,
Je viens juste d'installer Jedy sous XE3, et justement, je suis passé par là, je crois qu'il y a 2 volets : l'un pour la 32Bits et l'autre pour la 64Bits. J'ai eu un message d'erreur quand je ne décochais pas la case dans le 2ème volet ..
Bye

et

j'ai installé la version pour XE4 , le jvRichedit se trouve dans les JvEdits , pas encore testé par contre l'insertion d'une image , il faut que je retrouve le code...

Si ça marche sur XE3 et sur XE4, pas de raison que ça échoue sur XE2. Et dans tous les cas, ça ne marche pas non plus sur Delphi 7 vu que j'ai exactement la même erreur.

... peut-être que ça marche sur Delphi 2 ?

[SergioMaster]

Es-tu sur que tes paquets soit à jour ? moi en général je passe par les SVN ou les dailys peu souvent par les fichiers proposé en SourceForge.
Franchement pour XE4 , cela n'a pas été plus difficile a installer que tout autre paquet de composants ( le fait est que je suis en 32bits ce qui peut avoir un rôle a jouer ) , et a ma souvenance mes installations pour D7,D2010 (j'en suis resté a la 3.39) non plus .

[Pierre GIRARD]

Je dois avouer que j'ai utilisé les versions JVCL et JCL téléchargé depuis EDN et uniquement pour XE4 . Comme cela s'est installé nickel , je ne suis pas allé plus loin (même si j'ai téléchargé les dernières 'daily' versions des 2 produits ici pour JCL et là pour la JVCL
pour une fois je n'ai pas utiliser le SVN (déçu par mes dernières manips SVN avec XE4 , chez moi ça fonctionne pas )...

Mais dans tous les cas, ça passe par des .bat et les compilations en ligne de commande ne fonctionnent pas sur ma version de XE2.

Et puis j'ai essayé à partir des liens donnés sur le site JEDI. Le résultat est toujours le même dans tous les cas (j'en suis à 3 versions différentes).

En direct live et pendant que je répondais, j'ai installé LMD RichPack 2013 et en moins de 5 min mon problème est résolu. Vive les produits payants.

[Moez.B]

Mais dans tous les cas, ça passe par des .bat et les compilations en ligne de commande ne fonctionnent pas sur ma version de XE2.

Et puis j'ai essayé à partir des liens donnés sur le site JEDI. Le résultat est toujours le même dans tous les cas (j'en suis à 3 versions différentes).

En direct live et pendant que je répondais, j'ai installé LMD RichPack 2013 et en moins de 5 min mon problème est résolu. Vive les produits payants.

Salut

Actuellement, je travaille sur un XE2 et dans lequel il y a la JVCL. Donc, je crois que ton problème pourra être résolu. Sinon, est ce que tu peux avoir une version antérieure de la JEDY et répéter l'installation. La version que nous travaillons avec ici est la 2.3 comme Jedy Code Library.
Juste une petite remarque sur les composants payants, il n'y a pas de magie dans ces composants puisque l'ancêtre de tous les ancêtres de ces composants (payants ou en libre utilisation) est un TObject

Bye

[ShaiLeTroll]

Juste une petite remarque sur les composants payants, il n'y a pas de magie dans ces composants

En fait, la magie c'est que pour avoir l'équivalent de la JEDI VCL, il faut acheter peut-être 4 ou 5 Pack différents !
J'ai déjà travaillé dans une société, où il fallait installer plus de 15 libs, tu passais 3h à installer D7 !!!

L'autre magie des composants payant, si tu les essayent en trial et que tu ne peux pas les installer, la réaction est simple, tu en essayes un autre, du coup, les éditeurs de composants payants ont intérêt à ce que leurs déploiements soient robustes pour optimiser les ventes !

Il est dommage que la JVCL ne soient pas plus découpées, cela installe tout plein de truc inutile alors que l'on veut juste le TJvRichEdit ou TJvDateEdit
Je ne l'ai utilisé que lorsque mon employeur l'utilisait, j'ai toujours réussi à m'en passer !
D'ailleurs, lorsque je le peux, comme avec le TComPort, je n'installe pas le package, j'inclus juste les sources au projet qui l'utilise, avec les composants non visuels, cela simplifie nettement la vie !

Il est même assez ironique que le composant qui pose problème à Pierre GIRARD soit le TJvRichEdit, le seul qui l'intéresse au final !

[Pierre GIRARD]

Oui ... mais non. J'ai juste besoin d'un "RichEdit" évolué celui que j'ai installé en quelques minutes fonctionne parfaitement et va même largement au delà de ce que je voulais.

Actuellement, je suis déjà en train de tester et je fais au moins ce que je voulais faire. Et même, les possibilités de ce composant me donnent de nouvelles idées pour l'évolution de mon application.

Conclusion :
- En 2 jours de JVCL = rien en dehors d'une réinstallation forcée de XE2.
- En 2 heures de LMD = Je suis en bonnes voies.

LMD Rich Pack est un produit très puissant, hyper facile à installer et encore plus facile à mettre en œuvre. Et même si j'avais besoins de tous les outils, le prix de l'ensemble des composants "LMD Tools"reste raisonnable.

Si JEDI et les JVCL souhaitent atteindre ce niveau, ils ont un sacré boulot devant eux :

1. Fournir des packages dignes de ce nom (pas des .bat minables) =
   - Un exécutable pour Delphi 6
   - ...
   - Un exécutable pour Delphi 2010
   - ...
   - Un exécutable pour XE2
   - ...
   - etc... quelque soit l'environnement du client.
2. Installer directement les composants (CaD pas des sources qu'il faut compiler)
3. Créer directement les bons chemins et pas obliger à rajouter des informations ici ou là au risque de perdre du temps à rechercher où ça coince.
4. Faire un produit non "potentiellement" destructeur et donc qui n'oblige pas à reprendre l'installation de XE2 à 0.
5. Fournir un produit ... installable. Comme dit précédemment, j'en ai essayé trois sur trois versions différentes. Au final, c'est deux jours de perdus avec trois versions dont aucune ne s'installe (même à la petite cuillère).
   Les réponses :
   Il faut télécharger ici plutôt que là, il faut la version ci plutôt que ça. Ensuite, essayer la version -1 ou -2 ou la version -1 des JCL avec la version -2 des JVCL ... et réciproquement. A ce train d'enfer, dans 6 mois, j'y serais encore.
6. Bref : proposer un produit fini et directement installable sur n'importe quelle configuration.

Avec LMD, j'ai simplement téléchargé la version 32 bits pour XE2, et ça marche du premier coup.

[Pierre GIRARD]

...Il est même assez ironique que le composant qui pose problème à Pierre GIRARD soit le TJvRichEdit, le seul qui l'intéresse au final !

Sauf un détail de taille : Le JvStdCtrls est un pré-requis pour nombre d'autres composants. Du coup, c'est un des packages les plus importants qui refuse de se compiler.

... et d'ailleurs, c'est un Bug connu et répertorié (voir les interventions de "Pascal Jankowski") pour lequel je n'ai toujours pas de réponse claire ni de solution simple.

Quoi qu'il en soit, je laisse le fil en "Résolu" car j'ai ma solution, même si elle contourne le problème.