| |
Posted on March, 18 2012 - 12:23 AM |
Je rencontre un grave dysfonctionnement avec WDM et IOS
En effet, j'ai une application qui affiche une fenetre avec une zones répétées simplement remplie par programmation avec le code suivant
Et bien si j'ouvre et que je ferme cette fenetre entre 20 et 50 fois sur mon iphone, mon application n'a plus de mémoire, ca devient noire et ca plante
La derniere MAJ de WDM ne change rien au probleme
PROCEDURE RafraichirOrdonnance()
nCpt is int
LooperDeleteAll(ZR_Ordonnance)
HExecuteQuery(REQ_Ordonnance,hQueryDefault,mob_consu_lien.NumRelation)
HReadFirst(REQ_Ordonnance)
WHILE NOT HOut(REQ_Ordonnance)
nCpt=nCpt+1
LooperAdd(ZR_Ordonnance)
IF REQ_Ordonnance.ALD=-1 THEN
ZR_Ordonnance[nCpt].INT_ALD=True
ELSE
ZR_Ordonnance[nCpt].INT_ALD=False
END
ZR_Ordonnance[nCpt].LibellePoso=REQ_Ordonnance.LibellePoso
ZR_Ordonnance[nCpt].NomBreBoite=REQ_Ordonnance.NombreBoite
ZR_Ordonnance[nCpt].NomMedic=REQ_Ordonnance.NomMedic
ZR_Ordonnance[nCpt].NumOrdonnance=REQ_Ordonnance.NumOrdonnance
HReadNext(REQ_Ordonnance)
END
ZR_Ordonnance=-1 |
| |
| |
| | | |
|
| | |
| |
Posted on March, 19 2012 - 4:57 PM |
Bonjour
D'après le code fourni, il manque le hAnnuleDeclaration, ce qui fait qur
chaque requete reste chargée en mémoire, et au bout d'un moment, crash
Cordialement
--
Fabrice Harari
Consultant WinDev, WebDev et WinDev Mobile International
Plus d'information sur http://fabriceharari.com/index_FR.html
On 17/03/2012 18:23, GUERVILLE wrote:
Je rencontre un grave dysfonctionnement avec WDM et IOS
En effet, j'ai une application qui affiche une fenetre avec une zones répétées simplement remplie par programmation avec le code suivant
Et bien si j'ouvre et que je ferme cette fenetre entre 20 et 50 fois sur mon iphone, mon application n'a plus de mémoire, ca devient noire et ca plante
La derniere MAJ de WDM ne change rien au probleme
PROCEDURE RafraichirOrdonnance()
nCpt is int
LooperDeleteAll(ZR_Ordonnance)
HExecuteQuery(REQ_Ordonnance,hQueryDefault,mob_consu_lien.NumRelation)
HReadFirst(REQ_Ordonnance)
WHILE NOT HOut(REQ_Ordonnance)
nCpt=nCpt+1
LooperAdd(ZR_Ordonnance)
IF REQ_Ordonnance.ALD=-1 THEN
ZR_Ordonnance[nCpt].INT_ALD=True
ELSE
ZR_Ordonnance[nCpt].INT_ALD=False
END
ZR_Ordonnance[nCpt].LibellePoso=REQ_Ordonnance.LibellePoso
ZR_Ordonnance[nCpt].NomBreBoite=REQ_Ordonnance.NombreBoite
ZR_Ordonnance[nCpt].NomMedic=REQ_Ordonnance.NomMedic
ZR_Ordonnance[nCpt].NumOrdonnance=REQ_Ordonnance.NumOrdonnance
HReadNext(REQ_Ordonnance)
END
ZR_Ordonnance=-1
|
| |
| |
| | | |
|
| | |
| |
Posted on March, 19 2012 - 5:25 PM |
Pourtant, je pensais que la requete etait automatiquement liberée à la fermeture de la fenetre. Ce n'est pas le cas ? |
| |
| |
| | | |
|
| | |
| |
Posted on March, 19 2012 - 10:33 PM |
Je viens de tester et le pb ne vient pas de la (de toutes facons une petite requete qui affiche 5 elements ne peu pas mettre a genoux un iphone au bout de 20 appels)
De plus ce pb ne se produit pas sur Andoid (projet identique) et uniquement sur IOS.
Il y a bien un grave pb de liberation de mémoire. De plus ca s'est accentuée avec la derniere version de WDM (avant ca arrivait apres 40 clics, maitenant c'est une dizaine)
J'attends la réponse du support technique de PC Soft
Ce que je peux apporter comme elements c'est que mes zones ré |
| |
| |
| | | |
|
| | |
| |
Posted on March, 20 2012 - 7:48 AM |
Bonjour
non, pas pour les requêtes, AFAIK. Ce ne sont pas des variables locales,
mais des sources de données, donc globale au projet.
Cordialement
--
Fabrice Harari
Consultant WinDev, WebDev et WinDev Mobile International
Plus d'information sur http://fabriceharari.com/index_FR.html
On 19/03/2012 11:25, GUERVILLE wrote:
Pourtant, je pensais que la requete etait automatiquement liberée à la fermeture de la fenetre. Ce n'est pas le cas ?
|
| |
| |
| | | |
|
| | |
| |
Posted on March, 20 2012 - 9:32 AM |
Je ne comprends pas du tout votre réponse, pouvez vous detailler plus précisement SVP. Quelles sources de données ? |
| |
| |
| | | |
|
| | |
| |
Posted on March, 20 2012 - 10:35 AM |
Comme je l'ai dis, ca ne change pas le pb, d'ailleurs je n'ai jamais rencontré de pb mémoire sous Windev normal et windev mobile pour android alors que je n'utilise jamais HannuleDeclaration qui est une fonction relativement récente si je ne me trompe pas.
Mais dans ce cas, même en mettant des HannuleDeclaration partout, ca ne change rien au pb. Je tiens a préciser que ce problème à très nettement empiré avec la dernière version de WDM. Faites des tests sur vos propres applications sous IOS en fermant et reouvrant les fenetres entre 20 et 40 fois pour voir si vous rencontrez les mêmes pb.
Je viens de même de rencontrer un nouveau pb ce matin. Cette fois en faisant cette manipulation sur une autre fenetre mon application reboote totalement apres 20 manipulations ! |
| |
| |
| | | |
|
| | |
| |
Posted on March, 20 2012 - 5:43 PM |
Bonjour
hAnnuleDeclaration n'est pas récente. Elle a été fournie exactement en
même temps que hExecuteRequete. Elle est obligatoire après chaque
exécution de requete si on ne veut pas avoir une fuite de mémoire. La
taille de la fuite dépend bien sur de la requête faite.
Le fait qu'il y ait un autre problème avec IOS est tout à fait possible,
la version WM pour IOS est encore TRES jeune, trop jeune pour que je
passe du temps dessus pour l'instant, sauf obligé.
Le mieux est bien sur de fournir un exemple de projet qui démontre le
problème au support technique
Cordialement
--
Fabrice Harari
Consultant WinDev, WebDev et WinDev Mobile International
Plus d'information sur http://fabriceharari.com/index_FR.html
On 20/03/2012 04:35, GUERVILLE wrote:
Comme je l'ai dis, ca ne change pas le pb, d'ailleurs je n'ai jamais rencontré de pb mémoire sous Windev normal et windev mobile pour android alors que je n'utilise jamais HannuleDeclaration qui est une fonction relativement récente si je ne me trompe pas.
Mais dans ce cas, même en mettant des HannuleDeclaration partout, ca ne change rien au pb. Je tiens a préciser que ce problème à très nettement empiré avec la dernière version de WDM. Faites des tests sur vos propres applications sous IOS en fermant et reouvrant les fenetres entre 20 et 40 fois pour voir si vous rencontrez les mêmes pb.
Je viens de même de rencontrer un nouveau pb ce matin. Cette fois en faisant cette manipulation sur une autre fenetre mon application reboote totalement apres 20 manipulations !
|
| |
| |
| | | |
|
| | |
| |
Posted on March, 21 2012 - 1:22 PM |
Je viens de reproduire le même problème avec l'exemple de PCSoft "IOS note de frais".
Il suffit de l'installer sur l'iPhone et de le tester en cas réel (pas en émulation)
-> Ensuite vous allez dans l'écran qui permet de créer une "nouvelle note de frais"
-> Vous cliquez sur le bouton "+"
Dans la fenêtre suivante nommée “Collaborateur” vous cliquez simplement sur le bouton “Retour”
Vous retombez donc sur la fenetre précédente
-> Vous re-cliquez sur le bouton "+"
Dans la fenêtre suivante nommée “Collaborateur” vous cliquez simplement sur le bouton “Retour”
Faites ca une centaine de fois. Votre iPhone va planter
J'ai déterminé d'après mes nombreux tests, que les fenêtres contenants des zones répétées ne sont pas correctement libérées et provoquent une saturation de la mémoire de l'iphone.
Je suis quasiment certain que le pb se produit uniquement si la fenêtre contient une zone répétée |
| |
| |
| | | |
|
| | |
| |
Registered member
203 messages
Popularité : +3 (3 votes) |
|
Posted on March, 21 2012 - 5:52 PM |
Bonjour,
Envoyez le protocole de reproduction au Support Technique avec l'outil Requête au Support Technique. Si ça se trouve vous recevrez un patch ou une DLL Windev d'ici 1 à 2 jours.
Cordialement,
Alex |
| |
| |
| | | |
|
| | |
| |
Posted on March, 21 2012 - 6:04 PM |
| |
| |
| | | |
|
| | |
| |
Posted on January, 12 2013 - 10:37 AM |
Bonjour,
Je rencontre le même problème. Avez-vous pu le résoudre ?
Merci d'avance |
| |
| |
| | | |
|
| | |
| |
Posted on January, 16 2013 - 6:25 PM |
Bonsoir,
j'ai le même type de problème avec des fenêtres internes et la gestion de fenêtre internes par défilement par gesture.
Cela alloue de la mémoire qui n'est jamais libérée.
C'est en cours au Support Technique. |
| |
| |
| | | |
|
| | |
| |
Posted on March, 05 2013 - 3:17 PM |
J'ai exactement le même problème
Après plusieurs (ré)affichage de la fenêtre contenant des listes, un écran noir ....
Si quelqu'un a une solution, je suis preneur
Merci d'avance
Toph |
| |
| |
| | | |
|
| | |
| |
Posted on March, 06 2013 - 10:55 AM |
Développer directement avec X Code ? D'autant que la dernière version d'IOS a considérablement simplifié la gestion de la mémoire avec l'introduction de l'ARC. |
| |
| |
| | | |
|
| | |
| |
Registered member
141 messages |
|
Posted on March, 06 2013 - 11:35 AM |
Ce problème court depuis quelques mois. J'ai eut le service technique au téléphone hier et pour réponse j'ai eut : "Ha oui nous ne vous avons pas répondu. Je relance les développeurs.". Je penses que l'on peut encore attendre pour avoir une réponse. En attendant ceux qui ont une solutions ou une idée d'où proviendrait le problème.
J'ai déjà résolu une partie du problème beaucoup de champs n'était pas libérée à la fermeture d'une fenêtre internes. |
| |
| |
| | | |
|
| | |
| |
Posted on March, 06 2013 - 12:45 PM |
Bonjour à tous,
j'ai aussi relancé le service tech et commerciale pour que ça avance un peu.
Speak34, concernant le dealloc de champs, tu utilises le code que tu as déjà posté et tu passes Handle(LeChamp) c'est ça ?
#import <UIKit/UIKit.h>
void IOS_Dealloc(void* currentView)
{
UIView *tmpView = (UIView*)currentView;
//NSLog (@"Tentative de release du champs");
[tmpView release];
}
1. J'utilise déjà ton code sur les FI, mais dans une fenêtre interne avec gesture défilement au doigt sur plusieurs pages ça ne marche pas, ils doivent allouer différemment. Si jamais tu as une solution je suis preneur ?
2. Quelles sont les autres champs concernés, utilises-tu la même fonction ?
bonne journée
guy |
| |
| |
| | | |
|
| | |
| |
Posted on March, 06 2013 - 12:51 PM |
Bonjour,
J'ai sensiblement le même problème sous Android, qui génère une erreur WDJava.java.lang.OutOfMemoryError lors d'un OuvreFille après plusieurs ouvertures / fermetures de fenêtres fille.
Comment faites-vous pour forcer la libération de la mémoire sous iOS / Android?
Manifestement les HAnnuleDéclaration ne suffisent pas à résoudre le problème |
| |
| |
| | | |
|
| | |
| |
Registered member
141 messages |
|
Posted on March, 06 2013 - 6:59 PM |
En fait la grande blague de WM18 c'est les subviews. Alors j'ai taper un fonction récursives qui ressemble a peu de chose près à la tienne, GuyD.
UIView * myView = (UIView *)CurrentField;
for (UIView * subView IN [myView subviews])
{
IOS_Dealloc(subView);
}
[myView removeFromSuperview];
Après le problème c'est qu'il reste deux trois trucs à nettoyer que je ne trouve pas et qui me font casser le crane.
Bref, je suis toujours à la recherche d'idée. |
| |
| |
| | | |
|
| | |
| |
Registered member
141 messages |
|
Posted on March, 07 2013 - 12:22 PM |
Mais d'ailleurs même avec ce code il reste des choses à supprimer. Vu que ça me gonfle sévèrement de ne pouvoir développer une application stable et sans fuite de mémoire, j'espère que cela va vous aider et que nous trouverons une solution.
Donc, comme j'expliquais sur mon précédent message que WM18 géraient ses fenêtre en créant en objective C beaucoup de subviews. Mais quand nous fermons la fenêtre tout n'est pas déallouer (et si c'est une fenêtre interne, rien du tout). D'où ma fonction récursive donnait juste dessus (faîte toujours attention aux modification de casses du forum  ).
Mais il suffit juste d'un tour sur Instruments pour se rendre compte que la mémoire continu à monter malgré la déallocation "à la main" que nous faisons (d'ailleurs pour le fun, si vous commentez ou ne mettez pas le code que je vous ai donnée, vous verrez la mémoire monté en fèche). Quid du problème : Quel(s) est/sont le(s) élément(s) qui ne sont pas libérées ? En fait une partie de la réponse est encore plus tordu que ce que je pensais. Les zones répétées (qui sont quand même une des bases de l'iOS) et les variables tableaux / structures. En effet si jamais vous supprimer toutes les données de vos zones répétées et de vos tableaux mémoire à la fermeture de la fenêtre vous verrez que vous gagnerez encore un peu d'espace.
Mais toujours en passant par Instruments, vous constaterez que nous avons encore et toujours une partie de la mémoire qui n'est pas libéré.... J'ai déjà fait une recherche et ait listé une série de classes, quelques-unes sont des classes Cocoa comme UIView, UIWebView, UIImageView...etc... qui sont toutes des classes héritée de UIView et qui seront nettoyer par mon code. Mais il y à ça : CIOSDispatchGeneric et CIOSDispatcheScrollGeneric qui sont là dans 70/80% des classes d'une fenêtre et qui ne sont pas des classes Cocoa. Je fais une recherche sur les forum ObjC et iOS, aucun retour. Je soupçonne donc que ces classes soient en fait des classes WM18 compilé dans leurs librairies et que ce sont elles qui ne sont pas libérée car nous n'avons pas la main dessus.
Alors aujourd'hui, je bloque sur ce dernier problème, j'avoue que c'est rageant d'être à 2 mètres du pot de Pringles et de ne pouvoir y accéder. Je suis de ce fait preneur de toute idées. |
| |
| |
| | | |
|
| | |
| |
Posted on March, 07 2013 - 2:41 PM |
Bonjour,
Je n'ai pas eu le temps de tester le code suivant, mais combiné avec la méthode de Spek et avec la fonction EnumereChamp, il est peut être possible d'arriver à un résultat correct :
Daniel DUCTEIL a écrit dans le message de news <dba324de286dd4b5c361ef2880547b99@news.pcsoft> :
Voici un code que j'utilise afin de 'libérer' des champs de la mémoire. C'est une idée, je ne suis pas vraiment alaise dans xCode pour faire plus. (Pas testé avec iOS 6) void IOS_Dealloc(void* CurrentField)
{
[CurrentField release];
} Je l'appel comme ceci : Procedure LibererChamps(sLeNomDuChamps = est une chaîne "")
SI EnModeSimulateur() ALORS
SINON
SI ChampExiste(sLeNomDuChamps) ALORS
IOS_TraceDebug("Champs à libérer "+sLeNomDuChamps)
IOS_Dealloc(Handle(sLeNomDuChamps))
FIN
FIN |
| |
| |
| | | |
|
| | |
| |
Posted on March, 07 2013 - 3:55 PM |
C'est du mimétisme ce bug. Pas de garbage collector ou d'ARC. On est revenu 2 ans en arrière quand la gestion de la mémoire avec IOS était manuelle. |
| |
| |
| | | |
|
| | |
| |
Registered member
141 messages |
|
Posted on March, 07 2013 - 4:20 PM |
C'est vrai que l'idée de nettoyer champs à champs peut être sympa.
Je vais voir du code en partant de là. |
| |
| |
| | | |
|
| | |
| |
Registered member
141 messages |
|
Posted on March, 07 2013 - 5:06 PM |
Et oui... Je sais que c'est triste mais comment faire... J'ai bien essayé de modifier le projet compilé par WM18 en ARC mais non. Tu ne peux pas. |
| |
| |
| | | |
|
| | |
| |
Registered member
141 messages |
|
Posted on March, 08 2013 - 4:57 PM |
Et bé .... Hier j'ai reçu un mail de la part de PCSoft. Ils ont corrigé semble-t-il le problème. Bon il faut être sous WM18 46j et demandé le correctif correspondant au ticket : 78 223. Mais sur une première vérification cela semble correcte. Donc soyons optimiste et espérons qu'une analyse plus poussé permettra de valider cela. |
| |
| |
| | | |
|
| | |
| |
Posted on March, 11 2013 - 9:44 AM |
Tu nous tiendras au courant stp ? En attendant, j'ai mis en oeuvre la technique décrite ci-dessus.
Merci |
| |
| |
| | | |
|
| | |
| |
Registered member
141 messages |
|
Posted on March, 11 2013 - 11:42 AM |
Ben après des tests et un passage sur Instruments. Mes fenêtre internes ne sont plus "mémoirovore". Elle se dé-alloue sans problème. Au début je ne voyais que la moitié en mémoire libéré, mais après tests il semblerait que cela soit du cache gardé par l'iPad / iPhone Car en effet je la ré-ouvre et elle ne monte que de moitié. Donc cela à l'air sai. |
| |
| |
| | | |
|
| | |
| |
Posted on March, 14 2013 - 7:37 AM |
Bonsoir à tous,
j'ai aussi reçu un correctif. Je n'ai pas encore fait de test sur les FI on mode gesture défilement, mais en mode normal avec une FI défini dans l'éditeur ça n'a pas l'air de marcher.
en revanche j'ai trouvé une solution sans IOS_desalloc. Dans le code de fermeture de la fenêtre contenant la FI j'ai mis
ChangeFenêtreSource(MA_FI,"")
et dans instrument on voit que l'on libère bien la mémoire.
En revanche
1. si le FI contient un "modèle de champ" ça ne libère pas le "modele de champ" et dans cas je fais
SI EnModeSimulateuriOS = Faux ALORS
IOS_Dealloc(Handle(MA_FI.CMOD_Note))
FIN
ChangeFenêtreSource(MA_FI,"")
2. s'il y a un Graph, tout n'est pas libéré et je n'ai pas de solution  une idée ? (j'ai essayé le IOS_dealloc standard et récursif mais rien n'y fait, bug que j'avais déjà signalé en 17).
Voilà, en espérant apporter ma pierre
Bonne nuit |
| |
| |
| | | |
|
| | |
| |
Posted on March, 14 2013 - 10:58 AM |
Le correctif de PCSoft ne fonctionne pas ? C'est ça ? |
| |
| |
| | | |
|
| | |
| |
Registered member
141 messages |
|
Posted on March, 14 2013 - 11:26 AM |
Et oui c'est justement le correctif qui te permet de faire un ChangeFenetreSource(MA_FI,"") et de libérer la mémoire. Sinon (et pour mettre peter le crane sur ma table je peux le dire) que cela ne fonctionner pas. |
| |
| |
| | | |
|
| | |
| |
Registered member
141 messages |
|
Posted on March, 14 2013 - 1:26 PM |
Ben si le correctif te permet que lorsque tu fais ChangeFenêtreSource(MA_FI,"") te vider ta mémoire de ta FI. |
| |
| |
| | | |
|
| | |
| |
Posted on March, 15 2013 - 11:33 AM |
Bonjour Alexandre, j'ai exactement le même soucis avec Android,après plusieurs ouvre fille j'ai également une erreur WDJava.java.lang.OutOfMemoryErro.
Pourtant il n'y a aucune requête dans les fenêtres ce sont des formulaires.
Avez-vous déjà remonté l'info au st?
Cdlt
Fred |
| |
| |
| | | |
|
| | |
| |
Posted on March, 15 2013 - 12:39 PM |
Bonjour Fred,
Oui j'ai remonté l'information au service technique avec un petit projet. Ils ne constatent pas le problème sur tablette android alors que çà le fait sur galaxy s3.
J'ai trouvé que le bug ne se produit plus lorsque j'enlève les images de fond étirées de mes fenêtres (même si l'image de fond ne fait que 13ko...). J'ai remonté l'information au service technique, j'attends leur réponse.
J'espère que cela pourra vous aider. Bonne journée |
| |
| |
| | | |
|
| | |
| |
Posted on March, 15 2013 - 5:30 PM |
Bonjour,
Pour vous consoler, vous n'êtes pas seuls dans votre malheur.
Je travaille sur un programme sous Android (Galaxy Tab 2) qui manipule des dessins/images.
Il est très sensible et provoque (trop) facilement des erreurs "WDJava.java.lang.OutOfMemoryError"
avec plus de 200Mo de mémoire libre.
Je n'ai pas encore réussi à isoler une fonction (de type dessin, dcopie, drotation, …) qui pose problème (probablement une combinaison)
Bon courage. |
| |
| |
| | | |
|
| | |
| |
Posted on March, 15 2013 - 6:18 PM |
Pour moi les champs image sont à 100%
---------------------------------------------------
Alexandre Dumontier a écrit dans le message de news <cb6a0e27dd5bb17adbd643a4c45c0a5f@news.pcsoft> :
Lire la suite »
Bonjour Fred,
Oui j'ai remonté l'information au service technique avec un petit projet. Ils ne constatent pas le problème sur tablette android alors que çà le fait sur galaxy s3.
J'ai trouvé que le bug ne se produit plus lorsque j'enlève les images de fond étirées de mes fenêtres (même si l'image de fond ne fait que 13ko...). J'ai remonté l'information au service technique, j'attends leur réponse.
J'espère que cela pourra vous aider. Bonne journée
Question tout con mais as tu essayé de laisser ton image en 100% et sans étirement juste pour tester ? |
| |
| |
| | | |
|
| | |
| |
Registered member
141 messages |
|
Posted on March, 15 2013 - 6:59 PM |
Alexandre Dumontier a écrit dans le message de news <cb6a0e27dd5bb17adbd643a4c45c0a5f@news.pcsoft> :
Bonjour Fred,
Oui j'ai remonté l'information au service technique avec un petit projet. Ils ne constatent pas le problème sur tablette android alors que çà le fait sur galaxy s3.
J'ai trouvé que le bug ne se produit plus lorsque j'enlève les images de fond étirées de mes fenêtres (même si l'image de fond ne fait que 13ko...). J'ai remonté l'information au service technique, j'attends leur réponse.
J'espère que cela pourra vous aider. Bonne journée
Question tout con mais as tu essayé de laisser ton image en 100% et sans étirement juste pour tester ? |
| |
| |
| | | |
|
| | |
| |
Posted on March, 15 2013 - 7:12 PM |
Bonjour, pour ma part les images ne sont pas étirées et font chacune moins de 10ko=> 50ko par fenêtre. |
| |
| |
| | | |
|
| | |
| |
Posted on March, 16 2013 - 12:31 AM |
Je confirme que c'est bien le fond image d'une fenêtre qu'elle soit étiré ou non qui provoque une erreur.J'ai fait le test en mode homothétique et en 100% => ça plante. |
| |
| |
| | | |
|
| | |
| |
Posted on March, 18 2013 - 10:39 AM |
Bonjour,
Non je n'ai pas eu le temps de tester l'application devant être mise sur google play dans les plus brefs délais. Toutefois je fais confiance à Fred et Gérard qui affirment que çà le fait également à 100%. J'attends toujours une réponse du service technique à ce sujet, cette erreur n'a pas l'air d'être encore enregistrée chez eux.
Bonne journée
Spek34 a écrit dans le message de news <96fb223b913cf1034fcc3c8015ad2416@news.pcsoft> :
Alexandre Dumontier a écrit dans le message de news <cb6a0e27dd5bb17adbd643a4c45c0a5f@news.pcsoft> : Bonjour Fred,
Oui j'ai remonté l'information au service technique avec un petit projet. Ils ne constatent pas le problème sur tablette android alors que çà le fait sur galaxy s3.
J'ai trouvé que le bug ne se produit plus lorsque j'enlève les images de fond étirées de mes fenêtres (même si l'image de fond ne fait que 13ko...). J'ai remonté l'information au service technique, j'attends leur réponse.
J'espère que cela pourra vous aider. Bonne journée
Question tout con mais as tu essayé de laisser ton image en 100% et sans étirement juste pour tester ? |
| |
| |
| | | |
|
| | |
| |
Registered member
141 messages |
|
Posted on March, 18 2013 - 11:27 AM |
C'est un fond de fenêtre ou un champs image que vous mettez en fond ? J'ai eut de grave problème de mémoire sur iPad aussi lorsque j'utilisé l'image en fond direct de la fenêtre. |
| |
| |
| | | |
|
| | |
| |
Posted on March, 18 2013 - 4:01 PM |
Bonjour Alexandre,
si c'est vraiment urgent, je te conseille de mettre ton appli IOS sur
l'apple store plutot que sur google play... Tu risques d'avoir un
meilleur retour 
Cordialement
--
Fabrice Harari
Consultant WinDev, WebDev et WinDev Mobile International
Plus d'information sur http://fabriceharari.com/index_FR.html
On 3/18/2013 4:39 AM, Alexandre Dumontier wrote:
Bonjour, Non je n'ai pas eu le temps de tester l'application devant être mise sur google play dans les plus brefs délais. Toutefois je fais confiance à Fred et Gérard qui affirment que çà le fait également à 100%. J'attends toujours une réponse du service technique à ce sujet, cette erreur n'a pas l'air d'être encore enregistrée chez eux. Bonne journée Spek34 a écrit dans le message de news <96fb223b913cf1034fcc3c8015ad2416@news.pcsoft> : Alexandre Dumontier a écrit dans le message de news <cb6a0e27dd5bb17adbd643a4c45c0a5f@news.pcsoft> : Bonjour Fred,
Oui j'ai remonté l'information au service technique avec un petit projet. Ils ne constatent pas le problème sur tablette android alors que çà le fait sur galaxy s3.
J'ai trouvé que le bug ne se produit plus lorsque j'enlève les images de fond étirées de mes fenêtres (même si l'image de fond ne fait que 13ko...). J'ai remonté l'information au service technique, j'attends leur réponse.
J'espère que cela pourra vous aider. Bonne journée
Question tout con mais as tu essayé de laisser ton image en 100% et sans étirement juste pour tester ? |
| |
| |
| | | |
|
| | |
| |
Posted on March, 18 2013 - 4:04 PM |
Tu as raison Spek34, si j'utilise une image comme fond de fenêtre le problème disparaît et il réapparaît aussitôt si j'intègre le fond dans la fenêtre. |
| |
| |
| | | |
|
| | |
| |
Posted on March, 18 2013 - 6:12 PM |
Merci du conseil, mais la discussion a un peu dévié, et si j'envoie mon archive APK sur l'apple store, il y en a à qui ça risque de ne pas plaire
Fabrice Harari a écrit dans le message de news <514706b5$1@news.pcsoft.fr> :
Bonjour Alexandre, si c'est vraiment urgent, je te conseille de mettre ton appli IOS sur l'apple store plutot que sur google play... Tu risques d'avoir un meilleur retour Cordialement -- Fabrice Harari Consultant WinDev, WebDev et WinDev Mobile International Plus d'information sur http://fabriceharari.com/index_FR.htmlOn 3/18/2013 4:39 AM, Alexandre Dumontier wrote: Bonjour, Non je n'ai pas eu le temps de tester l'application devant être mise sur google play dans les plus brefs délais. Toutefois je fais confiance à Fred et Gérard qui affirment que çà le fait également à 100%. J'attends toujours une réponse du service technique à ce sujet, cette erreur n'a pas l'air d'être encore enregistrée chez eux. Bonne journée Spek34 a écrit dans le message de news <96fb223b913cf1034fcc3c8015ad2416@news.pcsoft> : Alexandre Dumontier a écrit dans le message de news <cb6a0e27dd5bb17adbd643a4c45c0a5f@news.pcsoft> : Bonjour Fred,
Oui j'ai remonté l'information au service technique avec un petit projet. Ils ne constatent pas le problème sur tablette android alors que çà le fait sur galaxy s3.
J'ai trouvé que le bug ne se produit plus lorsque j'enlève les images de fond étirées de mes fenêtres (même si l'image de fond ne fait que 13ko...). J'ai remonté l'information au service technique, j'attends leur réponse.
J'espère que cela pourra vous aider. Bonne journée
Question tout con mais as tu essayé de laisser ton image en 100% et sans étirement juste pour tester ? |
| |
| |
| | | |
|
| | |
| |
Registered member
141 messages |
|
Posted on March, 18 2013 - 6:23 PM |
De rien |
| |
| |
| | | |
|
| | |
| |
Posted on March, 19 2013 - 7:06 PM |
Le support technique aurait besoin d'un mini projet de moins de 1000 lignes de codes pour constater le problème et enregistrer un incident pour le bug de l'image de fond sous android.
Le souci c'est qu'en faisant un mini projet je n'arrive pas à reproduire le bug. Est-ce que par hasard vos projets feraient moins de 1000 lignes de code? Fred, Spek? Gérard?
fred a écrit dans le message de news <d279e73b92903612c6888e123727b32a@news.pcsoft> :
> Tu as raison Spek34, si j'utilise une image comme fond de fenêtre le problème disparaît et il réapparaît aussitôt si j'intègre le fond dans la fenêtre. |
| |
| |
| | | |
|
| | |
| |
Posted on March, 20 2013 - 12:30 PM |
Idem mon projet fait plus de 4000 lignes, j'ai essayer de recréer un projet test avec seulement 5 boutons et 5 fenêtres avec fond et la ça marche sans problème. |
| |
| |
| | | |
|
| | |
| |
Posted on March, 20 2013 - 2:37 PM |
Bonjour,
J'ai finalement réussi à reproduire le bug dans un mini projet avec une navigation entre 3 fenêtres, avec un modèle de fenêtre qui a une image de fond étirée.
Apparemment c'est à cause de l'image faite avec photoshop que le bug se produit, car quand je mets une image du catalogue, il ne se produit pas. Dans la description de l'image qui fait planter, la résolution est indiquée (96ppp)et l'image de fond est plus grande que la fenêtre pour s'afficher correctement sur tablette. C'est peut être çà le souci.
J'ai envoyé ce mini projet en demandant à pcsoft si une image de fond doit avoir des propriétés particulières pour ne pas avoir ce bug mémoire sous android. Je vous tiens au courant si j'ai une réponse exploitable. |
| |
| |
| | | |
|
| | |
| |
Posted on October, 23 2013 - 10:17 AM |
Bonjour à tous,
J'ai essayé vos solutions mais je rencontre toujours des problèmes.
Je vois que le sujet date du début de l'année. Je voudrais savoir si depuis, vous avez trouvé une solution pour réssoudre le problème mémoire.
Cordialement,
Fed1023 |
| |
| |
| | | |
|
| | |
| |
Posted on October, 23 2013 - 11:16 AM |
Bonjour,
Pour ma part le bug mémoire lié à l'image de fond de fenêtre a été résolu en version 56d de WINDEV Mobile 18. |
| |
| |
| | | |
|
| | |
| |
Registered member
141 messages |
|
Posted on October, 24 2013 - 11:55 AM |
Dans ce sujet, nous avons parlé de beaucoup de problèmes. Aux quels fais-tu référence ? |
| |
| |
| | | |
|
| | |
| |
Registered member
141 messages |
|
Posted on October, 24 2013 - 5:09 PM |
Bonjour à tous,
En relisant ce post j'ai pris un peu des bonnes idées de chacun à savoir :
La procédure IOS_Dealloc
L'énumération des champs pour le release (j'ai d'ailleurs également effectué un release de la fenêtre elle même, je ne suis pas sûr que ça change quelque chose)
Le passage des images en mode 100% (à ce sujet, je me suis dit que je pouvais probablement utiliser les vignettes générées dans la table mais visiblement j'ai du manquer un épisode car il m'affiche uniquement une portion de mon image alors que la taille de mon image est bien égale à la taille de la vignette... Si quelqu'un à une idée)
Je dois dire que le résultat est un peu meilleur en terme de stabilité en tout cas je n'ai plus les Leaks que j'avais auparavant.
Par contre, en utilisant Instruments je m'aperçois que la mémoire occupée par l'app grossit mais qu'elle ne redescend quasiment jamais ou très peu. En rechargeant les fenêtres le total occupé gonfle inexorablement ce qui implique que l'app plante au bout d'un moment ....
Il y a effectivement un autre problème de release que je n'arrive pas à comprendre.
Je suis toujours à l’affût des bonnes idées pour contourner ces problèmes.
Merci !
Sylvain |
| |
| |
| | | |
|
| | |
| |
Registered member
141 messages |
|
Posted on October, 25 2013 - 2:26 PM |
Haaaaa merci je ne suis pas le seul. Depuis le correctif récent pour iOS 7 j'ai plein de problème de mémoire que je n'avais pas avant. D'après le support je suis le seul à avoir ce genre de problème ( ).
Je suis en train de chercher des solutions l'une d'entre elles et de vider les zone répétées en quittant la fenêtre. |
| |
| |
| | | |
|
| | |
| |
Posted on October, 25 2013 - 3:08 PM |
Bonjour,
J'ai peut être une piste si vous pensez que le problème de mémoire vient de la zone répétée. Regardez s'il y a du code à l'affichage d'une ligne de la zone répétée. Apparemment selon la LST 94, "ce traitement pénalise la fluidité des applications sur les terminaux mobiles" , et il faut déplacer le code de ce traitement dans le code d'initialisation. |
| |
| |
| | | |
|
| | |
| |
Registered member
141 messages |
|
Posted on October, 25 2013 - 3:20 PM |
Merci Alexandre. Mais non ce n'est pas ça. Sylvain je te conseil d'éviter de laisser ton mail. Mais en effet je vais te contacter. |
| |
| |
| | | |
|
| | |