Au sujet de CONTAINER...

Bonjour,

quelques petites choses que j'ai remarqué au sujet du CONTAINER...
Ce ne sont pas des bugs mais des incohérences (à mon avis )

Code:

CONTAINER 1: TOP 1,50:LEFT 1,50
CONTAINER 2: TOP 2,170:LEFT 2,50
CONTAINER 3: TOP 3,290:LEFT 3,50

BUTTON 10:PARENT 10,1
CAPTION 10,"Test"

BUTTON 20:PARENT 20,2:TOP 20,18:LEFT 20,8
CAPTION 20,"Test"
INACTIVE 20

BUTTON 30:PARENT 30,3:TOP 30,18:LEFT 30,8
CAPTION 30,"Test"
INACTIVE 3

1er CONTAINER:
Le bouton est mal positionné. Normalement il devrait se trouver dans le cadre du CONTAINER et non pas 5 pixels au dessus. Cette poignée de pixels inclue en fait le caption du container. Les coordonnées 0,0 pour les enfants d'un container devraient se trouver dans le cadre...

2eme CONTAINER:
Le bouton est désactivé, son affichage est correct

3eme CONTAINER:
Le container est désactivé, donc le bouton également.
L'affichage du bouton n'est pas correct. Il devrait avoir la même apparence que dans le 2eme CONTAINER

Voilà, c'est pas grand chose mais cela ne me parait pas logique...

Je suis tout à fait d'accord avec toi.
Parfois le positionnement des objets est bizarre entre le "Form" et le "Container".
A moins que les pixels changent de dimensions.......

Bien vu Nardo,

Ce sont des bricoles, mais c'est bien de les signaler.....

A+

Sur le premier point, je sais depuis longtemps que les coordonnées du Container sont "hors tout", le cadre étant dessiné à l'intérieur. Gênant, certes, mais on peut s'en accommoder. d'ailleurs, je pense que ce composant est réalisé à l'aide d'un GROUPBOX de Delphi, qui fonctionne exactement de la même manière. C'est une contrainte qui vient en fait de Delphi.

Sur le second point, d'accord: tout est normal.

Sur le troisième point, tu as raison. L'affichage n'est pas normal. En Delphi, on place un buton dans un groupbox et un fait "groupbox1.enabled := false;", on obtient un affichage correct comme dans l'exemple 2. Je ne sais pas d'où vient la différence.

Bien vu Nardo. Je pense que l'on peut donc employer le mot bug qui va provoquer la machine infernale du debuggage de Jack Tu vois Nardo que tu ne peux pas t'absenter. Personne ne l'avait fait remarquer celui là.

Encore le mot magique (bug) qui a réussi à me faire sursauter.

Plus sérieusement, tout d'abord, merci à Nardo d'avoir présenté un exemple simple et compréhensible de ce qui le chagrine.

Pour le premier point, comme le dit Klaus, le CONTAINER est plus grand que le cadre, qui est tracé à l'intérieur du CONTAINER.
J'ai coloré le CONTAINER en gris clair pour bien montrer que le cadre est dessiné à l'intérieur.
De même, le CAPTION du container est tracé à l'intérieur du CONTAINER et sur le cadre.
Le premier point n'est pas un bug, car c'est conforme au "design" d'un CONTAINER.
Je préciserai cela dans la documentation.

Le deuxième point est un exemple qui fonctionne.

Pour le troisième, si on crée un traitement du clic sur le BUTTON 30, on voit bien que celui-ci n'est pas exécuté, car le CONTAINER de ce BUTTON est inactivé. Et pour confirmer, si on met en commentaire la ligne INACTIVE 3, le traitement du clic est correctement exécuté car le CONTAINER est alors actif.
Ce qui chagrine Nardo, c'est l'apparence du BUTTON 30: doit-on le mettre en apparence "inactif" quand le CONTAINER est inactif, et de manière générale, doit-on rendre en apparence "inactif" tout objet dont le PARENT est inactif ?
Je vous laisse débattre là-dessus puis je verrai si je modifie PANORAMIC. Pour le moment, je n'y suis pas favorable.

