Bonjour à tous.
J'ai plusieurs questions pour vous :

-->J'ai fait une toute petite appli :grin: utilisant des images avec HB++ qui fonctionne à merveille sur mon clié TJ25 (OS5 + Ecran couleur high res). Lorsque je beam cette appli sur un simple Zire (OS4 + Ecran NB), l'appli provoque une erreur car l'image est en niveau de gris... Comment faire pour que l'image utilisée s'adapte à la config de la machine ?

--> Sous HB++ la taille du Form est de 160x160, comment profiter du 320x320, et est_il possible de rendre les appli compatibles avec 160x160 ??

--> La taille de ma toute petite application est assez conséquente (30ko compilé en mode Release) je trouve que c bcp par rapport à ses focntionnalité (affichage de 2 petites images). HB++ ne peut il pas faire mieux ??

Merci pour vas réponse

A part sélectionner quelle image (couleur, N&B) beamer, je ne vois pas comme ton TJ25 pourrait savoir à qui il beame. Sauf si tu implémentes ça toi-même et beame toute la famille (donc l'image en plusieurs résolutions et profondeurs de couleur).


C'est possible, sans rien faire. Même en double densité, HB++ travaille dans un système de coordonnées 160x160. Je te conseille vivement la lecture de la section "Home > Programmer's Guide > More About Programming > Adding Program Functionality > Graphics" de l'aide de HB++ qui explique tout ça très bien.


HB++ inclut un certain nombre de fonctions de base, ce qui fait qu'il y a toujours une taille minimum. C'est un petit inconvénient à subir quand on voit tout ce qui est fourni automatiquement par ce "runtime" (mot mal employé vu que HB++ crée du code compilé, mais j'ai pas trouvé mieux ). Si tu préfères minimiser la taille de ton programme, il faut le faire en C.

Même pour les APIs spécifiques Sony (si c'est bien ce qui est utilisé pour le TJ25) ? Parce que ces APIs ne gèrent pas les "bitmap families", il faut ajouter du code (avec les fonctions HR sony) pour afficher dans la bonne résolution.


C'est le prix à payer pour ce genre d'outils

Aucune idée, je pense que HB++ (via le runtime) gère la Hires indifféremment à la mode Palm et Sony. Et le TJ25 utilise les APIs Palm, si je ne m'abuse. Mais attendons une réponse de jpa ou de Poolpy .

Je me permettais d'exprimer un doute car l'utilisation d'un bitmap HR sur Sony requiert une action explicite et (surtout) requiert une ressource bitmap HR au "format" standard (et non en "famille")...

Donc pour que HB++ fasse le boulot tout seul, cela supposerait qu'il convertisse automatiquement les bitmaps HD en version HR Sony et code les affichages à l'ouverture de chaque form... C'est possible, mais j'ai un doute

Ceci dit la première question à se poser par rapport à ces considérations est : le TJ25 est-il en HD (PalmSource) ou en HR (Sony) ?

Cela signifie t'il que dans les ressources du programme je dois inclure l'image en plusieurs résolutions / profondeur de couleur, et que celle qui sera utilisée depend de la machine ??

Sur les 30 Ko, il faudrait commencer par voir quelle est la proportion prise par tes 2 images. Ensuite, on pourra savoir, par différence, ce qui est pris par le code HB++.

Et je ne suis pas certain du tout que, pour un tout petit programme, il y ait beaucoup de Ko à gagner à le faire en C ou un autre compilateur "bas niveau" comme HSPascal ou PP par exemple, versus le compilateur "haut niveau" qu'est HB++.

Pour ma part, je préfère ces notions de "bas et haut niveaux" à la notion de "runtime" évoqué plus haut pour qualifier HB++ :-?
Par contre, iziBasic est aussi un compilo de type "runtime" lui

En tous cas, c'est comme ça que fonctionne le système. Si tu veux faire autrement, c'est à toi de le coder entièrement