Discussion :

[AlainFt]

Le problème :
je dispose d'une form, un panel et des labels.
Les labels et le panel ont pour parent la form mais les labels ne sont pas parents du panel et ne doivent pas l'être.

Les label sont placés dans la surface occupée par le panel et sont donc masqués. Je souhaiterai les rendre visibles en les amenant au premier plan.
bringtofront ne fonctionne pas. Une idée ?

Je suis sous Windows.

[FChrisF]

C'est un problème bien connu (il me semble bien qu'il y a même eu une autre discussion sur le même sujet récemment dans ce forum; mais je n'en suis pas sûr).

Pour faire court, les Panel sont des descendants de la classe TWinControl (i.e. des contrôles "Windows), alors que les Label sont des contrôles graphiques descendants de la classe TGraphiControl (i.e. non "Windows"); pour ces derniers le Z-Order ne fonctionne pas (i.e. BringToFront n'a pas d'action, par exemple).

Une solution simple est d'utiliser un descendant de TWinControl à la place des Labels: les StaticText (Contrôles additionnels -> TStaticText).


Aparté:
De toute façon, mais ce n'est que mon avis personnel, les labels sont un héritage du passé (i.e. quand le nombre de handles étaient limités dans les premières versions de Windows) qui devrait avoir disparu depuis longtemps: mieux vaut laisser l'OS faire tout le travail, de manière générale.

[Andnotor]

De toute façon, mais ce n'est que mon avis personnel, les labels sont un héritage du passé (i.e. quand le nombre de handles étaient limités dans les premières versions de Windows) qui devrait avoir disparu depuis longtemps: mieux vaut laisser l'OS faire tout le travail, de manière générale.

Le nombre de handles n'est pas limité et je n'ai pas souvenir qu'il l'ait été. Ce qui l'est est le nombre d'objets allouables par chaque processus : 10'000 (mais évidemment, un handle est retourné sur chaque objet).
Par objet, on entend : les contrôles graphiques évidemment mais aussi les threads, les events, les fichiers, les pipes, les régions, les DC etc. etc.
Le nombre de handles peut être supérieur à 10'000 en passant par des DuplicateHandle.

Penser que l'OS se charge de leur gestion est une erreur. Les handles ne seront automatiquement libérés qu'à la terminaison du processus, sinon c'est bien au développeur de penser à les fermer par CloseHandle.

10'000, ça paraît beaucoup mais cette limite peut être vite atteinte avec une app "mal conçue" tournant 7/7 24/24.

[FChrisF]

Si, le nombre total de handles était limité dans les premières versions de Windows (3.0 et 3.1); je parlais bien des premières versions de Windows dans mon post précédent (cf. https://kb.iu.edu/d/abou par exemple).

Et j'ai toujours eu le souvenir que les labels Delphi (probablement la version 1.0, pour Windows 3.x) avaient créés uniquement pour palier à ce problème potentiel. Mais c'est peut-être une légende; ou bien ma mémoire n'est peut-être plus ce qu'elle était ...


Quand je parlais de laisser l'OS faire son travail, je pensais à l'affichage du texte (label vs statictext): les versions actuelles de Windows le font bien mieux actuellement, que tout le code Free Pascal ou Delphi, qui réinvente seulement la roue pour "peindre" ces labels.


Je le maintiens: les labels sont, toujours de mon point de vue, une "ignominie":

- la compatibilité des labels avec les différentes versions de Windows (et ses différentes "spécificités") a toujours été source de problème dans le passé (sans compter les problèmes de "flickering" dans les débuts),

- ils sont un énorme problème pour les applications pour mal-voyants (type NVDA) qui "lisent" le texte affiché à l'écran dans les fenêtres des applications,

- etc.

[AlainFt]

Merci à vous deux, je teste et vous tiens au courant.

[Andnotor]

Si, le nombre total de handles était limité dans les premières versions de Windows (3.0 et 3.1); je parlais bien des premières versions de Windows dans mon post précédent (cf. https://kb.iu.edu/d/abou par exemple).

Cette limite existe toujours mais elle concerne les objets

Quand je parlais de laisser l'OS faire son travail, je pensais à l'affichage du texte (label vs statictext): les versions actuelles de Windows le font bien mieux actuellement, que tout le code Free Pascal ou Delphi, qui réinvente seulement la roue pour "peindre" ces labels.

Les TLabel comme les TPaintBox offre un accès facilité au DC. Après, ce ne sont que des appels à des API Windows.

- la compatibilité des labels avec les différentes versions de Windows (et ses différentes "spécificités") a toujours été source de problème dans le passé (sans compter les problèmes de "flickering" dans les débuts),

Franchement, je ne vois pas !
Quant au flicker, il survient toujours et est dû au fait que Windows lance un effacement (WM_ERASEBKGND) avant le dessin. Ceci est résolu avec le double-buffering mais il suffit de désactiver le Desktop Windows Manager (DWM) pour le voir réapparaître.

- ils sont un énorme problème pour les applications pour mal-voyants (type NVDA) qui "lisent" le texte affiché à l'écran dans les fenêtres des applications,

C'est vrai et là tu marques un point

C'est le problème de toutes les applications purement graphiques qui n'assurent pas la compatibilité avec MSAA (ou UIAutomation). Même les principaux navigateurs (à part les produits Microsoft) ne sont pas au top sur le sujet.

[AlainFt]

testé et approuvé, merci.