Bonjour,

Sous pp ... j'essaye de creer une fenetre externe avec WinCreateOffscreenWindow(160,160,nativeFormat,@error) (dans un appel arm lancé grace a PCENativeCall) ....

J'obtient soit une erreur ... soit ... aucun effet lorsque je fais un WinSetDrawWindow et que je dessine dedans...

Apres moult essaie ... je me demande si cette api fonctionne dans une armlet

Juste au cas où : tu as bien pensé aux conversions d'ordre des entiers, évidemment ?

Of course ...

Oui ... j'ai fait avec et sans Si je ne convertit pas j'obtient une erreur de memoire insuffisante (ce qui parait logique).

Je viens de voir que si je fais les choses differement avec un BmpCreate et un WinCreateBitmapWindows j'obtient le même résultat à savoir, je dessine toujours dans la fenetre principal ...

Dois-je aussi swapper le winHandle ... cela m'etonnerais fortement ...

Gniark gniark gniark ...

Je viens de comprendre ... ma structure est creer en 68k et le winHandle ne doit pas etre de meme taille en arm ... arf ...

J'ai testé en effectuant un WinSetDrawWindow(WinCreateOffscreenWindow(10,10,nativeFormat,@error)); et la ca passe nickel...

Reste a trouver ce qui ne vas pas dans ma structure ...

Merci Patrice

Je n'ai pourtant pas l'impression d'avoir été d'une grande utilité

Pour la question suivante : une différence d'alignement des structures ?

Bah oui ... une structure

WinHandle+UIn16+UInt16+UInt16+UInt16+UInt32

Genere un crash du palm meme si l offscreen windows est creer et utiliser en arm ...

Alors que une structure

UIn16+UInt16+UInt16+UInt16+UInt32+WinHandle ne pose aucun soucis ...

Ps la structure est creer en mémoire dans un code 68k et est exploité en partie en ARM.

Pour mes structures, je commence toujours par les variables codés en 4 octets (pointeurs, long) car ces variables doivent être alignés sur une adresse multiple de 4, puis vient le tour des variables 2 octets (word, short...) et enfin les char et autres 8 bits.

Comme un MemPtrNew t'aligne sur 4 octets, tu es toujours bien aligné, ARM ou 68k.

D'ailleurs, ARM préconise de n'utiliser que des variables 32 bits. Et c'est vrai que cela réduit ton code !!

Oui sauf qu'un WinHandle c'est un handle ... donc une variable sur 4 octets ... gniéééé

Je vais tenter que des variables 32bits tiens ...

Non, c'est un pointeur (ce qui ne change rien à sa taille).

Ah ouais
Moi qui croyais qu'il s'agissait d'un vulgaire ID 16 bits...

En cherchant un peu, je trouve:



typedef struct WindowType
#ifdef ALLOW_ACCESS_TO_INTERNALS_OF_WINDOWS // These fields will not be available in the next OS release!
{
Coord displayWidthV20; // use WinGetDisplayExtent instead
Coord displayHeightV20; // use WinGetDisplayExtent instead
void* displayAddrV20; // use the drawing functions instead
WindowFlagsType windowFlags;
RectangleType windowBounds;
AbsRectType clippingBounds;
BitmapPtr bitmapP;
FrameBitsType frameType;
DrawStateType* drawStateP; // was GraphicStatePtr
struct WindowType* nextWindow;
}
#endif
WindowType;

typedef WindowType *WinPtr;
typedef WindowType *WinHandle;

Oui bah .. c'est un pointeur spareil

Et oui c'est chainé les windows chez palm