Reprise du message précédent :

 
ça, ça peut être n'importe kel handle vers un élément graph'.. heu... vers n'importe kel "window" ?
par exemple, s'il me vient l'idée folle d'afficher des pixels dans mon radio button, c'est possible en passant le handle vers ce radio button ? où s'agit-t-il uniquement du handle vers la fenêtre (au sens visuel du terme, pas au sens API cette fois) parente ?
 
 
 
ou comment pouvoir dire un jour : "bonjour, je suis trilingue, je parle le français, l'anglais et le microsoft... les microsoftiens sont des gens venus d'une autre planéte... leur but est d'écraser le monde... mais je me suis soumis un jour à apprendre leur langage... je n'avais pas le choix... on m'a forcé.

[jfdsdjhfuetppo]--Message édité par Moustaaki le 23-05-2002 à 11:35:38--[/jfdsdjhfuetppo]

Moustaaki a écrit a écrit : ouai, fin ça, c valable parce ke c'est du "procédural"... c'est po de l'objet... mon bureau windows pourrait être un élément graphique particulier tout comme une fenêtre... chacun ayant une méthode repaint redéfini et spécifique... enfin, cela est peut-être conçu de cette manière avec les MFC ?

windows c'est "procédural" car ça a commencé il y a 20 ans et ça a eu le mérite de rester compatible avec les vieilles apps. donc oui, l'applic peut paraître monolithique ... mais tu as par ex un fonctionnement objet pour les windowprocs.  
 
et oui, les mfc encapsulent tout ça.

Avec C++Builder et Delphi y a toujours ce truc procédural, mais encapsulé.
La seule partie procédurale visible c'est le .dpr dans Delphi et le .cpp du nom de ton projet dans C++Builder.
Le Application.Run() correspond à la fonction qui fait la boucle de messages.

Moustaaki a écrit a écrit : merci en tout cas à tous ceux ki m'ont aidé dans ce topic avec une spéciale dédicace (cacedédi, ouai ! ) à HelloWord

ouais, ben g compris quoi ! ma solution était toute pourrie    
enfin bon, au moins tu sauras ce qu'est le VBL, j'aurais pas tout perdu  

Harkonnen a écrit a écrit :   ouais, ben g compris quoi ! ma solution était toute pourrie     enfin bon, au moins tu sauras ce qu'est le VBL, j'aurais pas tout perdu

 
mais non, tout le monde a fait avancer le shmililiblick ici et c'est bien cool

 
   ouai, et ça me plait bien comme ça  
ce ke je veux dire, c ke la programmation objet me parait bp plus abordable et intuitive.
et puis, on ne citera plus les nombreux avantages de la poo (prononcez pou):
modularité, extensibilité, réutilisabilité, etc...
 
et bien sûr ke l'objet encapsule du procédural mais au final, on obtient une approche complétement différente de la programmation (que je préfère pour ma part).

[jfdsdjhfuetppo]--Message édité par Moustaaki le 23-05-2002 à 11:42:57--[/jfdsdjhfuetppo]

alors, aidez moi à parler le langage microsoft, svp... j'ai kelkes points flous à éclaircir :
 
déjà au niveau de hDC ou des hWnd :
 
hWnd : handle d'une fenêtre or comme tout est fenêtre ça peut être le handle de n'importe koi ?
 
hDC," Handle to the device context. "  ... clairement, c koi ?

bin ça y est on arrivé à bout...
 
chaque "fenêtre" à un hWnd, un bouton c'est une fenêtre, tout est fenêtre car la fenêtre est la primitive de base pour les serveurs graphiques.
 
donc en passant un hWnd de bouton à une fonction de traçage, oui ça traçera dans un bouton.....
 
le device context est une structure qui maintient des infos sur un périphérique ou tu peux dessinner (fenêtre, imprimante...)
(là c'est un handle, donc un entier ou un pointeur qui pointe sur le device context dans une table, enfin ça tu l'as compris)

