"4D View Pro" ni "4D View" ne se charge pas 4D V17 32 bits

Bonjour,

Je suis en cours d’adaptation d’une base actuellement en V16 vers la V17. Pour des raisons liées à l’infrastructure du client, il est nécessaire de travailler en 32 bits. En effet, je dois utiliser des vieux drivers pour une base sysBase. Ces drivers n’existent qu’en version 32 bits.

J’ai adapté la base en utilisant un Server en 64 bits, pas de problème. Les procédures nécessaires ont été “déportées” pour s’exécuter sur un client 32 bits. Jusque là tout va bien.

Mon dernier problème concerne 4D View/4D View Pro.
Dans la version 32 bits, ni le plugin 4D View ni le plugin 4D View Pro ne se charge. Par contre le plugin 4D Write se charge correctement.

Je sais que 4D ne supporte plus les versions 32 bits mais là je suis coincé.

Si quelqu’un a une explication sur le fait qu’aucun des plugins ne se charge?

Merci d’avance pour vos conseils.
Luc

J’ai pu faire la migration de 4D Write en 32 bits en comparant un certain nombre de textes convertis dans les deux versions mais c’est impossible pour 4D View : l’ancien ne fonctionne qu’en 32 bits et le nouveau en 64 bits.
La conversion s’est passée correctement mais il a fallu faire des comparaisons entre deux occurrences de 4D, une en V17R4 32 et une en V17R5.
Au préalable, j’avais exporté toutes mes zones 4D View sur le disque, au cas où.

Je n’ai par contre pas d’explication à te proposer pour le non-chargement de 4D View…

Bonjour,

J’ai fini par comprendre le problème. en fait “4D View” bien que le plugin contienne le code 64 bits ne fonctionne pas. Il se charge en partie mais à l’exécution, message d’erreur.

La question concerne le portage de “4D View” vers “4D View Pro”. Si je ne charge pas “4D View” mon code “4D View” n’est plus exploitable.

Ô13000;5Ô(myview;…)

Comment faire pour convertir le code “4D View” en “4D View Pro”? soit je suis une buse (ce qui fort possible) soit le nouveau plugin n’est pas directement compatible au niveau code.

Mon problème c’est que tous les tableaux sont générés par du code et pas par une template.

Si quelqu’un a une idée?

Merci d’avance de votre
Cdlt
Luc

Mauvaise nouvelle, il faut TOUT redevelopper. Entre 4D View et 4D View Pro il n’y a que le nom qui est commun. 4D View Pro est un nouveau produit. Et, pour l’instant, j’ai pas l’impression que ce que je pouvais faire avec 4D View le soit en 4D View Pro. A voir ce que vous faites(faisiez) de votre coté.

Pour voir le code de 4D View, il suffit d’installer l’ancien plugin vous aurez le nom des commandes de 4D View, MAIS rien ne fonctionnera (puisque pas compatible 64 bit).

Bon courage. :frowning:

Bonjour Manuel,

Cela confirme ce que je pensais. J’ai du mal à comprendre la stratégie de 4D sur l’aspect 32/64 bits et sur l’évolution des plugins.

Aujourd’hui sir je veux passer ma base en V17/64 bits, il faut que je ré-écrive toute la partie 4D View. Il serais peut-être judicieux que 4D finalise le portage de “4D View” en 64 bits le temps que la version Pro soit 100 % compatible.

4D souhaite arrêter le développement en 32 bits, mais il ne peut pas encore livrer l’intégralité du logiciel en 64 bits. Il faudrait que l’on m’explique.

Merci encore pour ton aide. Ca va m’éviter de passer trop de temps sur ce problème.

Cordialement
Luc

J’aimerai savoir s’il serait envisageable que 4D nous fournisse des STUB (je crois que c’est comme cela qu’on dit :doubt:) pour les plug-ins 4D View et 4D Write afin qu’on puisse continuer à voir le nom des commandes dans le code, que celui-ci puisse être compilé (en 64 bit), mais que ces mêmes commandes ne fassent rien (même pas d’alerte) :?: :idea:

