PC SOFT

PROFESSIONAL NEWSGROUPS
WINDEVWEBDEV and WINDEV Mobile

Home → WINDEV Mobile 2025 → Could not find com.zebra.windevmobiledatawedgewrapper:windevmobiledatawedgewrapper:6.7.
Could not find com.zebra.windevmobiledatawedgewrapper:windevmobiledatawedgewrapper:6.7.
Started by Yvan, Jul., 04 2025 8:30 AM - 20 replies
Registered member
213 messages
Posted on July, 04 2025 - 8:30 AM
Bonjour,

J'ai développé une application mobile pour Android depuis plusieurs années et que j'ai migrée au fil des versions de Windev.

Cette application fonctionne pour des téléphones portables sous Android mais également pour des terminaux Zebra sous Android, le soucis que je rencontre se passe dans la génération de l'application pour le PlayStore et l'échec de la localisation des librairies nécessaires pour les Zebra.

Actuellement, je suis encore en production avec Windev 2024, mais vu que cette version de windev ne cible pas l'API 35 d'Android, j'ai migré le projet en Windev 2025.

Lors de la création de l'application Android avec Windev 25 (et le gradle 8.9), je rencontre l'erreur copiée ci-dessous.
En résumé, gradle ne trouve pas les dépendances distantes, jusqu'à présent, elles étaient renseignées dans le Wizard de création comme mentionné dans l'exemple Android Zebra Scan :
// Utiliser les informations suivantes pour décrire les artifacts à intégrer:
// - DataWedgeProfileIntentsWrapper
// Groupe: com.zebra.datawedgeprofileintentswrapper
// Nom: datawedgeprofileintentswrapper
// Version: 6.7
// - WindevMobileDataWedgeWrapper
// Groupe: com.zebra.windevmobiledatawedgewrapper
// Nom: windevmobiledatawedgewrapper
// Version: 6.7


En cherchant sur le web, je constate que de nombreuses évolutions ont été faites sur le projet Github de ces librairies :
https://github.com/ltrudu/WindevMobileDataWedgeWrapper/releases

Mais rien de neuf du coté maven (je le précise pq le rapport d'erreur gradle semble indiquer qu'il recherche les sources sur maven) :
https://mvnrepository.com/artifact/com.zebra.windevmobiledatawedgewrapper

Avez-vous une idée de comment faire pour que Gradle cherche (et trouve) la bonne version de ces librairies?

Pour info j'ai tenté de modifier le n° de version de 6.7 à 14.x selon les releases présentes sur Github mais sans succès.
Et également, j'ai envoyé une RST mais j'ai reçu une réponse qui n'en était pas vraiment une ... (no comment :) )

Merci d'avance!

Message d'erreur de la génération Gradle :

Échec de la création de l'application Android

Erreur retournée :
:mapReleaseSourceSetPaths FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':mapReleaseSourceSetPaths'.
> Could not resolve all files for configuration ':releaseRuntimeClasspath'.
> Could not find com.zebra.windevmobiledatawedgewrapper:windevmobiledatawedgewrapper:6.7.
Searched in the following locations:
- https://dl.google.com/dl/android/maven2/com/zebra/windevmobiledatawedgewrapper/windevmobiledatawedgewrapper/6.7/windevmobiledatawedgewrapper-6.7.pom
- https://jcenter.bintray.com/com/zebra/windevmobiledatawedgewrapper/windevmobiledatawedgewrapper/6.7/windevmobiledatawedgewrapper-6.7.pom
- file:/C:/Mes%20Projets/[...]/Android/gen/libs/windevmobiledatawedgewrapper-6.7.jar
- file:/C:/Mes%20Projets/[...]/Android/gen/libs/windevmobiledatawedgewrapper.jar
Required by:
project :
> Could not find com.zebra.datawedgeprofileintentswrapper:datawedgeprofileintentswrapper:6.7.
Searched in the following locations:
- https://dl.google.com/dl/android/maven2/com/zebra/datawedgeprofileintentswrapper/datawedgeprofileintentswrapper/6.7/datawedgeprofileintentswrapper-6.7.pom
- https://jcenter.bintray.com/com/zebra/datawedgeprofileintentswrapper/datawedgeprofileintentswrapper/6.7/datawedgeprofileintentswrapper-6.7.pom
- file:/C:/Mes%20Projets/[...]/Android/gen/libs/datawedgeprofileintentswrapper-6.7.jar
- file:/C:/Mes%20Projets/[...]/Android/gen/libs/datawedgeprofileintentswrapper.jar
Required by:
project :

* Try:
Run with --stacktrace option to get the stack trace.
Run with --info or --debug option to get more log output.
Run with --scan to get full insights.
Get more help at https://help.gradle.org.