En résumé, dans l'exemple présenté, il n'y a aucun bug fonctionnel.

Code:

LABEL clic

CONTAINER 1: TOP 1,50:LEFT 1,50:COLOR 1,150,150,150
CONTAINER 2: TOP 2,170:LEFT 2,50
CONTAINER 3: TOP 3,290:LEFT 3,50

BUTTON 10:PARENT 10,1
CAPTION 10,"Test"

BUTTON 20:PARENT 20,2:TOP 20,18:LEFT 20,8
CAPTION 20,"Test"
INACTIVE 20

BUTTON 30:PARENT 30,3:TOP 30,18:LEFT 30,8
CAPTION 30,"Test"
ON_CLICK 30,clic
INACTIVE 3

END

clic:
CAPTION 30,"CLIC"
WAIT 500
CAPTION 30,"Test"
RETURN

Il y a bien une possibilité pour solutionner le cas N°3, avec if inactive(3)=1 then inactive 30:

Code:

LABEL clic

CONTAINER 1: TOP 1,50:LEFT 1,50:COLOR 1,150,150,150
CONTAINER 2: TOP 2,170:LEFT 2,50
CONTAINER 3: TOP 3,290:LEFT 3,50

BUTTON 10:PARENT 10,1
CAPTION 10,"Test"

BUTTON 20:PARENT 20,2:TOP 20,18:LEFT 20,8
CAPTION 20,"Test"
INACTIVE 20

BUTTON 30:PARENT 30,3:TOP 30,18:LEFT 30,8
CAPTION 30,"test"
ON_CLICK 30,clic
INACTIVE 3

if inactive(3)=1 then inactive 30: ' il faut le faire à chaque objets

END

clic:
CAPTION 30,"CLIC"
WAIT 500
CAPTION 30,"Test"
RETURN

Mais c'est contraignant s'il y a beaucoup d'objets dans le container.

A+

Bonjour,

Jack a écrit:

En résumé, dans l'exemple présenté, il n'y a aucun bug fonctionnel.

Tout à fait Jack, je n'ai pas dis qu'il y avait un bug
C'est pour cette raison que je l'ai mis dans la rubrique :
"souhait et amélioration"... pour moi, c'est un fonctionnement normal.

Par contre ce qui ne me parait pas juste (visuellement parlant) c'est que dans le cas n°3, du fait que le container est inactif, le bouton est inactif (ça c'est normal) mais il a conservé l'apparence d'un bouton actif (là cela ne me parait pas normal).

Mais bon, j'ai bien précisé que c'était juste un détail...

L'exemple 2 est correct, c'est juste pour bien montrer l'apparence que doit avoir normalement (à mon avis) le bouton dans le cas n°3

@Jean-claude: Oui c'est d'ailleurs ce que je fais actuellement....

@Jack:
Le comportement est identique avec une form au lieu d'un container:

Code:

label x
width 0,200 : height 0,80
button 1 : caption 1,"Désactiver"
  on_click 1,x
form 10 : top 10,80 : left 10,200
button 12 : caption 12,"Bouton"
parent 12,10
inactive 10
end
x:
inactive 12
return

La form 10 est désactivée, le bouton 12 ne l'est pas. On ne peut pas le cliquer, pourtant on ne voit rien visuellement. Si l'on clique le bouton 1 "Désactiver", la routine X désactive explicitement le bouton 12. Cela ne change rien fonctionnellement, mais le bouton est grisé visuellement.

Je pense que c'est là un comportement général des composants utilisés pour implémenter Panoramic. est-ce utile de changer cela ? Je ne pense pas - l'effort serait sûrement important.Je sais, je suis en train de contredire le sens de mon post précédent, mais c'est le résultat de mes tests et réflexions sur cet aspect visuel.