Cela me permettrait de compiler un client en 64 bit qui serait une version Light qui permettrait au moins d’executer le reste des fonctions pour les postes livrés en standard sous macOS 10.15.

Resterait encore l’utilisation de la nouvelle couche réseau à gérer mais bon.

Bonjour,

Je viens d’avoir la confirmation de 4D (Via TAOW) qu’il fallait effectivement refaire tout le boulot pour pouvoir utiliser 4D View Pro.

Pas simple l’affaire…

Donc pour l’infant je reste en 32 bits.

Cordialement
Luc

J’ai passé toutes mes commandes de 4D View en commentaire avant de basculer.

Elles me servent de guide pour réécrire, plus ou moins, car la logique est différente.

Le problème c’est que je ne peux pas basculer pour l’instant, le 4D View Pro actuel est TRÈS loin de permettre ce que je fais actuellement avec le 4D View.

Donc, ce que je voudrais c’est qu’en attendant, on puisse déployer une application avec des clients en 32 bit fonctionnels (donc je ne peux pas commenter les commandes 4D View pour ces clients ET des clients en 64bit qui n’utiliserons PAS les plug-ins 4D View et 4D Write mais qui seront compilés en partant de la même base.

Il faudrait que les plug-ins contiennent des commandes en 64 bit vierge qui ne font rien et qui ne lancent même pas d’alerte. Charge à moi de ne pas les appeler (ou utiliser) sur les clients en 64 bit. C’est simplement pour n’avoir qu’une seule base à gérer pour l’ensemble.

Bonjour,

C’est exactement le problème que je rencontre.
J’ai une bonne quinzaine de documents 4D View que je fabrique uniquement via le code. Tant que la version 64 n’est pas développée, j’aimerais vraiment avoir les deux plugins dans le même environnement, 32 bits de préférences dans un premier temps.

Je vais faire une tentative pour générer dans un document ce qui est “statique” et voir ce que donne la conversion. C’est moins souple pour moi.

Cordialement
Luc

Je comprend votre besoin.

J’avais mis pendant un temps des
Si(en 32 bits)
Mon code valable en 32 b
Fin de si
Mais pour compiler, on retombe sur la problématique.

Ou alors une sous-méthode pour tout le code 4D View mais ce n’est pas facile d’isoler les commandes…

La solution Si/sinon ne convient pas.
Ce qu’il faudrait ce sont directives de compilation similaires à ce que l’on trouve en général dans les compilateur C.

#if compilation_32_bits // Code 32 bits

Ici le code 4D 32 bits

#else // 64 bits

Ici le code 64 bits.

#end

Le must serait qu’en interprété, les directives soient aussi prises en compte.

Ca permettrait de s’en sortir plus facilement.

Luc

Si vous copiez le dossier “4D View.bundle” du dossier “plugins” de votre 4D 32 bits vers le dossier “plugins” de votre 4D 64 bits, alors vous pouvez ouvrir vos bases qui contiennent des commandes de 4D View, les voir, vous pouvez même compiler la base sans que cela ne génère d’erreur, simplement leur exécution générera une erreur.

Il est donc tout à fait possible dans le cadre d’une migration de déplacer temporairement 4D View dans votre 4D 64 bits pour continuer à voir votre code, à vous bien entendu de protéger son exécution avec des tests lors de l’exécution en 64 bits.

Comme le composant 4D View Pro est aussi disponible dans les versions 32 bits, vos commandes 4D View Pro seront aussi visibles et compilables en version 32 bits, simplement elles ne pourront pas être exécutables, il faudra les protéger.

Attention, cela vous limite à l’utilisation des commandes de 4D View Pro disponibles dans les versions de 4D disposant encore d’une version 32 bits, donc cela ne fonctionnera pas pour les versions les plus récentes du programme R comme la v17R6 qui est exclusivement 64 bits.

Le but serait de faire tourner un client 4D v17.3 en 64 bit sous Catalina.

Il n’est pas question de 4D View Pro ici.

Le client exécute une base qui comporte les plug-ins 4D View et 4D Write.

Cela pour pouvoir exécuter une version light de la base (sans utiliser ces plug-ins non fonctionnels en 64 bit).

Est-ce envisageable ? quelles sont les restrictions ? (utilisation de la couche réseau legacy network ?)
Il FAUT que le client tourne sous macOS 10.15 Catalina. Avez-vous déjà testé/compilé un exemple de ce type qui soit fonctionnel ?

Oui bien sûr, c’est totalement faisable, il suffit de copier comme je vous l’ai indiqué votre dossier “4D View.bundle” du dossier “plugins” d’une version 32 bits à la version 64 bits, à protéger l’exécution du code spécifique à 4D View, et ça va marcher directement après compilation en 64 bits.

Que cela fonctionne en 64 bit, OK, mais la question porte sur la compatibilité de ce même client sous macOS Catalina (qui n’autorise plus aucun code 32 bit).

Cela va fonctionner sous Catalina comme sous n’importe quel autre OS 64 bits, un exécutable 64 bits quel qu’il soit ne peut plus appeler de code 32 bits en son sein, donc si vous pouvez le lancer en 64 bits, vous êtes déjà dans un environnement exclusivement 64 bits du point de vue de l’application, donc cela fonctionnera même dans un OS qui ne permet plus de 32 bits.

Je viens de faire le test (NB: un bémol on a désactivé GateKeeper sur le poste de test); Effectivement cela fonctionne, il y a quand même des bizarreries:

  • plantages aléatoires
  • lorsqu’on lance un process utilisant une commande 4D View => Crash du 4D Client 64 bit
  • il semble que le client 64 utilise la nouvelle couche réseau ? (ServerNet ?) alors que les autres clients 32 bit utilisent l’ancienne ? (je ne savais pas qu’on pouvait mixer les 2 :doubt:)
  • lorsqu’il revient de veille le client 64 bit prend environ 1 minute avec la roue de la mort avant de rendre la main ?!

Il est possible de choisir dans les préférences de la base si l’on souhaite ou non utiliser les nouvelles couches réseaux. Pour ce qui concerne Catalina, nous sommes encore en train de faire les adaptations nécessaires, donc prenez bien les dernières Nightly Build et surtout n’hésitez pas à remonter au support les dysfonctionnements que vous rencontrerez.

Pour ce qui est de l’appel aux plugins 32 bits, lors de mes tests j’ai bien eu pour ma part l’alerte indiquant que le code du plugin 32 bits ne pouvait pas être appelé en 64 bits, mais j’ai fait mes tests sous Windows, et en mono.

En interprété, je vous confirme qu’on a des alertes si on appelle une commande des plugins 32bit dans une base en 64bit. Mais visiblement en compilé ça crash…

Mon test a été fait sur mac (Catalina oblige :lol:) avec la dernière NB du jour v17.3 build 17.242957.

Avec un serveur Mac (en 64 bit) et un autre client 32 bit connecté en même temps.

NB: nous sommes éditeur donc c’est une application Fusionnée.

Par contre, je pense qu’il n’est pas possible de gérer correctement les updades des clients (je ne vois pas comment peut cohabiter des clients 32 et 64 dans le même serveur fusionné ?) Il faut donc déployer les clients 64 bit à la main.

Lors de la compilation, j’ai l’option de compatibilité de l’utilisation de l’ancienne couche réseau, mais lorsque j’ai le rapport de crash du client 64 bit, je vois des threads appelés ServerNet (nouvelle couche réseau ?) Et le fait qu’il puisse reprendre après une mise en veille du poste (cela n’est pas possible normalement avec l’ancienne couche ?) Bref, c’est bizarre…
Ou c’est un mode dégradé/compatible 64 bit de la nouvelle couche réseau ?