Deprecated Gradle features were used in this build, making it incompatible with Gradle 9.0.

You can use '--warning-mode all' to show the individual deprecation warnings and determine if they come from your own scripts or plugins.

For more on this, please refer to https://docs.gradle.org/8.9/userguide/command_line_interface.html… in the Gradle documentation.

BUILD FAILED in 35s
2 actionable tasks: 2 executed
Message modified, July, 04 2025 - 8:33 AM
Registered member
548 messages
Posted on July, 04 2025 - 9:00 AM
Registered member
3,705 messages
Posted on July, 04 2025 - 9:16 AM
Salut
Il est préférable de télécharger les dépendances pour éviter de devoir changer son code trop souvent
De plus, même avec WM 20 ou 25 ou 2024 il est possible de compiler avec l'API 35
Il suffit de modifier le manifeste avant compilation
Il y a même une page du blog ou de la FAQ qui explique comment faire (il faut que je retrouve la page)
Mais d'après le GitHub, il faut
L' API 34 (il se peut que ce n'est pas encore compatible 35)
Il te faut Gradle 7.3.3 et OpenJDK 17
Donc pour l'instant reste en wm 2024 et essaye de contacter Trudu Laurent sur LinkedIn pour lui demander
Si la version actuelle est compatible API 35.
Registered member
213 messages
Posted on July, 04 2025 - 10:12 AM
Jopab a écrit :


Merci José!
Message modified, July, 04 2025 - 10:13 AM
Registered member
213 messages
Posted on July, 04 2025 - 10:13 AM
Merci Popoy!
Registered member
213 messages
Posted on July, 04 2025 - 10:41 AM
Popoy,

J'ai tenté la solution proposée par José via la FAQ qu'il indiquait, j'ai une autre erreur Gradle ([...] Could not find method flatDir() for arguments [...], en ciblant la version 14.7 qui était une release API 35 et aussi en ciblant la version 14.9 qui est la dernière version qui serait d'après les logs un retour en API 34).

Je vais essayer ce que tu propose, mais quand tu suggères de télécharger les dépendances, ça signifie télécharger le .zip ou le tar.gz depuis github et le convertir en .jar puis l'ajouter dans le wizard à l'étape "intégration de librairies"?

J'ai cherché une FAQ sur les niveau d'API "modifiables" dans une ancienne version de Windev et je n'ai pas trouvé, si tu as la main sur de la doc ça m'intéresse ...

Merci.
Registered member
3,705 messages
Posted on July, 04 2025 - 11:31 AM
Yvan a écrit :
Popoy,

J'ai tenté la solution proposée par José via la FAQ qu'il indiquait, j'ai une autre erreur Gradle ([...] Could not find method flatDir() for arguments [...], en ciblant la version 14.7 qui était une release API 35 et aussi en ciblant la version 14.9 qui est la dernière version qui serait d'après les logs un retour en API 34).

Je vais essayer ce que tu propose, mais quand tu suggères de télécharger les dépendances, ça signifie télécharger le .zip ou le tar.gz depuis github et le convertir en .jar puis l'ajouter dans le wizard à l'étape "intégration de librairies"?

J'ai cherché une FAQ sur les niveau d'API "modifiables" dans une ancienne version de Windev et je n'ai pas trouvé, si tu as la main sur de la doc ça m'intéresse ...

Merci.

Salut,
Je suppose que le zip et tar.gz ont sûrement le même contenu
Décompresse l'un d'eux
Il doit sûrement contenir un ou plusieurs jar
Si c'est un source, il faut le compiler en jar
Avec une commande du style
javac MyJavaFile.java
Il existe aussi des compilateurs en ligne
Ensuite tu le met dans le wizard
Mais bien sûr il se peut que tu doives adapter avec de prochaines API Android
Posted on July, 07 2025 - 4:30 PM
Bonjour,

Pour compiler sur la version SaaS 2025, j'utilise les dépendances suivantes:

Groupe Nom Version
com.github.ltrudu DataWedgeIntentWrapper 14.9
com.github.ltrudu WindevMobileDataWedgeWrapper 14.9

Avec le repository suivant ajouté à la compilation:
maven { url "https://jitpack.io" }

J'ai configuré la build avec une version minimale à Android 13.

Et modifié le manifest pour ajouter la permission: com.symbol.datawedge.permission.contentprovider

Et la query: com.symbol.datawedge

Sur mon Windev 2025 SaaS, tout compile sans problème.

En cas de difficultés, n'hésitez pas à me contacter en utilisant les "Issues" sur le repository Github suivant:
https://github.com/ltrudu/WindevMobileDataWedgeWrapper

Excellente journée et "happy coding" avec Windev :)

Laurent

