Discussion :

[sfpx]

Oups j'ai trouvé le problème au niveau de la performance.
J'avais oublié de virer le déplacement de la form maitresse dans l'evenement moving de la pngform.

Resterait à solutionner le problème de scintillement au démarrage..

Mais bon, vu que sub0 travaille déjà sur un composant je vais laisser tomber...en fait je vais le continuer seulement pour mon apprentissage personnel

J'ai déjà appris quelques petits trucs qui me seront utiles.

[sfpx]

De plus, avec ta méthode, j'imagine que si je veux déplacer un control pendant l'éxécution du programme, ce ne sera plus possible, non ?

Bien vu.

En fait j'ai trouvé workaround pour employé un terme bien français.
Une procédure Redrawform qui doit être appelée lors de changements de la form maitresse
Ça fonctionne mais évidemment alors ça "flashe"

M'enfin je ne fais pas de concours et j'ai bien hâte de voir ton code final.

[Sub0]

sfpx, je travaille dessus, mais rien ne t'empêche de chercher à optimiser mon code de ton côté. Pour le moment, je suis encore à vérifier d'autres méthodes possibles... Je le répète, mon objectif principal est d'obtenir un compo aussi rapide et fluide que possible, c'est pour cette raison que les fonctions de traitemens graphiques seront très certainement codées en assembleur, à+

[sfpx]

Je met le tout sur la glace pour le moment car j'ai des petits problèmes à régler dans mon projet en cours.

P.S.
Avais tu regardé du côté du message wm_mouseactivate et du résultat ma_noactivate ou ma_noactivateandeat afin d'interdir le focus ?

J'ai essayé rapidement et effectivement il est alors possible d'interdire le focus mais pour ce qui est de capturer le mouvement de la fenetre par la suite je ne sais pas..

[Sub0]

Salut!

J'ai terminé le code pour WinXP, il est parfait!
Il se déplace vite, le focus reste bien affiché, il ne scintille pas, le fadein/out est nickel, et il fonctionne même par dessus une vidéo. On peut également modifier les controls dans la form pendant l'éxécution. Je suis maintenant en train de coder la version 16bits pour win95/98. Au final, le programme permutera lui-même le code. Lorsque les unités seront terminées, je transformerai le programme en composant visuel. Je posterai la source lorsque celle-ci sera terminée, à+

[DarkChamallo]

Vraiment chouette, merci pour ton travail acharné ! Tu me fais baver avec ton message Allez, bon courage pour la finalisation alors !!!

[DarkChamallo]

Tout se passe comme tu veux ? As-tu besoin que je teste/débeugue sous Win9x ?

[Sub0]

Salut!

Pour la version 16bits (win95/98), j'ai simplifié les choses en ne redessinant l'arrière-plan qu'après le déplacement sinon ça nécessite trop de ressources si on redessine pendant le déplacement, surtout si la fenêtre est grande... Pareil pour le fadein/out, la version 16bits n'en possède pas.

Bref, ce compo est surtout fait pour win32, mais reste compatible avec win16.
Je suis maintenant au stade d'en faire un composant. Je vous tiens au courant.
Si tu veux l'essayer, voici ma dernière compilation en pièce-jointe :

[DarkChamallo]

ok, je regarde ça merci

[DarkChamallo]

Bon, sous XP ça à l'air ok mais en même temps ce n'est qu'un exécutable donc je ne peux rien modifier sur la fiche pour tester

Sous windows 98 seconde édition il ne se passe rien... la gestion de détection du win16 doit pas être bonne : je clique 2 fois, un coup de sablier et... rien ! Ca me rappelle les mutex qui empèchent d'exécuter 2 fois un soft

Sous Windows 2000 le png est corrompu, c'est à dire que mal décompressé à l'affichage ou je ne sais quoi : concrètement le haut de l'image est à peu près correcte puis décolorée puis du milieu jusqu'en bas c'est du brouillard de bandes noires

Voilou.

[Sub0]

Merci pour ces tests. Je vais analyser ces bugs.
Je simplifie au maximum le code puis je te l'enverrai par mp.

[DarkChamallo]

Alors, voilà mes petits débeugages :

Sur WinXP :

- parfois (désolé, je n'ai pas su reproduire les conditions) au lancement du programme le mémo n'apparait qu'après un clic sur la fiche
- si une application fstayontop est déplacée par dessus la fiche (gestionnaire de tâche utilisé pour ce test), cette dernière suit la fenêtre fstayontop comme si elle y était collé au passage
- un clic droit sur la fiche restaure le texte du mémo que l'on avait pu effacer
- si on clique sur le bouton sans lacher puis qu'on lache la souris en dehors de la fiche, la fois suivante si on clique sur la fiche le bouton s'enfonce (ça à la rigueur on s'en fout, mais cela peut peut être créer d'autres incidents dans d'autres situations).

Sur Win2K :

- bitmap d'origine corrompu mais si "form.png" présent près de l'exécutable (et donc affiché) ce dernier n'est PAS corrompu.
- si image de fond plus grande, le clic pour déplacer la fiche est pris en compte tardivement, ça donne l'impression que la fiche est lourde à déplacer
- avec une image, disons 4 fois plus grosse que la bleue avec homer, la fiche devient excessivement lente au déplacement.

Sur Win98 :

- aucun test pour l'instant car rien n'est lancé à part un message d'exportation manquante à user32 (UpdateLayeredWindowMachin)

Voilou

[Sub0]

Merci pour les tests.
J'ai du pain sur la planche !

[Sub0]

J'ai finalement décidé de reprendre le code du départ en utilisant directement les TImages en 24bits sur la form puisque vraissemblabement, les bitmaps en 32bits posent problème avec les autres systèmes que WinXP. Je repars du tout 1er code que je vous avais donné (lire ce post). En ce qui concerne le déplacement, le développeur aura le choix d'utiliser ou non la transparence. Finalement, ce n'est pas très génant le fait que la transparence ne s'adapte pas lorsqu'on déplace la fenêtre car elle s'adapte lorsqu'on termine le déplacement... a+

[Sub0]

Oué, c'est vraiment la galère à mettre au point !
Je me demande si ça vaut bien la peine...