EXEMPLE DE MANUAL DOCKING OU COMMENT DONNER DE LA SOUPLESSE À VOS APPLICATIONS
Caribensila
Messages postés
2527
Date d'inscription
jeudi 15 janvier 2004
Statut
Membre
Dernière intervention
16 octobre 2019
-
3 févr. 2011 à 15:54
cs_cantador Messages postés 4720 Date d'inscription dimanche 26 février 2006 Statut Modérateur Dernière intervention 31 juillet 2021 - 9 mars 2011 à 09:10
cs_cantador Messages postés 4720 Date d'inscription dimanche 26 février 2006 Statut Modérateur Dernière intervention 31 juillet 2021 - 9 mars 2011 à 09:10
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/52780-exemple-de-manual-docking-ou-comment-donner-de-la-souplesse-a-vos-applications
https://codes-sources.commentcamarche.net/source/52780-exemple-de-manual-docking-ou-comment-donner-de-la-souplesse-a-vos-applications
9 mars 2011 à 09:10
j'ai des applis mais on ne peut plus banales..
mais qui ne traitent pas la création de fiches à
l'intérieur d'un Thread ce qui est bien le sujet évoqué
par Caribensila.
Mais, il suffit de tester, c'est-à-dire placer :
if not Assigned(Form2) then
Application.CreateForm(TForm2, Form2)
dans une procédure située dans un Thread
en enlevant dans les options la création au démarrage de la form2
pas de quoi déposer une source, tout juste peut-être un snippet..
cantador
7 mars 2011 à 16:10
7 mars 2011 à 16:03
Tu dis avoir des applications perso qui continennent des Thread et des créations de fiches pourrais tu faire une démo cela m'interesserai comme beaucoup de mon niveau (Débutant chronique)
11 févr. 2011 à 16:05
non,
j'ai des applications perso qui continennent des Thread et des créations de fiches
mais effectivement ça me semble une excellente idée de faire le tout ensemble et cela ne doit pas à priori poser de soucis.
cantador
11 févr. 2011 à 14:57
Dans une application lourde, as-tu déjà essayé de construire les fiches dans un Thread dont la priority = tpIdle ?
Cela pourrait être une méthode combinant tous les avantages.
Il me semble que le risque que l'utilisateur demande la construction d'une fiche en même temps que l'application (faible probabilité), ne doit pas être très difficile à gérer...
Qu'en pensez-vous ?
11 févr. 2011 à 10:15
@L_art_ment et Caribensila :
le souci de la création des fiches se pose bien évidememnt lorsque ces dernières sont lourdes
deux solutions :
soit on les créent à la demande, l'application s'ouvre plus vite au démarrage mais souffrira un peu lors de l'ouverture de celles-ci.
soit, on laisse delphi les créer au démarrage et dans ce cas, l'utilisateur devra patienter et ensuite tout sera léger.
il n'y pas vraiment de solution miracle..
Pour ma part, j'opte le plus souvent pour la création des fiches au démarrage et lorsque vraiment, le temps d'ouverture semble long (ce qui est parfois pénible), alors je mets en place une barre de progression pendant la création des fiches + ouverture des tables.
Cela rassure en quelque sorte l'utilisateur qui ne se pose plus de questions à savoir si l'appli est plantée ou pas etc.
Ce système est d'ailleurs courant aujourd'hui (barre de progression lors des installations
des logiciels ou chargement dans les jeux vidéos etc..)
Il faut aussi prendre en compte l'objet de l'application.
cantador
8 févr. 2011 à 16:27
car pas mal de choses n'existaient pas sous D5 :
bien sur XPmanifest et VARIANTS (heureusement ta démo n'en a pas du tout besoin)
ensuite quelques nouvelles propriétés , sur les boutons LBL_LINK1 LINK2 LINK3 (OnMouse et Font.Color) , sur les PANEL (Panel1 ParentBackground), LabelSpacing ... etc ..
et surtout les composant TLabeledEdit ou LabelEdit (inexistant en D5 , mais l'équivalent existaient dans les packs de composants payants ou gratuits, tel que PROLIB18)
Pour faire cela, évidemment pas dans l'IDE , ce nettoyage se fait dans un éditeur tel que NotePad++ ou PSPad (mes préférés)
et aussi la directive {$IF qui, sauf mon ignorance, n'existait que sous une forme limitative : $IFDEF ou $IFNDEF ...
Et bien, merveille, ça marche impeccable sous D5 , résultat identique , enfin pour ce qui est de l'aspect visuel et du fonctionnement,
par contre l'embonpoint et l'obésité made in USA nous frappe de plein fouet :
l' EXE = 1176 ko sous D5 , et maintenant 1763 ko sous D2010 !!!
dont environ 800ko rien que pour l'image incorporée dans UMAIN.DFM (pour l'ombrage)
cordialement
************
7 févr. 2011 à 14:12
pour D5, oui je comprends mais saches que ça prend 5mn pour se faire un composant TXPManifest compatible avec D7 et +
à l'occasion si tu pouvais tester le code sous D5 pour savoir si ma modif est acceptée où non.
7 févr. 2011 à 13:48
Merci pour le commentaire ... pour la note, si tu y tiens toujours, tu peux à nouveau noter. L'ancienne a été supprimée.
@Caribensila:
"Voici une petite manip' de docking sans une seule ligne de code entraînant de grands effets sans trop d'efforts non plus ! ^^ "
oui ... mais c'était pas le but recherché, je pense que l'utilité est différente ici. Le code que je propose offre, à mon avis, des possibilités autres que celles du docking automatique. ;)
@Tous:
D'ailleurs à ce propos, vous trouverez dans les Démos de Delphi un bel exemple de Docking (Drag n Drop) sur fiches et ToolBars.
Répertoire d'installation de Delphi ... \Demos\Docking\DockEx.dpr
7 févr. 2011 à 13:43
pour ce qui est de DELPHI5 , c'est effectivement par nécessité : quand on dispose de nombreux composants PAYANTS sous D5 , on n'a pas envie de remettre des centaines d'euros pour acquerir les memes en version plus récente.
Et aussi, je suis définitivement faché avec la nouvelle formule des Helps apparu avec D2005 et suivants (tout ça pour se mettre au diapason de Microsoft).
7 févr. 2011 à 11:35
7 févr. 2011 à 11:34
7 févr. 2011 à 11:13
Delphi 7 est un minimum aujourd'hui ... ceux qui veulent rester à une version antérieur (par choix où nécessité) ... libre à eux mais 99,9% des codes déposés ici le sont pour D7 et plus
Le thème XPManifest est un "problème" connu depuis au moins 8 ans et des solutions alternatives existes, à vous de les utiliser. ( J'ai fait une modif dans le code mais je sais pas si ça passe sous D5, version que je ne possède pas)
Sinon le code est modifié pour contrer l'erreur ... il semblerait que l'évènement OnChange du PageControl soit déclenché une deuxième fois sous D2009 et + ... problème résolu.
7 févr. 2011 à 07:58
{Sélection du menu en fonction de la fiche au premier plan}
procedure TMainDocfrm.PageControl1Change(Sender: TObject);
var X1 : integer ;
begin
X1 := PageControl1.ActivePage.ControlCount-1 ;
if (PageControl1.ActivePage.Controls[X1] is TForm) then begin
** nota : j'ai légèrement modifié pour faire apparaitre l'indice X1 ,
qui se révèle être NEGATIF , soit -1
7 févr. 2011 à 07:35
Avec DELPHI5 , beaucoup d'erreurs, car le composant XPmanifest n'existe pas.
Avec DELPHI2010, la compile et le début d'exécution fonctionne impec ( le projet DPR est transformé en DPROJ automatiquement)
La ou ça coince, c'est lorsqu'on clique sur l'un des boutons "Relacher Manuellement" : on récolte une erreur grave
"le projet ManualDoc.EXE .... EAcessViolation ... adresse 00433136 .... lecture adr 000008"
L
6 févr. 2011 à 23:30
Dans la démo de Cirec je prends, pour l'exemple, l'appli SHADED TEXT.
1) Mettre la propriété 'DockSite' de la fiche 'Ombrefrm' à true.
2) Mettre la propriété 'DragKind' du TPanel 'Panel1' à 'dkDock'.
3) Mettre la propriété 'DragMode' du TPanel 'Panel1' à 'dmAutomatic'.
Lancez l'application et amusez-vous à "draguer" le Panel1 où ça vous chante.
Dans cet exemple ça n'a pas grand intérêt, mais imaginez ce truc dans des applications prévues pour... ;)
5 févr. 2011 à 08:30
4 févr. 2011 à 21:49
Merci pour cette méthode simple et efficace, qui va me rendre de grand service.
4 févr. 2011 à 19:41
donc, pour que ça fonctionne il faut impérativement déposer un TMainMenu sur la fiche principale de l'application (avec ou sans Items ça n'a pas d'importance).
La gestion est très simple vous verrez cela dans le code
j'ai "poussé" la gestion aux "multimenus" donc chaque fiche peut contenir un TMainMenu et en fonction de la page active et si c'est une fiche(TForm) et si elle dispose d'un MainMenu il sera affiché à la place habituelle.
ah oui, dans l'unité UMain.pas du projet de Caribensila, à la fin, on y trouve un exemple de retrait du menu si l'on demande la fermeture de la fiche par commande interne.
Voilà .. je crois qu'il ne manque plus rien :D
4 févr. 2011 à 19:24
merci pour vos commentaires ... je suis content que ça vous plaise
@Dubois77:
je pense avoir résolu le problème des menus ... à savoir qu'un TMainMenu ne peut s'afficher qu'en haut d'une fiche ... de ce fait il faut ruser :D
encore une petite astuce qui, je trouve, règle assez bien le problème sans trop d'efforts ^^
4 févr. 2011 à 18:52
simple et efficace
A+
4 févr. 2011 à 13:51
Question d'un néophyte :
J'ai essayé le source de CIREC avec le truc de Caribensila (tout est impec !) avec une application autre que celles qu'il a fourni.
Dans cette application il a un menu
Elle n’apparaît pas à l’exécution
Comment faire pour voir le menu (si cela est possible bien sur)
Cordialement
Roger
4 févr. 2011 à 08:44
Encore une fois, Delphifr tombe à point pour moi !
Cette source est exactement ce que je souhaite faire dans l'une de mes applications en ce moment, une application assez lourde (avec base de données, active directory et tout le tralala).
J'avais utilisé une méthode autre, le principe était de ne pas créé les forms dés le démarrage (comme le préconise Cari juste au dessus) et de les créer au moment voulu dans mon appli en renseignant un panel sur ma form Principale comme parent de la form à créé (euh ma phrase est-elle claire ?)
Cependant, un problème se posait, admettons, si de ma form3, je souhaitais agir sur un composant de ma form Principale (par exemple un ClientDataSet relié à une dbGrid) je me retrouvais avec des messages d'erreur, alors que mon code était bon.
Je vais donc essayé avec ta methode pour voir si je peux accéder d'une fiche à l'autre sans soucis.
Merci pour ton source !
3 févr. 2011 à 23:32
Dans une application, seules les fiches nécessaires dès le démarrage doivent être crées automatiquement !
Si je prends comme exemple la démo de Cirec et que l'on considère que d'écrire avec des ombres sera une occupation occasionnelle, il n'est pas nécessaire de créer la fiche Ombrefrm dès le lancement.
Comment faire ?
Sous D7, dans l'IDE, cliquer sur Projet/Options.../Fiches
et mettre la fiche Ombrefrm en disponibilité en cliquant sur le '>'. Ainsi, elle ne sera plus créée au démarrage.
Et ajouter cette ligne dans le code de Cirec pour créer la fiche quand besoin :
procedure TMainDocfrm.btn_Doc3Click(Sender: TObject);
begin
btn_Doc3.Enabled := False;
btn_UnDoc3.Enabled := True;
if Ombrefrm=nil then Application.CreateForm(TOmbrefrm,Ombrefrm); /////// La ligne à ajouter //////
Ombrefrm.ManualDock(PageControl1, nil, alClient);
PageControl1.ActivePageIndex := PageControl1.PageCount - 1;
if not Ombrefrm.Visible then Ombrefrm.Show;
end;
En faisant de même avec toutes les fiches secondaires, l'utilisateur ne s'apercevra de rien et aura le sentiment d'utiliser une application alliant légéreté et performances. Le rêve, quoi...
Merci à Cirec de me pardonner ce squat, mais c'était l'occasion... ;)
3 févr. 2011 à 17:03
3 févr. 2011 à 15:54
[Didier Nordon. Revue: Pour la Science. Février 2011]
Et bien, voici une citation qui s'applique parfaitement à ce 'post'. :)
Merci Cirec.
Je me permets de préciser que cette démo a été inspirée à Cirec par une discussion du forum concernant le Modèle MDI qui est un mode d'écriture 'deprecated' dans Windows. Cette démo illustre à merveille une alternative puissante et pleine d'intérêt.