Yvan a écrit :
Bonjour,

J'ai développé une application mobile pour Android depuis plusieurs années et que j'ai migrée au fil des versions de Windev.

Cette application fonctionne pour des téléphones portables sous Android mais également pour des terminaux Zebra sous Android, le soucis que je rencontre se passe dans la génération de l'application pour le PlayStore et l'échec de la localisation des librairies nécessaires pour les Zebra.

Actuellement, je suis encore en production avec Windev 2024, mais vu que cette version de windev ne cible pas l'API 35 d'Android, j'ai migré le projet en Windev 2025.

Lors de la création de l'application Android avec Windev 25 (et le gradle 8.9), je rencontre l'erreur copiée ci-dessous.
En résumé, gradle ne trouve pas les dépendances distantes, jusqu'à présent, elles étaient renseignées dans le Wizard de création comme mentionné dans l'exemple Android Zebra Scan :
// Utiliser les informations suivantes pour décrire les artifacts à intégrer:
// - DataWedgeProfileIntentsWrapper
// Groupe: com.zebra.datawedgeprofileintentswrapper
// Nom: datawedgeprofileintentswrapper
// Version: 6.7
// - WindevMobileDataWedgeWrapper
// Groupe: com.zebra.windevmobiledatawedgewrapper
// Nom: windevmobiledatawedgewrapper
// Version: 6.7


En cherchant sur le web, je constate que de nombreuses évolutions ont été faites sur le projet Github de ces librairies :
https://github.com/ltrudu/WindevMobileDataWedgeWrapper/releases

Mais rien de neuf du coté maven (je le précise pq le rapport d'erreur gradle semble indiquer qu'il recherche les sources sur maven) :
https://mvnrepository.com/artifact/com.zebra.windevmobiledatawedgewrapper

Avez-vous une idée de comment faire pour que Gradle cherche (et trouve) la bonne version de ces librairies?

Pour info j'ai tenté de modifier le n° de version de 6.7 à 14.x selon les releases présentes sur Github mais sans succès.
Et également, j'ai envoyé une RST mais j'ai reçu une réponse qui n'en était pas vraiment une ... (no comment :) )

Merci d'avance!

Message d'erreur de la génération Gradle :

Échec de la création de l'application Android

Erreur retournée :
:mapReleaseSourceSetPaths FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':mapReleaseSourceSetPaths'.
Could not resolve all files for configuration ':releaseRuntimeClasspath'.
> Could not find com.zebra.windevmobiledatawedgewrapper:windevmobiledatawedgewrapper:6.7.

Searched in the following locations:
- https://dl.google.com/dl/android/maven2/com/zebra/windevmobiledatawedgewrapper/windevmobiledatawedgewrapper/6.7/windevmobiledatawedgewrapper-6.7.pom
- https://jcenter.bintray.com/com/zebra/windevmobiledatawedgewrapper/windevmobiledatawedgewrapper/6.7/windevmobiledatawedgewrapper-6.7.pom
- file:/C:/Mes%20Projets/[...]/Android/gen/libs/windevmobiledatawedgewrapper-6.7.jar
- file:/C:/Mes%20Projets/[...]/Android/gen/libs/windevmobiledatawedgewrapper.jar
Required by:
project :
> Could not find com.zebra.datawedgeprofileintentswrapper:datawedgeprofileintentswrapper:6.7.
Searched in the following locations:
- https://dl.google.com/dl/android/maven2/com/zebra/datawedgeprofileintentswrapper/datawedgeprofileintentswrapper/6.7/datawedgeprofileintentswrapper-6.7.pom
- https://jcenter.bintray.com/com/zebra/datawedgeprofileintentswrapper/datawedgeprofileintentswrapper/6.7/datawedgeprofileintentswrapper-6.7.pom
- file:/C:/Mes%20Projets/[...]/Android/gen/libs/datawedgeprofileintentswrapper-6.7.jar
- file:/C:/Mes%20Projets/[...]/Android/gen/libs/datawedgeprofileintentswrapper.jar
Required by:
project :

* Try:
Run with --stacktrace option to get the stack trace.
Run with --info or --debug option to get more log output.
Run with --scan to get full insights.
Get more help at https://help.gradle.org.

Deprecated Gradle features were used in this build, making it incompatible with Gradle 9.0.

You can use '--warning-mode all' to show the individual deprecation warnings and determine if they come from your own scripts or plugins.

For more on this, please refer to https://docs.gradle.org/8.9/userguide/command_line_interface.html… in the Gradle documentation.

BUILD FAILED in 35s
2 actionable tasks: 2 executed
Registered member
213 messages
Posted on July, 07 2025 - 4:55 PM
José,