Juste une idée que j'envoie en l'air!
On aurait un objet ou une forme avec une transparence qu'on mettrait par-dessus, cela pourrait faire l'affaire.
C'est peut-être idiot, mais l'avantage du procédé, est qu'il ne ralentit (incalculable) pas l'exécution du programme, alors que si tous les objets doivent être contrôlés et suivent la définition d'un container ou d'une forme, inclus un parcours d'une table supplémentaire, donc ralentit le processus.
C'est ce que je crois, maintenant ...

C'est une bonne idée, cosmos70. Juste un genre de filtre légèrement opacifiant qui viendrait se positionner au-dessus du container ou de la form désactivée. On aurait immédiatement une indication visuelle.

Actuellement, Panoramic ne contient aucun objet qui nous permette de le faire à notre niveau. Est-ce que c'est faisable pour Jack au niveau du noyau de Panoramic - lui seul peut répondre.

L'idée d'un masque transparent est bonne : ça simplifie le boulot de Jack !
(je pense qu'il doit en ce moment te remercier et mettre un ex-voto sur le mur des demandes d'amelioration de Pano )

l'essentiel c'est que les "childs" soient dans le même état que le contenant...
le reste c'est de " l'habillage " que je voulais seulement faire remarquer.
C'est clair que si cela demande beaucoup de boulot à Jack, cela n'en vaut pas la peine...