vu que chaque controle est une fenêtre, tout controle possède un hWnd

le hDC te permet de récupérer le contexte d'un périphérique. dans ton cas, ce hDC te permet de récupérer la zone de l'écran ou tu pourras dessiner
pour faire une comparaison, ta fenêtre est une feuille de papier, et le hDC est un coté de cette feuille ou tu pourras dessiner (comparaison à la con, mais j'ai pas trouvé mieux )

Harkonnen a écrit a écrit : [quote] le hDC te permet de récupérer le contexte d'un périphérique. dans ton cas, ce hDC te permet de récupérer la zone de l'écran ou tu pourras dessiner pour faire une comparaison, ta fenêtre est une feuille de papier, et le hDC est un coté de cette feuille ou tu pourras dessiner (comparaison à la con, mais j'ai pas trouvé mieux )

 
ok..
delphi propose une méthode pour tous ces composants graphiques : Handle ki renvoie un handle... (exemple TPaintBox.Handle.. eu.. c pa un méthode statique par contre )
 
est-ce que je peux utiliser cet handle comme hDC ?

Je dirais plutôt TPaintBox.Canvas.Handle :

 
Sinon y a aussi TPaintBox.GetDeviceContext qui est peut-être plus adapté :

[jfdsdjhfuetppo]--Message édité par antp le 23-05-2002 à 12:51:48--[/jfdsdjhfuetppo]

Moustaaki a écrit a écrit :     ok.. delphi propose une méthode pour tous ces composants graphiques : Handle ki renvoie un handle... (exemple TPaintBox.Handle.. eu.. c pa un méthode statique par contre )   est-ce que je peux utiliser cet handle comme hDC ?

 
 
bon, je répond à ma question, corrigez moi si je me trompe :
je ne peux pas utiliser cet handle comme hDC, en fait, ça n'a rien à voir...
 
en fait, ce kil faut que je fasse, c'est utiliser la méthode getDC(handleDuPaintBox) pour obtenir un hDC correspondant au paintBox...
ensuite à partir de ce hDC, je pourrais construire un bitMap 'compatible' createCompatibleBitmap... etc...
 
bon, j'ai bien compris ?

 
 
ooo, génial !!! aaa, c puissant delphi
merci antp !

est-ce que l'un de vous peut m'expliquer ces 4 lignes de code ?
 

 
 
 
de plus, il y a un truc que je ne comprend pas bien dans delphi avec les handles... déjà handle ne représente pas hWND mais HDC...
ensuite, getDeviceContext demande un handle HWND... mais comment associer un HDC à la propriété handle d'un paint box si on ne connait pas le handle de celui ci ?
dans l'exemple, il font :
 

 
je ne comprend pas bien... j'ai l'impression kon affecte un DC complétement bidon...
   
parceque dans le code C, on fait :  

aisni, on ne récupère pas le DC à partir de n'importe koi ! on le récupère à partir du handle identifiant la "fenêtre" (au sens api du terme)... alors....

[jfdsdjhfuetppo]--Message édité par Moustaaki le 23-05-2002 à 13:50:52--[/jfdsdjhfuetppo]

TWinControl.Handle -> hWnd
TCanvas.Handle -> HDC
 
TPaintBox est un TWinControl.
TPaintBox.Canvas est un TCanvas.
 
Et tu devrais faire paintBox1.canvas.Handle := paintBox1.getDeviceContext(notUsed);
 
Sinon ton device context est pour la form (self) et non pas pour la paintbox...

 
ok, je v tester tout ça alors
encore merci
euh, non, une autre kestion pour ke ça soit encore plus klerr :
 
mais pourkoi on ne fait pas :
paintBox1.canvas.handle := getDeviceContext(paintBox1.handle);
=> heu, la propriété handle n'est pas accessible en fait
 
 
 
et puis, je viens de tester :
PaintBox1.Canvas.Handle := PaintBox1.getDeviceContext(notUsed);
 
et ça me retourne l'erreur à la compile :
[Erreur] main.pas(33): Identificateur non déclaré : 'getDeviceContext'

[jfdsdjhfuetppo]--Message édité par Moustaaki le 23-05-2002 à 14:52:07--[/jfdsdjhfuetppo]

 
 
en fait, TPaintBox n'est hélas pas un TWinControl... et il ne dispose ni de la propriété Handle ni de la méthode getDeviceContext(handle: HWND);
 
bon, j'v voir ce ke je peux faire
 
en faisant une classe descendante de TCustomControl ki elle même descend de TWinControl, ça doit être faisable... ?

[jfdsdjhfuetppo]--Message édité par Moustaaki le 23-05-2002 à 14:58:03--[/jfdsdjhfuetppo]

arf... utilise un TPanel alors
Mais c'est moins prévu pour

[jfdsdjhfuetppo]--Message édité par antp le 23-05-2002 à 14:59:14--[/jfdsdjhfuetppo]

antp a écrit a écrit : arf... utilise un TPanel alors Mais c'est moins prévu pour

 
ouai, c vrai ke ça fait un peu crado ...
keske tu penses de l'utilisation de TCustomControl... apparement, il n'y que la méthode paint à redéfinir... et c ce ki correspond à la réponse WM_PAINT dans la windowProc...  
il faudrai donc ke je code l'ékivalent de cela :

 
keske t'en penses ?

Ouais c'est peut-être mieux...

o my god. (BoolayAttitude := true)
 
bon, encore un pb... mes neuronnes correspondants au lexique de la programmation se sont déconnectés et je ne sais plus ce ke veut dire cette erreur :
 
[Erreur] affichage.pas(22): Les types des paramètres VAR originaux et formels doivent être identiques
 
à l'appel de la function BeginPaint dans la méthode suivante :

 
 
 
prototype de la fonction paint :
function Windows.BeginPaint(hwnd: HWND; var lpPaint: tagPAINTSTRUCT): HDC;
 
si je remplace le type de ps par tagPAINTSTRUCT, on obtient la même erreur.

[jfdsdjhfuetppo]--Message édité par Moustaaki le 23-05-2002 à 15:31:21--[/jfdsdjhfuetppo]

Houlà les messages d'erreur en français, ça fait tout bizarre
 
essaie de créer soit une variable LPPAINTSTRUCT (si ça existe) qui contient l'adresse de l'autre truc:
 
ptr: LPPAINTSTRUCT;
 
ptr := @ps
 
ou alors:
 
ptr: PPAINTSTRUCT;
 
Et si ça existe pas ajoute
 
type
  PPAINTSTRUCT = ^PAINTSTRUCT;

[jfdsdjhfuetppo]--Message édité par antp le 23-05-2002 à 15:36:06--[/jfdsdjhfuetppo]

antp a écrit a écrit : Houlà les messages d'erreur en français, ça fait tout bizarre

 
ouai , j'ai tout en français, même la doc et c'est kan même plus pratique

CRAQUAGE
 
bon, dans windows.pas, on a ça :

 
 
et je fais ça :

 
 
toujours la même erreur de compil.

Essaie de mettre le handle dans un hwnd

PTDR
 
procedure TSpectrumControl.Paint;
var
   ptr_ps: tagPAINTSTRUCT;
 l_hdc: HDC;
begin
   l_hdc := BeginPaint(self.Handle, tagPAINTSTRUCT(ptr_ps));
   PaintWindow(l_hdc);
   EndPaint(self.Handle, ptr_ps);
end;
 
 
 
ok ok... ça marche ... 'fin ça compile en tout cas
 
j'm'attend à de belles erreurs d'executions mais bon, on verra bien

[jfdsdjhfuetppo]--Message édité par Moustaaki le 23-05-2002 à 15:44:19--[/jfdsdjhfuetppo]

Ouais faut voir si ça marche, parce que tu donnes pas de pointeur là il me semble...

 
par dèf, tagPAINTSTRUCT n'est pas un pointeur en effet
mais il rale dès ke j'essaye de lui donner à manger un pointeur !!! keske je peux y faire ???
 
 
et d'ailleurs :
function Windows.BeginPaint(hwnd: HWND; var lpPaint: tagPAINTSTRUCT): HDC;
 
il ne demande pas un pointeur en fait, non ? sinon, ça serait :
function Windows.BeginPaint(hwnd: HWND; var lpPaint: PPAINTSTRUCT): HDC;
 
 
 
bon bin on va voir ce ke ça donne

[jfdsdjhfuetppo]--Message édité par Moustaaki le 23-05-2002 à 15:57:25--[/jfdsdjhfuetppo]

est ce ke c'est le mot clé "var" ki va faire ke le passage de paramètre va se faire par référence et non par valeur par hazard ? ce ki expliquerais pouquoi on a pas besoin de passer un pointeur ??

Ha oui vu comme ça...  
Mais c'est parce que moi je n'ai pas trouvé autre chose que la définition "C" de la fonction, où il fallait un pointeur de PAINTSTRUCT.
Vu que la il veut un var tag machin c'est bon comme tu l'as mis.

oki

   
AHAHAHAH, je suis mort de rire !!!
 
bon, je me suis carrément planté dans la traduction C => pascal et le résultat est assez... comment dirais-je ... jugez par vous-même :
 
compilation -> Ok
 
lancement du programme -> rien ne se passe alors kun retangle tout noir devrai apparaitre...  
 
je passe une autre appli en premier plan puis je reviens à mon appli et là, c'est siouper : mon appli se mêt à afficher toutes les fenêtres des applis en train de tourner une à une, en boucle... impossible de l'arreter... Ctrl+Sup n'y fait rien
jai réinventé le Alt+Tab perpétuel ki se fini par un bô débordement de pile
bon, je crois ke je vais utiliser le prog k'HelloWorld m'a filé tel kil est en le convertissant en DLL ...alalalalalal... c'est terrible, la programmation bas niveau mais kan tu fais nimp', ça FAIT nimp'
 
 voulez ke je vous pose le code ou un lien vers l'exe pour rigoler un peu ?

[jfdsdjhfuetppo]--Message édité par Moustaaki le 23-05-2002 à 17:14:50--[/jfdsdjhfuetppo]

ouais envoie toujours

antp a écrit a écrit : ouais envoie toujours

 
je mêt le code, hein, pas l'exe ... mais t'arriveras facilement à le recréer avec delphi...
 
 
j'ai d'abord défini un objet TSpectrumControl de la façon suivante (comprenez de façon totalement freestyle) :
 
[booleyCode]

[/booleyCode]
 
 
 
 
ensuite j'ai créé une fenêtre pour utiliser/tester cet objet :
 

 
 
 
 
donc, je l'ai relancé pour voir si ça refaisais la même chose et j'ai regardé de plus près ce kil faisait :
le lancement du programme provoque une énorme montée en charge du CPU ki passe à 100% d'utilisation et n'en redescend plus .
au bout d'une minute, en forçant un peu le passage d'une appli à l'autre, on finit par avoir le résultat décrit plus haut

[jfdsdjhfuetppo]--Message édité par Moustaaki le 23-05-2002 à 17:37:14--[/jfdsdjhfuetppo]

merde, j'ai oublié d'appeller ma méthode initSurface !!!!

Moustaaki a écrit a écrit : merde, j'ai oublié d'appeller ma méthode initSurface !!!!

 
 
oui, bon, ça fait pareil -> montée en charge du processeur, rien ne s'affiche (à part la fenêtre) et j'ai arrété avant ke tout plante grâce aux gestionnaires de tâches (merci win2000 )
 
 
 
 
 
je viens de supprimer la méthode init... à la place, j'ai rajouté à la fin du constructeur :
 
TForm(AOwner).insertControl(self);
puis le code ki est dans initSurface;
 
 
voilà... j'avais pas pensé à faire ça... 'fin, c'est p'têtre pas conseillé encore

[jfdsdjhfuetppo]--Message édité par Moustaaki le 23-05-2002 à 17:48:23--[/jfdsdjhfuetppo]

Au sujet des handle ...
Un handle c'est un peut comme un pointeur : ca permet de désigner un objet (géré par Windows) sauf que c?une sorte de numéro unique qui identifie un objet et pas son adresse. Ce n'est pas l'objet lui même (qui est ainsi protégé car uniquement modifié par Windows via des fonctions qui utilisent cet handle pouridentifier l'objet à modifier).
hWnd : c'est un handle (le h du debut ...) de fenetre (Wnd).
hDC : c'est un handle de device context (DC).
 
Ce sont des handle sur des objets fenetre et contexte de périphérique.
 
A quoi sert un device context ?
Prenons le cas de SetPixel : il doit savoir où se trouve la fenêtre, ses dimensions, si elle est en partie cachée par une autre afin de déterminer où afficher un point sur l'écran et si effectivement cela doit être fait.
De même une fonction dessin de texte, elle doit savoir tout ca mais en plus savoir quelle police utiliser pour dessiner le texte ...
Et il en est ainsi pour toutes les fonctions de dessin sur une fenêtre.
Alors 2 possibilité : soit une fenêtre contient en plus des nombreux champs qu'elle possède tous ces champs en plus, soit on créé une variable qui contient tout ça et on l?associe a la fenêtre.
La dexieme solution à savoir un type Device Context au lieu d'un mega type Fenetre qui contiendrait tout a pas mal d'avantage ... une fenetre peut ainsi partager son DC avec une autre, le type fenetre est moins volumineux : mine de rien, un DC ca fait ... 800 octets !!!. Car une fenetre est beaucoup plus d'un rectangle a l'ecran. Je dirait que c'est plutot le DC qui sert de primitive pour les serveurs graphiques.
 
Une fenetre Windows est un véritable objet, capable de polymorphisme, d'héritage et même de plus (super-classing = héritage multiple ?), qui peut servir a autre chose qu'a dessiner un rectangle à l'écran : dialoguer avec d'autres applications via des messages, encapsuler des données, ... on fait de la véritable programmation objet avec des données privées gérées en interne par la fenêtre et mises à disposition d'autres objets (autres fenetres) via des méthodes (implémentées sous forme de messages ...)
Ainsi WM_CREATE et WM_DESTROY sont ... des constructeurs et destructeurs ! ! !
C'est pour cela que l'architecture Win32 se prête si bien à la programmation objet. Et ce n'est pas parce qu'on programme en C que ce n'est pas de l'objet. Faire de l'objet en C est possible (exemple : gtk !) mais c'est plus fastidieux qu'en C++ car le langage ne met pas à ta disposition tout un tas d'artifices (constructeurs appelés automatiquement, mon_type.ma_fonction(), membres prives/public ...) qui facilitent et sécurisent le boulot.
 
Pour en revenir au DC, MS a donc préféré mettre à disposition des programmes une petite pile de DC que le programmeur est libre de se gérer.
Quand tu fait GetDC(), tu utilises un des DC disponibles sur la pile, tu l'utilises, et quand tu n'en n'a plus besoin, tu le libère via ReleaseDC(). Ainsi, un programme fonctionne avec très peu de DC (je crois qu'au lancement Windows te met 5 DC de dispo sur la pile). Même si ton programme possède 100 fenêtre, tu n'utilise que quelques DC (imagine le gain en mémoire : 100 DC de 800 octets, c'est pas négligeable ! Surtout du temps de Windows 3.1 ou un PC avait quelques mega de mémoire. Toute économie était bonne à prendre)
L'inconvénient avec ceci c'est qu'a chaque allocation de DC, celui-ci est vierge. Donc tu passes pas mal de temps a chaque fois a te le mettre comme il faut (choisir la police, la couleur, ...) et tu payes en temps d'exécution l?économie mémoire (ce qui est souvent le cas).
Aujourd'hui, 800 octets par fenêtre c'est négligeable. Car il n'y a pas tant de fenêtre que cela à l'écran (une fenêtre ToolBar (barre d'outils ) est intelligente : elle ne fait pas un CreateWindow pour chaque bouton de sa barre d'outils, mais effectue un simple dessin de boutons ... et hop une dizaine de fenetres économisées ... et tous les composants de Windows sont ainsi bien optimisés).
Alors MS recommande de plutôt utiliser un DC pour chaque fenêtre qui ne sera jamais libéré. On perd 800 octets par fenêtre mais on gagne des dizaines d'appels aux fonctions GDI. Ceci est fait à l'aide du style CS_OWNDC et c'est pour cela que je récupère mon DC au démarrage et que je le libère (c'est obligatoire ca ?) a la fin. Avec CS_OWNDC, ma fenêtre se voit attribuer un DC indépendamment de la pile de DC de mon programme. Y'a pas à le libérer car de toutes façons il est réservé uniquement pour ma fenêtre.
 