La FAQ que tu m'as indiquée me permet bien de générer l'application sans soucis avec un niveau d'API 35 avec Windev 2025. Merci.

Cependant, je rencontre des erreurs que je ne rencontrais pas auparavant avec la version "originale" 6.7 de l'intégration.

Le composant en lui-même, d'après moi il n'a pas changé (je suis donc toujours avec le même que depuis Windev26), le commentaire en introduction de la COL_DataWedge indique toujours qu'il s'agit de la 6.7 et est simplement recompilé comme la majorité des exemples PC Soft lors d'une mise à jour de l'éditeur, à priori je ne vois aucune différence et je ne trouve aucune mise à jour du composant en dehors de ce qui est fourni via l'exemple ScannerDataWedge.

Concernant l'erreur que je rencontre, le message est ci-dessous, dans le code de fermeture de fenêtre contient ceci :
ZebraDWFacileNettoyer("FEN_Login.CB_SuccesNettoyer","FEN_Login.CB_Erreur")


La procédure local (qui est une procédure callback) FEN_Login.CB_Erreur est la suivante :
PROCÉDURE CB_Erreur(sNomDuProfil est une chaîne, sMessage est une chaîne, sErreur est une chaîne)

gclIHM.Informe(ChaîneConstruit("Erreur lors de l'initialisation du scanner %1%4%2%4%3",sNomDuProfil,sMessage,sErreur,RC))


Et le message d'erreur reçu à la fenêtre concernée est le suivant :
Message=Les paramètres d'appel du code 'cB_Erreur' sont incorrects : on attendait 3 paramètres et on en a reçu 2.
Traitement=Procédure globale ZebraDWNettoyerBroadcastReceiver
Pile WLangage=Procédure globale ZebraDWNettoyerBroadcastReceiver
Procédure globale ZebraDWFacileNettoyer
Fermeture de FEN_Login
Pile Java=fr.pcsoft.wdjava.core.erreur.WDErreurManager.a(SourceFile:5)
fr.pcsoft.wdjava.core.erreur.WDErreurManager.b(SourceFile:1)
fr.pcsoft.wdjava.core.WDCallback.execute(SourceFile:44)
fr.pcsoft.wdjava.core.WDCallback.execute(SourceFile:26)
fr.pcsoft.wdjava.core.WDCallback.execute(SourceFile:2)
fr.pcsoft.wdjava.core.application.WD
...


Ce que je ne comprend pas c'est qu'auparavant on était déjà sur 3 paramètres, et donc je ne vois pas pourquoi l'erreur indique que l'on en a reçu 2 ...

Je précise que ce plantage arrive déjà en debug ... sur un Zebra TC21.

Merci pour toute info ;)
Registered member
213 messages
Posted on July, 08 2025 - 6:09 AM
En fait si dans l'assistant de génération de l'application on indique la version 14.6 pour les 2 librairies, ça fonctionne, c'est avec la dernière version en cours (14.9) que ça ne fonctionne pas. Je vais remonter l'info au développeur des librairies Java.
Posted on July, 10 2025 - 2:51 PM
Bonjour,

Merci pour votre message.

Je viens de constater que l'erreur provient du wrapper Windev qui appelle la procédure CB_Erreur en lui passant 2 paramètres au lieu de 3.

J'ai mis à jour la librairie pour corriger cette erreur (désolé d'avoir pris autant de temps, mais j'ai du me heurter à plusieurs problèmes de compilation et de génération de la librairie sur le serveur Jitpack).

Pour y accéder, il vous suffit de mettre à jour la dépendance:
Groupe: com.github.ltrudu
Nom: WindevMobileDataWedgeWrapper
Version: 14.12

Je vais prévenir PCSoft pour qu'ils mettent à jour l'exemple afin d'intégrer ce bug fix.
Registered member
213 messages
Posted on July, 10 2025 - 3:44 PM
Laurent Trudu a écrit :
Bonjour,

Merci pour votre message.

Je viens de constater que l'erreur provient du wrapper Windev qui appelle la procédure CB_Erreur en lui passant 2 paramètres au lieu de 3.

J'ai mis à jour la librairie pour corriger cette erreur (désolé d'avoir pris autant de temps, mais j'ai du me heurter à plusieurs problèmes de compilation et de génération de la librairie sur le serveur Jitpack).

Pour y accéder, il vous suffit de mettre à jour la dépendance:
Groupe: com.github.ltrudu
Nom: WindevMobileDataWedgeWrapper
Version: 14.12

Je vais prévenir PCSoft pour qu'ils mettent à jour l'exemple afin d'intégrer ce bug fix.
Registered member
213 messages
Posted on July, 10 2025 - 3:45 PM
Merci Laurent, et merci pour la réponse précédente que je n'avais pas vue, je vais tester ça avec la version 14.12 et la mise à jour du manifeste alors.