Je suis pour l'objet opacifiant (en plus ça ouvrirait peut-être la porte de la copie d'image avec gestion de la transparence, on ne sait jamais ) (Vous pouvez m'appeler "Idée fixe" si vous voulez .... )

Le seul hic, c'est que rien ne peut recouvrir un bouton en dehors d'un autre form... et si on veut régler la transparence du form, il faut utiliser une dll...
...
c'est pas grave...

Sauf si Jack le gère "nativement" dans Panoramic, je pense

Puisqu'on est au bout de l'idée, et pour ne pas alourdir les sujets qui ne servent à rien, une parenthèse:
J'avais demandé si on pourrait avoir la possibilité d'avoir un lignage dans un memo par exemple, sans jamais avoir de réponse.
J'ai trouvé ceci:

Citation :

Aujourd'hui, PANORAMIC a pris une direction à laquelle je ne m'attendais pas. Je pensais qu'on me demanderait plus d'objets Windows, des "quadrillages" comme dans EXCEL, des objets pour tracer des histogrammes, des camemberts, des courbes à partir d'un tableau de données, ou encore des fonctions 3D comme l'animation, les keyframes. Mais non.
Je développe surtout des fonctions de base du langage pour répondre à la demande

Vous ne savez pas demander! Jack est près à tout!

Oui, mais bon, on essaye d'éviter de demander les objets de confort comme Jack travaille déjà sur le moteur et une refonte du fonctionnement ... mais bon, ce n'est pas tombé dans l'oreille d'un sourd et quand la v& sera pleinement opérationnelle, on pourra demander pleins d'objets à Jack pour remplir sa todo list...

J'ai fait un petit essai, à l'ai de d'une de mes DLLs. J'ai une fonction qui peut rendre une form translucide, à un degré réglable. Alors, j'ai placé deux boutons. Le bouton "Cacher" va créer une form sans bord qui se place par-dessus ce bouton, et cette form sera légèrement translucide. Il n'est plus possible de cliquer sur le bouton, bien qu'il ne soit pas désactivé. Et le bouton est "flouté". Le bouton "Montrer" supprime la form qui sert de masque.

Comme il s'agit d'une form que j'ajoute, elle va disparaître à l'arrière-plan dès qu'on clique dans la form 0, et mon bouton sera alors accessible. Pour éviter cela, j'ai ajouter un on_click dans la form 0 pour rappeler mon masque en avant-plan.

C'est une maquette de masquage, et ça montre que c'est possible. On peut pousser plus loin s'il le faut. Voici le code de ma maquette:

Code:

label x,y,z
dim x%, i%

button 1 : top 1,30 : left 1,30
on_click 1,x : caption 1,"Cacher"
button 2 : top 2,30 : left 2,300
on_click 2,y : caption 2,"Montrer"
dll_on "SetWindowButtons.dll"
on_click 0,z
end

x:
form 10 : top 10,30 : left 10,25
width 10,150 : height 10,80
border_hide 10
x% = handle(10)
i% = dll_call2("WindowTranparency",x%,200)
return

y:
delete 10
return
z:
if object_exists(10)=1 then to_foreground 10
return

Il faut SetWindowButtons.dll. Et voici le code Delphi de la routine WindowTransparency:

Code:

function WindowTranparency(hWnd,trans: integer): integer; stdcall; export;
var
    WinInfo: Integer;
    xtrans: integer;
begin
    xtrans := trans;
    if xtrans<0 then xtrans := 0;
    if xtrans>255 then xtrans := 255;
    WinInfo := GetWindowLong(hWnd, GWL_EXSTYLE);
    If xtrans < 255 Then  begin
        WinInfo:= WinInfo Or (WS_EX_LAYERED);
        SetWindowLong (hWnd, GWL_EXSTYLE, WinInfo);
        SetLayeredWindowAttributes (hWnd, 0, xtrans, LWA_ALPHA);
    end Else begin
        WinInfo:= WinInfo Xor WS_EX_LAYERED;
        SetWindowLong (hWnd, GWL_EXSTYLE, WinInfo);
    End;
    result := 0;
end;

J'ai regardé un peu plus en profondeur. Créer une fenêtre translucide n'est qu'un pis-aller. En effet, quand on déplace la fenêtre de base, la fenêtre translucide reste à sa place, et l'effet est perdu. On peut attacher une form à un container via ma fonction AttachWindowToWindow (dans la même DLL). Mais malheureusement, elle perd alors son degré de transparence. En effet, Windows ne sait gérer la transparence que pour des fenêtres sans parent, donc celles qui sont "libres". C'est une restriction Windows.

Les forums de Delphi sont remplis de demandes de transparence sur tel ou tel objet. Ce n'est possible qu'au prix d'un effort considérable, en créant un dérivé de l'objet concerné et en remplaçant la méthode par défaut de dessin du fond par une procédure spécifique qui copierait la portion de l'écran en-dessous du contrôle dans son image, avant de dessiner le reste. Et encore, en cas de redimensionnement de la fenêtre de base ou en cas de déplacement de la fenêtre de base, il y a de vilains scintillements inévitables.

Par conséquant, le choix d'une fenêtre translucide pour priser l'image d'un container n'est pas réellement applicable, ni en Panoramic, ni par moi dans une DLL. Et je doute que Jack puisse le faire facilement bien qu'ayant le contrôle du noyau de Panoramic.

Seule solution: parcourir tous les objets d'un container et les rendre inactifs. Mais ça, Jack ne peut pas le faire automatiquement en Panoramic. Car supposons que le container contenait un objet intentionnellement inactif. En rendant le container inactif, rien ne changerait pour cet objet. Mais en rendant le container actif à nouveau, on ne sait plus quel objet était initialement actif ou inactif, et on se retrouverait avec tous les objets actifs ! Cette boucle pour inactiver les objets ne peut être gérée que par le programme lui-même. Il ne peut y avoir rien d'automatique.

Une solution approchante mais "brutale": créer un second container avec les mêmes dimensions au même emplacement, mais vide et caché. Au lieu de désactiver le container d'origine, il suffit de montrer le container vide par show, et au lieu de réactiver, on cache le container vide par hide. Certes, on ne voit plus rien. Mais on voit immédiatement que rien n'est accessible.

EDIT

Je vais même en ajouter une couche ! Si dans un container, on a un autre container avec des objets. Désactiver le container principal, cela doit provoquer quoi ? Je ne pense pas qu'il y ait une solution simple pour tous les cas de figure. La gestion de l'apparence, à mon sens, doit vraiment rester au niveau de l'application.

Bonjour,
Le plus simple, car depuis deux jours je suis sur des conteneurs et conteneur options, c'est de travailler sur la fonte.
On fait par exemple: fonte_color x,180,180,180 pour un conteneur inactif. Et fonte x,0,0,0 (ou autre, moi j'ai mis bleu) pour un container actif.
Il ne reste plus que les boutons, qu'il faut rendre actif ou inactif, car cela il ne sont pas consernés par la fonte.

J'ai essayé de jouer avec les couleurs des containers, pour marquer actif/inactif. Et j'ai constaté une chose curieuse.

Je fais un container contenant un bouton et un autre container qui à son tour contient un bouton. J'ai, dans la form 0, deux jeux de boutons, pour désactiver/activer le premier container et le second. En désactivant, je diminue les valeurs RGB du container ciblé de 10, et en activant, je remets la couleur d'origine.

Si je désactive le container 2 (le petit à l'intérieur), tout fonctionne comme on l'imagine: le bouton à l'intérieur est inactif bien qu'il ne change pas d'aspect, et le container 2 est grisé. Si je réactive ce container, tout revient à son état initial.

Si maintenant, SANS sortir du programme, je désactive le container 1 (le grand contenant tout), le même raisonnement s'applique: tout l'intérieur devient inactif, mais seul le container 1 change de couleur, ce qui est normal. Si maintenant je réactive le container 1, tout revient à son état initial.

Tout semble normal, de direz-vous. Or, il y a un problème ! Sortez du programme, relancez-le et commencez par désactiver le container 1. Résultat ? Tout comme précédemment, tout l'intérieur est inactif. Normal. Mais la couleur du container 2 a changé aussi ! Et ça, ce n'est pas normal ! Réactivez le container 1, et tout revient à son état initial, même le container 2 ! Mais si, sans sortir du programme, vous désactivez maintenant le container 2, puis vous le réactivez, le même phénomène ne se produira plus ! Désactiver maintenant le container 1 de grise plus le container 2 !

Tout se passe comme si le container 2 copiait automatiquement la couleur de son container parent, jusqu'à ce qu'on lui donne une couleur personnelle. A partir de ce moment, il est autonome en ce qui concernenla couleur.

D'accord, ce n'est pas bloquant, ce n'est pas grave, c'est un détail. Mais c'est curieux tout de même. Voici le programme pour le vérifier:

Code:

label x1,y1,x2,y2
dim r%, g%, b%
r% = 236 : g% = 233 : b% = 216

button 1 : top 1,10 : left 1,10
caption 1,"Inactiver 1" : on_click 1,x1

button 2 : top 2,10 : left 2,160
caption 2,"Activer 1" : on_click 2,y1

button 3 : top 3,10 : left 3,310
caption 3,"Inactiver 2" : on_click 3,x2

button 4 : top 4,10 : left 4,460
caption 4,"Activer 2" : on_click 4,y2

width 0,800 : height 0,600

container 10 : top 10,50 : left 10,10
width 10,400 : height 10,400
caption 10,"Container 1"
button 11 : parent 11,10 : top 11,20 : left 11,10
caption 11,"Bouton 1" : hint 11,"Bouton 1"

container 20 : parent 20,10 : top 20,60 : left 20,10
caption 20,"Container 2"
button 21 : parent 21,20 : top 21,20 : left 21,10
caption 21,"Bouton 2" : hint 21,"Bouton 2"

end

x1:
inactive 10
color 10,r%-10,g%-10,b%-10
return

y1:
active 10
color 10,r%,g%,b%
return

x2:
inactive 20
color 20,r%-10,g%-10,b%-10
return

y2:
active 20
color 20,r%,g%,b%
return

Bizarre. Je regarde pourquoi.