Un mot sur ma notation :
g_hWinDC : le "g_" c'est pour "global" a savoir variable globale. T'as pas a garder ca !
 
Au fait, un blit, c'est tout simplement une recopie
 

Pas besoin de g_Rect: TRect;, tu as déjà TWinControl::ClientRect !!!
C'est le même ... remplace g_Rect par Clientrect.
De même _hWinDC: HDC;, c'est ... la propiété TWinControl::Handle !!!
_hBitmap est un handle tout court (HANDLE), pas un handle sur fenetre (HWND) ...
Du coup ca change :

A moins que ca aille dans initSurface mais je crois pas (a quoi sert ce dernier ?) Je dirais même que ça doit aller dans TWinControl::CreateWnd ...
 

idem, TWinControl::DestroyWnd me semble meilleur ...
Je pense que TWinControl::PaintWindow est parfaitement indiqué au lieu de paint qui ne sert à rien  ... en plus pas besoin de BeginPaint ni de EndPaint ... ceci est déjà fait par Delphi qui te file gracieusement le DC en paramètre ... plus que pas besoin, c'est une erreur ...
Au passage, tu as oublié le blit ... c'est là qu'il faut afficher l'image ... p_hdc, c'est quoi ce p_ ?

 
Voila en gros le truc. Ton principal problème c'est que tu penses qu'il y a Delphi d'une cote et Win32 de l'autre ... Delphi est une surcouche de Win32 qui le simplifie ...
Aussi, certaines parties de code sont déjà faites et tu dois tout simplement les éliminer, car c'est Delphi qui s'en charge.
La fenêtre dans laquelle je dessinais est ici ton composant Spectrum. Toutes les proprietes Rect, Handle, DC de ce composant sont gérées par Delphi. Tu les utilises tout bêtement et directement.
Les seuls et uniques ajouts sont un bitmap en mémoire : h_Bitmap et un contexte de périph pour ce bitmap : _hBMPDC.
L'equivalent de WM_CREATE et WM_DESTROY en Delphi sont TWinControl::CreateWnd et TWinControl::DestroyWnd si je ne m'abuse (j'ai l'aide VCL de C++Builder sous les yeux ... quel con j'aurais du faire le prog avec ça, ça aurait été immédiat à traduire ! Mais bon ça faisait longtemps que je voulais faire un petit programme de test en Win32 pour manipuler les bitmap ...)
 
Dans ces 2 méthodes tu créés le bitmap et son DC puis tu les destruit. Ca oui, c'est win32. Ensuite, le seule autre ajout win32 est dans TWinControl::PaintWindow pour dessiner le bitmap quand il a été effacé (un simple blit complet) et dans CalculeColonne pour :
- afficher un point dans le bitmap avec setPixel(g_hBMPDC, Col, i, COLORREF(Couleur_voulue);
- afficher la colonne modifiée du bitmap dans ton controle : BitBlt(GetDeviceContext(), Colonne, 0, 1, Width, _hBMPDC, Colonne, 0, SRCCOPY);
Tout ce qui est HDC g_hWinDC, TRACE_WIDTH, et TRACE_HEIGHT devient TonComposant.Handle, TonComposant.Width, TonComposant.Height ...
 
Voila voila ... j?espère que ça va mieux ... on peut encore optimiser je pense via les DIB, puis via DirectX, puis avec l?assembleur, mais à chaque fois c?est de plus en plus complexe et apparemment ça c?est déjà pas simple !

HelloWorld a écrit a écrit :   Un mot sur ma notation : g_hWinDC : le "g_" c'est pour "global" a savoir variable globale. T'as pas a garder ca !

ouai, je sais bien , c'est juste pour m'y retrouver entre le code pascal et le tiens !
 

emptySepctrum est une fonction spécifique à mes besoins : la surface doit afficher un spectre. Mais il va devoir en afficher plusieurs puisque lorsqu'on examine quelqu'un, on lui examine plusieurs vaisseaux. donc, entre chaque examen, on remplit de noir la surface pour représenter un spectre vide -> d'où la méthode emptySpectrum qui je l'avoue a un nom de merde .
 

 
ah ouai, pas con
 

 
en fait, je crois qu'on ne peux pas utiliser le Handle dans le create parceque le composant n'a pas encore de fenêtre parente (renvoie l'erreur à l'execution : "le control '' n'a pas de fenêtre parente" )... d'où la méthode initTruc mais c'est en effet carrément mieux de le mettre dans CreateWnd, j'avoue que je n'avais pas remarqué son existence (sniff, excuses moi CreateWnd )
 
 

en fait, en delphi, ou plutôt en pascal, la casse n'est pas respectée donc si tu déclare un truc dans ce style : hdc: HDC , il va pas comprendre ... alors, j'ai mis un p devant pour "paramètre"
 

ouai, delphi "encapsule" du win32 (hum, j'aime bien les langage de haut niveau ) ... mais comme on peut utiliser toute l'api win32, j'y suis allé un peu comme un beu ...
 
 

ouai mais là, j'ai bien mieux compris t'expliques vachement bien ! merci beaucoup !
et c'est vrai que directX, j'risque de nager complétement !
 
 
bon, en tout cas, j'vais maintenant faire ça proprement (pas de freestyle cette fois-ci) et je devrais y arriver:D.
encore MERCI, et puis merci et merci    
 
aller, ciao et peut-être dans kekles heures pour de nouvelles aventures

putain, je suis trop un boulet...même avec toutes ces explications, j'y arrive po .... :gun:

[jfdsdjhfuetppo]--Message édité par Moustaaki le 24-05-2002 à 13:10:51--[/jfdsdjhfuetppo]

boolay time....
 
 
bon, voici mon code... le paintWnd ne fonctionne pas... ya ke ma fonction fillSurface ki marche puisqu'elle fait appel aux fonctions du VCL.
 
 

 
ou comment être un gros bouley DSL.
 
le truc, c'est que ça ne fait rien... ça plante pas, c'est déjà ça... mais ça fait queud.

[jfdsdjhfuetppo]--Message édité par Moustaaki le 24-05-2002 à 15:14:38--[/jfdsdjhfuetppo]

tu devrais songer à potasser sérieusement win32 ...  
 
et à lire la DOC !
 
hBitmap := CreateCompatibleBitmap(Canvas.Handle, Width, Height);  
hBitmapDC := CreateCompatibleDC(hBitmap);
SelectObject(hBitmapDC, hBitmap);  
 
je comprends même pas comment ça peut compiler ...
 
il faut :
 
* créer un dc compatible
* créer une image
* la sélectionner dans le dc
 
hBitmapDC := CreateCompatibleDC(Canvas.Handle);  
hBitmap := CreateCompatibleBitmap(hBitmap, Width, Height);  
SelectObject(hBitmapDC, hBitmap);