Laurent Trudu a écrit :
Bonjour,

Merci pour votre message.

Je viens de constater que l'erreur provient du wrapper Windev qui appelle la procédure CB_Erreur en lui passant 2 paramètres au lieu de 3.

J'ai mis à jour la librairie pour corriger cette erreur (désolé d'avoir pris autant de temps, mais j'ai du me heurter à plusieurs problèmes de compilation et de génération de la librairie sur le serveur Jitpack).

Pour y accéder, il vous suffit de mettre à jour la dépendance:
Groupe: com.github.ltrudu
Nom: WindevMobileDataWedgeWrapper
Version: 14.12

Je vais prévenir PCSoft pour qu'ils mettent à jour l'exemple afin d'intégrer ce bug fix.
Posted on July, 11 2025 - 10:38 AM
Bonjour,

Note aux utilisateurs du plugin Scan Zebra.

Si vous rencontrez des problèmes, la meilleur façon pour me les remonter est:

- Ouvrir un fil sur ce forum avec la description du problème

- Ouvrir un ticket sur le GitHub de la librairie Java wrapper Windev Mobile en y incluant le lien vers le forum PCSoft : https://github.com/ltrudu/WindevMobileDataWedgeWrapper/issues

- Me prévenir sur Linked In que vous avez rencontré un problème et posté un ticket sur GitHub.

Je ne vérifie pas tous les jours ces sources, mais suffisamment pour pouvoir assurer un minimum de support rapidement sur ces composants.

Merci d'avance pour votre aide à stabiliser ces librairies :)

Bon code sur Windev Mobile et terminaux Zebra :D
Registered member
213 messages
Posted on July, 14 2025 - 10:39 AM
Bonjour Laurent,

En utilisant la dernière librairie (14.12) et la dernière mise à jour de Windev25 update3 (version clé) qui a par défaut Gradle 8.9, on arrive à créer l'application.
Par contre je rencontre une erreur à l'utilisation, cette erreur est relative avec le soucis remonté plus haut dans ce fil, càd la procédure CallBack d'erreur.
Je ne sais pas si c'est votre Work Around qui en est la cause ou le composant Windev issu de leur exemple, le soucis étant que l'exemple ne sert pas que d'exemple mais il est surtout utile pour nous développeurs WD de copier le composant de l'exemple dans nos projet et de l'utiliser en production.
Je ne sais pas non plus si on a la main pour faire la correction de notre coté, je n'ai pas l'impression vu que l'on ne "voit" dans le code du composant que le passage de la procédure callback en code Java (mais rien de visible par rapport aux paramètres de cette procédure.

private static void _DWEnregistrerCallbackDeScan(final String sCallbackHandleScan , final String sCallbackSucces, final String sCallbackError)
{
mDataWedgeWindevMobileFacade.DWEnregistrerCallbackDeScan(sCallbackHandleScan, sCallbackSucces, sCallbackError);
}


Je pense que ma seule solution en l'état est de créer l'app en pointant vers vos librairies 14.6 avec WD25 pour atteindre le niveau ad'API35, qui était mon soucis principal.
Par ailleurs, vous parlez d'une version minimale à Android 13, ce qui ne semble pas empêcher d'installer l'app avec votre librairie 14.12 sur un TC21 qui est sous Android 11 (mis à part le soucis de la callback bien sûr), vous me confirmez que ça n'empêche pas aux applications utilisant votre composant sur des versions Android antérieures à la 13 de fonctionner correctement, le matériel industriel étant remplacé moins souvent que les téléphones portables?
Merci en tous les cas pour tout le boulot déjà accompli, j'espère que l'on aura rapidement une version Java/Windev fonctionnelle pour les lecteurs de codes-barres Zebra ;)

