Tabstrip en utilisant les objets form (vb.net)

Soyez le premier à donner votre avis sur cette source.

Vue 11 447 fois - Téléchargée 1 249 fois

Description

Ce code montre un exemple de gestion d'un TabStrip avec des objets FORM au lieu des objets FRAME.
Je trouve ceci plus clair que l'utilisation des FRAME.

Mes problèmatiques restantes sont :
1) Il n'est pas possible d'utiliser un module de classe pour gérer chaque TabStrip car le passage des références vers la Form principal et du TabStrip ne peut pas s'effectuer. VB me jette avec une erreur. (Hors une instance de classe par TabStrip serait beucoup mieux :-( ). Vu que cela est possible dans un module, alors j'ai créé un module générique qui gére n'importe quel TabStrip.
2) Il y un effet pas très design, c'est la Frame principal qui s'inactive lorsque l'on utilise le form du TabStrip (méthode SetWindowLong + WS_CHILD ne fonctionne pas)

Codes Sources

A voir également

Ajouter un commentaire

Commentaires

cs_Jack
Messages postés
14008
Date d'inscription
samedi 29 décembre 2001
Statut
Modérateur
Dernière intervention
28 août 2015
61 -
Oui, pourquoi pas.
Avantage de ta méthode :
Quand, dans une TabStrip qui gère des options d'un programme, tu as beaucoup de controles, ça devient lourd, le compilo n'aime pas trop et en plus, VB6 limite le nombre de composants par forme à 255 (de mémoire).
Donc, le fait d'utiliser des formes peut résoudre ce genre de problème.
MdoDev
Messages postés
4
Date d'inscription
jeudi 8 juin 2006
Statut
Membre
Dernière intervention
6 juillet 2006
-
Pour moi l'autre avantage est de rendre le code plus clair et donc facilement maintenable.

Merci.
Mdo
cs_FraGag
Messages postés
82
Date d'inscription
jeudi 19 février 2004
Statut
Membre
Dernière intervention
18 avril 2008
-
Plusieurs programmes (pas écrits en VB bien sûr...) utilisent les "Dialogs" de Windows pour afficher du contenu dans des onglets, sauf que ces fenêtres sont enfants de la fenêtre principale. En faisant ainsi, on enlèverait l'effet "pas joli". L'API SetParent est là pour ça. De plus, il ne sera plus nécessaire de calculer la position du form parent pour l'ajouter à la position des forms enfants. Finalement, avec les propriétés ClientLeft, ClientTop, ClientWidth et ClientHeight du TabStrip, il n'y a qu'à faire, dans Form_Resize :

Private Sub Form_Resize()
Dim i As Integer
For i = 1 To UBound(m_Forms)
m_Forms(i).frmFormName.Move TabStrip1.ClientLeft, ... 'continuer avec les autres ClientXYZ
Next
End Sub
MdoDev
Messages postés
4
Date d'inscription
jeudi 8 juin 2006
Statut
Membre
Dernière intervention
6 juillet 2006
-
Je vais mettre à jour mon source et tester dès que possible, A suivre ...
cs_FraGag
Messages postés
82
Date d'inscription
jeudi 19 février 2004
Statut
Membre
Dernière intervention
18 avril 2008
-
Je viens de me souvenir qu'il faut ajouter le style WS_CHILD (&H40000000) pour que les forms ne volent pas le focus au form parent. Présentement, quand un form est sélectionné, le form parent est désélectionné, mais avec SetWindowLong, avec nIndex = GWL_STYLE (-16), le form parent gardera le focus également (comme si c'était n'importe quel contrôle qu'on dépose sur un form). Il est important de conserver l'ancien style (à récupérer avec GetWindowLong) et de mélanger WS_CHILD avec l'opérateur Or (on l'enlèverait avec And Not). Donc, la ligne à ajouter (je la mettrais juste après l'appel à SetParent) serait :

Call SetWindowLong(stForms(UBound(stForms)).frmFormName.hWnd, GWL_STYLE, GetWindowLong(stForms(UBound(stForms)).frmFormName.hWnd, GWL_STYLE) Or WS_CHILD)

Il ne reste qu'à déclarer les APIs et les constantes, dont j'ai mis les valeurs entre parenthèses. Maintenant, on ne devrait y voir que du feu !

Vous n'êtes pas encore membre ?

inscrivez-vous, c'est gratuit et ça prend moins d'une minute !

Les membres obtiennent plus de réponses que les utilisateurs anonymes.

Le fait d'être membre vous permet d'avoir un suivi détaillé de vos demandes et codes sources.

Le fait d'être membre vous permet d'avoir des options supplémentaires.