Mon application marche à merveille, sauf sur le palm m515 ? Pourquoi ?
J'ai pour mes test un :
Tungsten T2
Zire
m515
IIIc
SA marche partout sauf sur le m515 qui possède la version 4.1P pour les applications.
Pourquoi ?
En gros c'est lorsque je saisie le text d'un txtfield et que celui ci est à blanc, il me le donne comme s'il était trop gros...
fldPtr = FrmGetObjectPtr(form, FrmGetObjectIndex(form, calTxtAssVie));
dtemp = atof(FldGetTextPtr(fldPtr));
if (dtemp >0 )
{
...
}
mais il est toujours plus grand que zéro sur le m515 et = 0 sur les autres.. Pourquoi ?
de plus je trouve pas de ROM pour imuler et debugger le m515
merci à vous !
Version complète : m515
CITATION(Philippe_Dsf)
de plus je trouve pas de ROM pour imuler et debugger le m515
merci à vous !
merci à vous !
Même sur le site de palmos ?
Bizarre :
http://www.palmos.com/dev/dl/dl_tools/dl_emulator/_wc_roms.html ://http://www.palmos.com/dev/dl/dl_too.../_wc_roms.html
Tu trouves des ROMS pour la version 4.1
Je te conseille les roms de débug, c'est plus pratique, elles font plus de controles...
CITATION(Philippe_Dsf)
fldPtr = FrmGetObjectPtr(form, FrmGetObjectIndex(form, calTxtAssVie));
dtemp = atof(FldGetTextPtr(fldPtr));
if (dtemp >0 )
{
...
}
mais il est toujours plus grand que zéro sur le m515 et = 0 sur les autres.. Pourquoi ?
dtemp = atof(FldGetTextPtr(fldPtr));
if (dtemp >0 )
{
...
}
mais il est toujours plus grand que zéro sur le m515 et = 0 sur les autres.. Pourquoi ?
Là, tu fais un test sur le pointeur.
Je pense que les versions 5 de PALMOS te retournent un pointeur NULL quand il n'y aucun texte, mais j'en suis pas sur.
La rom 4.1 est de la rom 4.0 je n'ai pas retrouver celle que je veux... c'est poche.. j'ai écrit à palm et j'attends.. mais pendant ce temps je cherche à voir quoi je pourrais trouver.
Ce qui me fourre c'Est que sur le Tunsten 4.5 et le Zire 4.0 sa marche mais pas pour le 4.1 et sur le IIIc 3.5 sa fonctionne aussi.. Il y aurai une différence sur le retour pour le 4.1 !??!?!
ma checker voir si je compare
if ( dtemp > 0 ou dtemp == NULL )
(peux-tu faire ça moi ??ou ma checker mon NULL sur mon FldGetText
Ce qui me fourre c'Est que sur le Tunsten 4.5 et le Zire 4.0 sa marche mais pas pour le 4.1 et sur le IIIc 3.5 sa fonctionne aussi.. Il y aurai une différence sur le retour pour le 4.1 !??!?!
ma checker voir si je compare
if ( dtemp > 0 ou dtemp == NULL )
(peux-tu faire ça moi ??ou ma checker mon NULL sur mon FldGetText
CITATION(oupsman)
Là, tu fais un test sur le pointeur.
atof() renvoit un float pas un pointeur !
Je n'ai pas d'idée sur le problème, ceci dit. Mais fait un test sur > 0.1 pour voir si ce ne serait pas un bug d'"arrondi"...
Au fait, il est déclaré comment dtemp ?
On peu pas faire non plus FlpAToF sa marche pas pantoute s'te fonction là .. ma essayé 0.1
si je met 0 dans mes champs sa marche. .mais c'Est bIZZZ
si je met 0 dans mes champs sa marche. .mais c'Est bIZZZ
CITATION(Patrice)
atof() renvoit un float pas un pointeur !
Je n'ai pas d'idée sur le problème, ceci dit. Mais fait un test sur > 0.1 pour voir si ce ne serait pas un bug d'"arrondi"...
Au fait, il est déclaré comment dtemp ?
J'ai répondu trop vite !
BTW, j'ai noté un problème à un moment : PalmOS renvoie parfois un caractère parasite à la place d'un champ vide. je crois d'ailleurs que le problème se pose pas sur PalmOS 5.
La valeur de dtemp est aléatoire ou c'est toujours la même ?
D'ailleurs atoi est une fonction de la libc non ?
Il est plus sur je pense de développer sa propre fonction. D'ailleurs, il me semble que l'utilisation de fonctions de la librairie standard C n'est pas bonne pour la taille du .prc. Qui confirme ?
Il est assez simple de trouver une fonction équivalente sur le net :
Cette fonction est tirée du source de DiveLog
http://aquapalm.sourceforge.net/source_htm..._8c-source.html
Il est plus sur je pense de développer sa propre fonction. D'ailleurs, il me semble que l'utilisation de fonctions de la librairie standard C n'est pas bonne pour la taille du .prc. Qui confirme ?
Il est assez simple de trouver une fonction équivalente sur le net :
CODE
Int32 StrToFloat(char *tmp_str, int frac)
{
int i;
int neg;
char *cP,period;
char *str;
Int32 ipart,fpart,mult;
Int32 rslt;
str=tmp_str;
switch (PrefGetPreference(prefNumberFormat))
{
case nfCommaPeriod:
case nfApostrophePeriod:
period='.';
break;
default:
period=',';
}
while( (*str == ' ') || (*str == 't') ) /* trim whitespace */
++str;
if( *str == '-' ) /* check for neg. */
{
neg = 1;
++str;
}
else
{
neg = 0;
if( *str == '+' ) /* drop any sign */
++str;
}
ipart = StrAToI(str); /* get integer part */
mult=1;
for (i=0;i<frac;i++)
mult*=10;
ipart*=mult;
if( (cP = StrChr(str,period)) )
{
i=StrLen(cP)-1; cP++;
fpart = StrAToI(cP); /* and frac part */
while( i > 0 ) /* scale as needed */
{
if (mult>1)
{
mult/=10;
}
else
{
mult=1;
fpart/=10;
}
i--;
}
rslt=ipart+fpart*mult;
}
else
rslt=ipart;
return( neg?-rslt:rslt );
}
{
int i;
int neg;
char *cP,period;
char *str;
Int32 ipart,fpart,mult;
Int32 rslt;
str=tmp_str;
switch (PrefGetPreference(prefNumberFormat))
{
case nfCommaPeriod:
case nfApostrophePeriod:
period='.';
break;
default:
period=',';
}
while( (*str == ' ') || (*str == 't') ) /* trim whitespace */
++str;
if( *str == '-' ) /* check for neg. */
{
neg = 1;
++str;
}
else
{
neg = 0;
if( *str == '+' ) /* drop any sign */
++str;
}
ipart = StrAToI(str); /* get integer part */
mult=1;
for (i=0;i<frac;i++)
mult*=10;
ipart*=mult;
if( (cP = StrChr(str,period)) )
{
i=StrLen(cP)-1; cP++;
fpart = StrAToI(cP); /* and frac part */
while( i > 0 ) /* scale as needed */
{
if (mult>1)
{
mult/=10;
}
else
{
mult=1;
fpart/=10;
}
i--;
}
rslt=ipart+fpart*mult;
}
else
rslt=ipart;
return( neg?-rslt:rslt );
}
Cette fonction est tirée du source de DiveLog
http://aquapalm.sourceforge.net/source_htm..._8c-source.html
CITATION(oupsman)
Il est plus sur je pense de développer sa propre fonction. D'ailleurs, il me semble que l'utilisation de fonctions de la librairie standard C n'est pas bonne pour la taille du .prc. Qui confirme ?
Je ne confirme pas parce que la fonction est absente de ma version du SDK ! En tous cas, il vaut certainement mieux utiliser une fonction de la libc que d'écrire la sienne !!! Tu peux aussi entièrement réécrire les librairies, une fois que tu commences...
En l'occurence, la solution recommandée sur d'utiliser le FloatManager et la fonction FlpAToF(). Et elle fonctionne !
Et Macflyincaster, tu t'écartes du sujet. D'autant plus que ta fonction n'est pas utilisable dans tous les cas...
Finalement je me suis mis un alerte pour m'afficher le resutlat de mon atof et voilà le résultat
tungsten T2 = 0.00
m515 = 4294912857.00
Voilà comment ce convertis le txtField à blanc sur le palm m515 avec l'OS. 4.1P
Alors ma contrer mon problème en vérifiant si le resulat > 0 et < 1000 ( mon domaine de valeur possible )
tungsten T2 = 0.00
m515 = 4294912857.00
Voilà comment ce convertis le txtField à blanc sur le palm m515 avec l'OS. 4.1P
Alors ma contrer mon problème en vérifiant si le resulat > 0 et < 1000 ( mon domaine de valeur possible )
Ce que tu devrais plutôt faire (en y réfléchissant un peu plus sérieusement), ce serait :
Ce qui pourra éventuellement t'éviter des crash sévères...
CODE
pFldTxt = FldGetTextPtr(fldPtr);
if (pFldTxt != NULL)
{
dtemp = atof(pFldTxt);
if (dtemp >0 )
{
...
if (pFldTxt != NULL)
{
dtemp = atof(pFldTxt);
if (dtemp >0 )
{
...
Ce qui pourra éventuellement t'éviter des crash sévères...
CITATION(Patrice)
Je ne confirme pas parce que la fonction est absente de ma version du SDK ! En tous cas, il vaut certainement mieux utiliser une fonction de la libc que d'écrire la sienne !!! Tu peux aussi entièrement réécrire les librairies, une fois que tu commences...
Ouais mais linker la libc juste pour une fonction, c'est un peu dommage......
Enfin, cet avis n'engage que moi.
Le link est quand même suffisamment intelligent pour n'inclure que la ou les fonctions utilisées dans la librairie !!! Tu n'embarques pas toute la librairie parce que tu utilises une de ses fonctions, ce serait la fin du monde 
Bon, faut que je revoie mes sources alors. Ou alors, c'était les anciennes versions des compilo car il me semble avoir lu qu'il fallait éviter au maximum les fonctions de la libc sous peine de linker la libc en entier. Et dire que je me suis fait ch.er à reprogrammer deux-trois fonctions de la libc pour LPS :x
|[img]style_emoticons/default/anim_mur.gif[/img] |[img]style_emoticons/default/anim_mur.gif[/img] |[img]style_emoticons/default/anim_mur.gif[/img] |[img]style_emoticons/default/anim_mur.gif[/img] |[img]style_emoticons/default/anim_mur.gif[/img] |[img]style_emoticons/default/anim_mur.gif[/img]
|[img]style_emoticons/default/anim_mur.gif[/img] |[img]style_emoticons/default/anim_mur.gif[/img] |[img]style_emoticons/default/anim_mur.gif[/img] |[img]style_emoticons/default/anim_mur.gif[/img] |[img]style_emoticons/default/anim_mur.gif[/img] |[img]style_emoticons/default/anim_mur.gif[/img]
Finalement je regarde si mon ptr est null sinon.. je fait ma conversion et sa marche TEMPÊTE !
Merci Patrice...
Si tu veux voir un peu quoi ça l'air à ce jour.. encore 2-3 bugs
Merci Patrice...
Si tu veux voir un peu quoi ça l'air à ce jour.. encore 2-3 bugs
J'en profite pour m'excuser de t'avoir un peu laissé tomber la dernière fois ... Mais je ne suis jamais arriver à compiler tes sources avec les prc-tools (tu utilises des librairies, dont la libc, que je n'ai pas) et je suis un peu serré sur mes plannings en ce moment...
Oupsman, il est effectivement déconseillé d'utiliser la libc mais à ma connaissance, c'est parce qu'elle reproduit du code existant en ROM sous un nom différent (exemple sprintf() -> StrPrintF()), ce qui alourdit donc bien les programmes.
Ceci dit, je peux bien sur me tromper sur mon affirmation, en particulier sur la libc que je n'utilise pas. Mais je suis 100% certain pour d'autres lib (comme les GlueXXXX, que j'utilise, elles), donc le linker a un minimum d'intelligence.
... Mais je ne suis jamais arriver à compiler tes sources avec les prc-tools (tu utilises des librairies, dont la libc, que je n'ai pas) et je suis un peu serré sur mes plannings en ce moment...
Oupsman, il est effectivement déconseillé d'utiliser la libc mais à ma connaissance, c'est parce qu'elle reproduit du code existant en ROM sous un nom différent (exemple sprintf() -> StrPrintF()), ce qui alourdit donc bien les programmes.
Ceci dit, je peux bien sur me tromper sur mon affirmation, en particulier sur la libc que je n'utilise pas. Mais je suis 100% certain pour d'autres lib (comme les GlueXXXX, que j'utilise, elles), donc le linker a un minimum d'intelligence.
Ceci est une version "bas débit" de notre forum. Pour voir la version complète avec plus d'information, la mise en page et les images, veuillez cliquer ici.