Message=Erreur interne.
Message système=Attempt to invoke virtual method 'java.lang.String java.lang.Object.toString()' on a null object reference
Traitement=Clic sur FEN_Mouvement.ACTB_ActionBar
Pile WLangage=Clic sur FEN_Mouvement.ACTB_ActionBar
Pile Java=fr.pcsoft.wdjava.core.application.WDCollProc.a(SourceFile:49)
fr.pcsoft.wdjava.core.application.WDCollProc.appelProcedureWL(SourceFile:1)
com.justeunclic.stockiteasy.wdgen.GWDCPCOL_DataWedge$1.appelProcedureWLSSSS(GWDCPCOL_DataWedge.java:302)
com.zebra.windevmobiledatawedgewrapper.DataWedgeWindevMobileFacade.DWEffacerCallbackDeScan(DataWedgeWindevMobileFacade.java:414)
com.justeunclic.stockiteasy.wdgen.GWDCPCOL_DataWedge._DWEffacerCallbackDeScan(GWDCPCOL_DataWedge.java:434)
com.justeunclic.stockiteasy.wdgen.GWDCPCOL_DataWedge.fWD_zebraDWNettoyerBroadcastReceiver(GWDCPCOL_DataWedge.java:1925)
com.justeunclic.stockiteasy.wdgen.GWDCPCOL_DataWedge.fWD_zebraDWFacileNettoyer(GWDCPCOL_DataWedge.java:2023)
com.justeunclic.stockiteasy.wdgen.GWDFFEN_Mouvement$GWDACTB_ActionBar.clicSurBoutonGauche(GWDFFEN_Mouvement.java:12545)
fr.pcsoft.wdjava.ui.i.executerTraitement(SourceFile:422)
fr.pcsoft.wdjava.ui.actionbar.WDActionBar.executerTraitement(SourceFile:1)
fr.pcsoft.wdjava.ui.h.a(SourceFile:14)
fr.pcsoft.wdjava.ui.h.appelPCode(SourceFile:213)
fr.pcsoft.wdjava.ui.i.appelPCode(SourceFile:1)
fr.pcsoft.wdjava.ui.actionbar.WDActionBar.a(SourceFile:6)
fr.pcsoft.wdjava.ui.actionbar.WDActionBar.onSelectOption(SourceFile:5)
fr.pcsoft.wdjava.ui.champs.fenetre.WDFenetre.a(SourceFile:74)
fr.pcsoft.wdjava.ui.champs.fenetre.WDFenetre.activity_onOptionsItemSelected(SourceFile:1)
fr.pcsoft.wdjava.ui.activite.d.a(SourceFile:163)
fr.pcsoft.wdjava.ui.activite.WDActivite.onOptionsItemSelected(SourceFile:1)
android.app.Activity.onMenuItemSelected(Activity.java:4281)
androidx.activity.ComponentActivity.onMenuItemSelected(ComponentActivity.java:529)
androidx.fragment.app.FragmentActivity.onMenuItemSelected(FragmentActivity.java:352)
androidx.appcompat.app.AppCompatActivity.onMenuItemSelected(AppCompatActivity.java:269)
androidx.appcompat.view.WindowCallbackWrapper.onMenuItemSelected(WindowCallbackWrapper.java:110)
androidx.appcompat.widget.ToolbarWidgetWrapper$1.onClick(ToolbarWidgetWrapper.java:188)
android.view.View.performClick(View.java:7448)
android.view.View.performClickInternal(View.java:7425)
android.view.View.access$3600(View.java:810)
android.view.View$PerformClick.run(View.java:28309)
android.os.Handler.handleCallback(Handler.java:938)
android.os.Handler.dispatchMessage(Handler.java:99)
android.os.Looper.loop(Looper.java:223)
android.app.ActivityThread.main(ActivityThread.java:7747)
java.lang.reflect.Method.invoke(Native Method)
com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:592)
com.android.internal.os.ZygoteInit.main(ZygoteInit.java:952)
Thread=id=2
name=main
priority=5
groupName=main
Registered member
17 messages
Posted on July, 15 2025 - 12:15 PM
Bonjour,

L'erreur se produit si on essaye d'executer ZebraDWFacileNettoyer sans avoir au préalable fait de ZebraDWFacileInitialiser.
J'ai pris en compte ce cas dans la librairie.
Pouvez vous effectuer un test avec la version 14.14 et me dire si vous rencontrez toujours le problème s'il vous plait ?

--
Snr Software Sales Engineer – France
ZEBRA TECHNOLOGIES EUROPE LIMITED
www.zebra.com
Registered member
213 messages
Posted on July, 16 2025 - 11:07 AM
Bonjour Laurent,

Ca ne plante plus (à ce moment là), mais ça affiche un toast indiquant : "Erreur lors de l'initialisation du scanner ScanCallBack Erreur, pas de call back de scan enregistrée".
Ce toast provient du code que j'ai mis dans la procédure CB_Erreur, mais je ne vois pas pourquoi on passe dans la procédure alors qu'à priori il n'y a pas d'erreur, j'ai pu ouvrir la fenêtre, scanner des QR-Code avec succès, et en quittant la fenêtre et appelant ZebraDWFacileNettoyer ça appel CB_Erreur.
Et pour info, je lance bien ZebraDWFacileInitialiser en fin d'initialisation de la fenêtre.

Autre nouveau soucis de plantage immédiat, à l'appel de ZebraDWFacileInitialiser("FEN_Login.CB_Succes","FEN_Login.CB_Erreur") qui se trouve dans mon test en fermeture de la fenêtre FEN_LOGIN, j'ai le plantage suivant :

===== Erreur =====
Date et heure=16/07/2025 10:33:26
Message=La procédure 'FEN_Login.CB_Succes' est inconnue.
Pile WLangage=Initialisation de StockItEasy8Mobile
Pile Java=fr.pcsoft.wdjava.core.erreur.WDErreurManager.a(SourceFile:5)
fr.pcsoft.wdjava.core.erreur.WDErreurManager.b(SourceFile:1)
fr.pcsoft.wdjava.core.application.WDCollProc.a(SourceFile:65)
fr.pcsoft.wdjava.core.application.WDCollProc.appelProcedureWL(SourceFile:1)
com.[...].wdgen.GWDCPCOL_DataWedge$1.appelProcedureWLSS(GWDCPCOL_DataWedge.java:292)
com.zebra.windevmobiledatawedgewrapper.DataWedgeWindevMobileFacade$7.result(DataWedgeWindevMobileFacade.java:355)
com.zebra.datawedgeprofileintents.DWProfileCommandBase$dataWedgeActionResultReceiver.onReceive(DWProfileCommandBase.java:181)
android.app.LoadedApk$ReceiverDispatcher$Args.lambda$getRunnable$0$LoadedApk$ReceiverDispatcher$Args(LoadedApk.java:1580)
android.app.-$$Lambda$LoadedApk$ReceiverDispatcher$Args$_BumDX2UKsnxLVrE6UJsJZkotuA.run(Unknown Source:2)
android.os.Handler.handleCallback(Handler.java:938)
android.os.Handler.dispatchMessage(Handler.java:99)
android.os.Looper.loop(Looper.java:223)
android.os.HandlerThread.run(HandlerThread.java:67)
Thread=id=2262
name=com.[...].THREAD
priority=5
groupName=main

===== Application =====
[...]
Version du framework Android=30.0.253.0

===== Appareil =====
Modèle=TC21
Constructeur=Zebra Technologies
Marque=Zebra

===== Système =====
Numéro de version d'Android=11 (Android11)
Api Level Android=30
Mémoire de stockage interne totale=17,34 Go
Mémoire de stockage interne disponible=11,91 Go
Densité de l'écran=320
Résolution de l'écran=720x1280


J'ai testé depuis l'exemple Windev (mais qui est fort simplifié dans le sens ou la fermeture de la première fenêtre ferme le projet), du coup j'ai mis un arrêt à la fermeture de la seconde fenêtre afin de voir si la procédure callback renvoyait une erreur et c'est le cas, il s'agit de cet appel à la fermeture de fenêtre :
ZebraDWNettoyerBroadcastReceiver("FEN_Scan_Avancé.CB_NettoyerBroadcastReceiverSucces", "FEN_Scan_Avancé.CB_NettoyerBroadcastReceiverErreur")

On dirait que tous les appels aux procédures callback sont exécutés à tort ou à raison, et dans mon plantage dans FEN_LOGIN la procédure FEN_Login.CB_Succes existe belle et bien.

PS: j'ai testé à nouveau avec la 14.6 et c'est OK, en attendant, je vais utiliser cette version.

Bien sûr je reste disponible pour débuguer, on peut se connecter via Linkedin pour ne pas polluer ce fil tant qu'on n'est pas sur une version stable ;)
Registered member
17 messages
Posted on July, 21 2025 - 10:49 AM
Bonjour,
Je n'arrive pas à reproduire ce bug.
J'ai modifié le sample pour ouvrir la fenêtre Scan_Simple depuis une autre fenêtre et lorsque je ferme Scan_Simple, je n'ai pas d'erreur remontée.
J'ai modifié la fenêtre Scan_Simple en rajoutant un bouton pour exécuter plusieurs fois ZebraDWFacileNettoyer et ensuite fermer cette fenêtre et je ne rencontre pas de bugs non plus.
Pouvez vous me décrire le workflow de votre application svp ?
A savoir quand est-ce que vous faites appel à ZebraDWFacileNettoyer pour avoir le crash que vous avez sur l'erreur décrite dans l'issue que vous avez posté sur Github svp ?
Merci d'avance.

--
Snr Software Sales Engineer – France
ZEBRA TECHNOLOGIES EUROPE LIMITED
www.zebra.com
Registered member
17 messages
Posted on August, 13 2025 - 2:40 PM
Bonjour,
J'ai remplacé les remontées d'erreurs par des warnings.
En effet, le fait de demander 2 fois à des-enregistrer un Broadcast receiver lève une exception, mais quand on y réfléchit, cela ne pose pas de pb de stabilité sur l'application cliente.
Du coup, j'ai opté pour remonter cet information sous la forme d'un ajout dans le logCat Android.
En effet, le fait d'appeler une procédure Windev lors de la fermeture de la fenêtre ne m'assure pas que cette procédure est toujours instancié en mémoire, pouvant ainsi causer un bug lors de son appel.
Cette mise à jour évite ce cas.
Pourriez vous tester avec la version 14.15 s'il vous plait ?
Et me dire si votre application fonctionne correctement.
J'ai fait des essais sur ma version de l'app, et je n'ai pas rencontré de pb en fermant et reouvrant plusieurs fois la fenêtre de scan simple.

Aussi, si vous n'avez pas de beep lors des scans, j'ai constaté un erreur dans la classe CZebraDWProfilePluginScannerScanParams
Il faut mettre à null le membre m_sdecode_audio_feedback_uri à la ligne 4 de a classe CZebraDWProfilePluginScannerScanParams située dans le composant interne ScannerDataWedge.
Son initialisation devient:
m_sdecode_audio_feedback_uri est une chaîne = Null, Sérialise = "decode_audio_feedback_uri"

Si vous me confirmez que tout se passe bien de votre côté, je vais remonter toutes les modifications à PCSoft afin que le sample soit mis à jour.
Merci d'avance.

--
Snr Software Sales Engineer – France
ZEBRA TECHNOLOGIES EUROPE LIMITED
www.zebra.com
Registered member
17 messages
Posted on August, 18 2025 - 10:26 AM
Bonjour,

J'ai fait quelques modifications sur la librairie.

Suite à une remontée d'un autre problème: la méthode DWModifierLesParametresDuScanner_Java parfois remonte une erreur de paramètre inconnu.

J'avais constaté ce pb sur certaines version de l'OS Android auparavent, car certains paramètres ont changé de format.

Malheureusement je n'ai pas les resources pour tester toutes les versions et faire des cas spécifiques.

J'ai effectué des tests de performances et si l'on ne modifie que ce dont on a besoin, la méthode ZebraDWInitialiserUnProfil en mode OVERWRITE permet d'effectuer la même tache, sans les problèmes de paramètres non reconnus.

De plus elle offre plus de capacité de configuration car ne se limite pas aux paramètres du scanner.

La perte en performances est de l'ordre de 100 à 200ms pour une trentaine de paramètres modifiés (ce qui est rarement le cas).

En environnement industriel, sur l'initialisation d'une vue, ce surcoût ne sera pas pénalisant (200ms max, c'est imperceptible).

J'ai donc supprimé DWModifierLesParametresDuScanner_Java des méthodes disponibles.

J'ai mis à jour le WindevMobileDataWedgeWrapper en version 14.6, et DataWedgeIntentWrapper en version 14.10.

J'ai mis à jour le sample Zebra Android Scan, et publié sur mon Github pour que vous puissiez bénéficier plus rapidement de la dernière version du composant:
https://github.com/ltrudu/WindevMobile_Android_Zebra_Scan_Demo

Dans ce sample, vous pouvez regarder le code des boutons Mode Agressif et Mode Normal pour voir comment changer les paramètres dynamiquement à l'aide de la méthode ZebraDWInitialiserUnProfil.

J'en ai profité pour corriger un bug d'initialisation du scanner dans la classe CZebraDWProfilePluginScannerScanParams:
La méthode m_sdecode_audio_feedback_uri n'était pas initialisé à Null, entrainant ainsi la perte du beep du scanner.

J'ai aussi modifié le workflow en rajoutant une fenêtre de départ qui ouvre les fenêtres scan simple et scan avancé, ceci afin de bien valider que l'ouverture / fermeture intensive de fenêtres ne créait ni bugs, ni effets de bords.

Pourriez vous me dire si vous validez cette version svp ?

A savoir, est ce que vous ne rencontrez plus vos pb avec et si vous utilisiez DWModifierLesParametresDuScanner_Java , est ce que la modification vers ZebraDWInitialiserUnProfil vous satisfait (ça fait la même chose, mais en plus complet)

Ainsi je pourrai envoyer le lien vers le github à PCSoft pour leur demander de mettre à jour le sample directement sur leur code base.

Merci d'avance.

--
Snr Software Sales Engineer – France
ZEBRA TECHNOLOGIES EUROPE LIMITED
www.zebra.com
Registered member
17 messages
Posted on August, 20 2025 - 10:40 AM
Bonjour,

Erratum... les dernières versions sont:

WindevMobileDataWedgeWrapper : 14.16 (et non14.6)

DataWedgeIntentWrapper : 14.10

Désolé pour l'erreur.

Bon code,
Laurent Trudu

--
Snr Software Sales Engineer – France
ZEBRA TECHNOLOGIES EUROPE LIMITED
www.zebra.com