Discussion :

[Jipété]

Pour ne pas qu'on m'accuse de coder avec des vieux bouzins, j'ai ouvert le projet dans une machine virtuelle où se trouve la merveilleuse 1.8.2 et je croyais bien que la solution était là :
Il y a deux espaces entre "écrite" et "avec" afin que "la" se retrouve ligne suivante, pour comparer avec la 1.4.0



J'enlève l'espace en trop et j'en rajoute après "avec", "la" reste en bas



Mais un appui de plus sur la barre d'espace et badaboum...



J'enlève le , ça ne l'est pas du tout.

[BeanzMaster]

mais en WordWrap, l'encombrement n'est plus le même :

Bien vue, pas du tout penser à ce truc.

Salut à tous,

EDIT : c'était trop beau !
Un dernier mot : je viens de tester à l'instant, ça fonctionne bien avec le TLabel (bien vu, BeanzMaster ) et c'est plus simple. Incroyable !
Dommage qu'il n'ait pas de bordure pour voir exactement la taille des objets mais bon, ne demandons pas l'impossible.

Le but final de la manip étant de simuler un TRichEdit, ça a l'air d'être bon .
Quelle aventure !

Avec une ligne de texte un poil longue, c'est foutu dès la première action (chargement des fichiers d'un dossier, création des TLabels)
Notez l'ascenseur horizontal de la ScrollBox parente des TLabels, que je n'avais jamais vu avec les TMemo.
Pièce jointe 361948

Pour que cela fonctionne il te faut contraindre les dimensions du TLabel avec celle de la scrollbox. Ainsi la barre de scroll horizontale n'apparaitera pas

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
procedure TForm1.CreateLabel;
var
  i:integer;
begin
  For i:=0 to 2 do
  begin
    LabelsContainer[i] := TLabel.Create(Self);
    With LabelsContainer[i] do
    begin
      Parent := ScrollBox1;
      Align := alTop;
      Height := 100;
      WordWrap := True;
      Constraints.maxwidth := scrollbox1.Clientwidth - 16; //<----- C'est ici que ca ce passe, -16 a cause de la scroll barre verticale si elle est affichée, sinon on déborde et la scroll barre horizontale s'affiche
      autosize := True; //<---- Important sinon la hauteur ne sera pas mise à jour
      Borderspacing.around:=4; // pour l'esthetique :)
    end;
  end;
end;

EDIT : Constraints.maxwidth := scrollbox1.Clientwidth - 16; le -16 c'est peut-être un peu trop juste 24 ou 32 me semble plus approprié

[Jipété]

Salut,

Pour que cela fonctionne il te faut contraindre les dimensions du TLabel avec celle de la scrollbox. Ainsi la barre de scroll horizontale n'apparaitra pas

il me semblait l'avoir dit, j'ai regardé mais pas trouvé donc désolé, j'ai dû oublier de dire que j'ai abandonné le TLabel pour la bonne et simple raison qu'il est très confortable de pouvoir pianoter un (ou quelques) caractère(s) dans un seul TMemo, sans passer par la ligne du TEdit qui, elle, est recopiée dans tous les objets d'affichage présents.

À propos du problème montré par les .gif ce matin, je suspecte des erreurs d'arrondis de calculs mais les sources sont d'un compliqué, c'est l'enfer.

Le souci semble insoluble, pour le moment.

[BeanzMaster]

Le soucis d arrondi que tu soupçonnes vient peut être de Round si elle est utilisée. Ex round(2,5) = 2 et round(3,5) = 4. J ai pas le lien de la doc sous les yeux. Je suis au taf.
Pour ton truc avec les espaces. Comme l a dis Andnotor c'est du a wordwrap et comment il decoupe la ligne. Rien a faire de ce cote je penses.

[Jipété]

Pour ton truc avec les espaces. Comme l'a dit Andnotor c'est dû à wordwrap et comment il découpe la ligne. Rien à faire de ce côté je pense.

On est propres...

De mon côté, j'ai commencé l'étude du DPI-aware, et c'est compliqué, d'autant plus que ça serait plutôt bien implémenté à partir de la 1.8 (voir tout en bas du lien donné), mais je vous rappelle que dans mon contexte de machine virtuelle Debian, Lazarus et le programme ibus sont incompatibles, la preuve ce soir où après avoir arrêté ibus (comme je l'avais récemment écrit), Lazarus continue à me doubler les caractères !

Alors pour taper du code, laisse tomber, surtout avec la complétion qui ne fonctionne que si on tape un "." donc double "." + retour arrière = pas de complétion...
Pµt41n ça fait ch13r !

Bref, avec du copier-coller, le mieux que je puisse faire c'est ça (4 images, je veux rajouter le mot "jolie", il y a déjà "jo" et vous me voyez taper "l i e <espace>, admirez le résultat, moins moche qu'en 1.4.0 mais pas pro pour autant.



Notez dans la caption de la fiche la troisième valeur, qui représente la hauteur du rectangle calculé par DrawText, qui sera utilisé pour la Height du mémo et on peut voir 58 OK, 58 FAUX, 85 OK 85 OK.

[Jipété]

Bonjour,

J'ai une piste : l'espace est parfois considérée (oui, c'est féminin, là) comme un caractère occupant une place qui se mesure, et parfois non, selon là où elle est placée (bout de ligne).

Regardez cette petite animation (3 images) en portant votre attention sur les nombres représentant la largeur (244, 251) et regardez en même temps le curseur qui avance après le "t", sur la petite ligne de saisie :



La largeur du TRect fluctue. Vous trouvez ça normal, vous ?

Ensuite, si je m'amuse à gommer l'espace entre le "t" et le "u", comme il y a la place, le "u" remonte :



Mais si je rajoute une espace après le "u", c'est la loose totale :

[Andnotor]

le mieux que je puisse faire c'est ça (4 images, je veux rajouter le mot "jolie", il y a déjà "jo" et vous me voyez taper "l i e <espace>, admirez le résultat

CW 260 -- Largeur 260. Le calcul est correct mais ClientWidth est plus grand que la partie éditable, il y a la bordure et éventuellement des marges. Remplace ClientWidth par la largeur du rectangle de formatage qu'on obtient par EM_GETRECT : SendMessage(Memo1.Handle, EM_GETRECT, 0, LPARAM(@R));.

La largeur du TRect fluctue. Vous trouvez ça normal, vous ?

Oui, l'espace est remplacé par un saut de ligne de formatage correspondant à #13#13#10. Mais c'est uniquement pour le visuel, ça n’apparaît pas dans la chaîne elle-même (si récupérée par WM_GETTEXT) qui est toujours le texte original.


Après un ou deux essais, je constate aussi que le wrapping n'est pas recalculé à chaque frappe lorsque l'édition à lieu en milieu de texte mais uniquement lorsque la dernière ligne est trop longue. DrawText renvoie une valeur correct mais puisque le mémo n'a pas procédé au wrapping (un petit mot qui tiendrait sur la ligne précédente n'a pas été remonté), une ligne est masquée.
Ce n'est pas un "problème" Delphi ou Lazarus mais bien le comportement du contrôle Windows sous-jacent. C'est gênant ici mais ça parait logique sur de très gros textes, le système passerait son temps à calculer cela.

Même EM_GETLINECOUNT est parfois dans les choux, ce qui influe sur EM_LINEINDEX. Lines.Count renvoie une ligne de trop

Bref, la seule solution fiable que j'aie trouvé est tout bonnement de recréer le composant par RecreateWnd qui va forcer un nouveau WordWrap. Ce qui donne ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
procedure TForm1.Memo1Change(Sender: TObject);
var
  DC :hDC;
  R  :TRect;
begin
  //Evite le flicker généré par RecreateWnd
  LockWindowUpdate(Handle);
 
  try
    Memo1.RecreateWnd;
 
    //Rectangle de formatage
    Memo1.Perform(EM_GETRECT, 0, LPARAM(@R));
 
    DC := GetDC(Memo1.Handle);
 
    try
      SelectObject(DC, Memo1.Font.Handle);
 
      DrawText(DC, PChar(Memo1.Lines.Text), -1, R, DT_CALCRECT or DT_WORDBREAK);
      Memo1.ClientHeight := R.Height +GetSystemMetrics(SM_CYBORDER) *2;
 
    finally
      ReleaseDC(Memo1.Handle, DC);
    end;
 
  finally
    LockWindowUpdate(0);
  end;
end;

[Jipété]

EDIT du lendemain :
J'ai hier posté tout ce qui suit sans avoir vu la réponse d'Andnotor (l'alerte par email lors de nouveaux posts fonctionne bizarrement, des fois, ou alors c'est ma messagerie...)
Résultat des courses faut que je me dépêche d'étudier ce qu'il m'a écrit, ne tenez donc pas trop compte de ce long texte, je le laisse juste pour les images.
/EDIT

Encore plus fort !

Au bout de la ligne, si je rajoute un "u" le bloc passe à la ligne et c'est visible, mais si je rajoute une espace au lieu du "u" le bloc passe à la ligne d'une manière invisible,



Mais encore plus fort que plus fort, si, sur cette ligne invisible terminée par une espace je rajoute des caractères, la seconde ligne devient visible.
Bien.
Alors je rajoute encore une espace au bout de ces caractères ("blah"), en tout état de cause je m'attends à ce que "pqrst" remonte puisqu'il y a la place et que ça se passe comme ça dans les traitements de texte mais là non, damned !



Pour que ça "remonte", il faut que j'enlève le "t".

Et si je clique dans la première ligne du mémo et que j'appuie sur la touche "Fin", le caret s'arrête après le "s", l'espace n'est donc pas considérée,



alors que la même manip sur une ligne courte avec espace finale fonctionne correctement :



On n'est pas sorti de l'auberge...

[Jipété]

Merci à toi de t'être décarcassé pour nous sortir tout ça, cependant n'oublions pas que nous sommes ici dans l'environnement Lazarus dont plein de morceaux, particulièrement sous Linux, ne sont pas finis, ce qui donne ça dans la vraie vie avec la toute récente 1.8.2 ¹ :

Bref, la seule solution fiable que j'aie trouvé est tout bonnement de recréer le composant par RecreateWnd qui va forcer un nouveau WordWrap. Ce qui donne ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
procedure TForm1.Memo1Change(Sender: TObject);
var
  DC :hDC;
  R  :TRect;
begin
  //Evite le flicker généré par RecreateWnd
//  LockWindowUpdate(Handle); // inconnu à la compil, mais on peut faire l'impasse ou trouver autre chose
 
  try
    Memo1.RecreateWnd; // Error: identifier idents no member "RecreateWnd" 
  //...
end;

et face à ça on ne peut rien faire...
---
¹ : testé sous XP dans une vieille 1.6 rc1 avec le même résultat.


Rions un peu, ça nous détendra -- on dira que je trolle, mais ça n'est pas bien grave :

Ne voyant pas le bout du tunnel avec un bête TMemo, je me suis dit que j'allais tenter avec un TSynMemo rajouté dans un projet minimaliste (1 TComboBox [valeurs de 8 à 20 en 2 par 2], 1 TEdit dont le texte sera recopié dans 1 TMemo et c'est tout), puisque c'est présent dans la barre de composants, et si le comportement avec la taille mini est correct (c'est l'autre souci, l'histoire du mémo trop haut si la font est en taille 8, 10, ou 12 -- vous suivez ? ), le problème (car il faut bien qu'il y ait un problème, sinon ça n'est pas du Lazarus) se trouve dans la non-prise en compte des options de qualité de police, look, le TSynMemo est tout en bas, sous le Memo1 :


Le machin n'en a ràf des options de pitch et quality, navrant de chez navrant, d'autant plus que cette copie d'écran est prise sous 1.8.2...

Bah, tout sert à tout in the life, autre sujet sympa découvert lors de mes recherches, pour ceux qui aiment la typographie et ce genre de choses, je suis tombé sur un article très intéressant concernant la justification du texte et en prime les blagues qui surgissent avec la police Segoe UI (à moins que ça n'ait été corrigé depuis) et de là, j'ai découvert le caractère ESPACE qui n'occupe pas d'espace, fabuleux !

Ça va peut-être solutionner le problème des coupures​ ​qui se font sans que le mémo change de taille (exemple : après le mot "coupures" il y a une espace à taille 0 puis une espace normale et encore une espace à taille 0, lol hein ! ça ne se voit pas).

[Jipété]

On vit des trucs, des fois, on se demande...

Exemple avec ce projet minimaliste : 1 TComboBox (valeurs de 8 à 20 en 2 par 2), 1 TEdit dont le texte sera recopié dans 1 TMemo et c'est tout.
Je me suis payé le luxe de forcer la police du mémo sans effets de bord, c'est cool.

Je définis ItemIndex = 0 dans l'edi en ce qui concerne le combobox, donc une taille de police du mémo à 8 et en avant, F9.



Et on constate avec stupéfaction que la hauteur du mémo se resize (parce que, oui, à la création sur la fiche il est plus grand)) à la valeur que j'espère, 16 px, c-à-d que le code ne tient pas compte de ces histoires de MinHeight.

Je peux même jouer à ajouter et/ou enlever des caractères dans l'édit, celui-ci est bien recopié dans le mémo comme prévu et logiquement je dois passer dans UpdateMemoHeight, sans que ça impacte la hauteur du mémo :



Par contre, il suffit que je demande 10 en taille par le combo pour partir dans le plan MinHeight à 35 et là c'est mort, je peux remonter à 8 je ne retrouve pas mon joli mémo à la taille bien ajustée.



Et ce comportement est hélas corrigé en 1.8.2 où l'on trouve donc, dès le 1^er run, un grand mémo et un petit texte :



Qui a eu l'idée stupide de ce rendu aussi moche ?
Comment avoir la main sur la hauteur sans s'encombrer de MinHeight ?

[Jipété]

Bonsoir,

Voilà des nouvelles, une bonne et une mauvaise.

Commençons par la bonne : j'ai lâché l'affaire sous Linux (faut dire aussi que c'est déprimant, cet environnement -- regardez par exemple pour la même police les informations issues d'une structure TextMetric, à gauche le pingouin à droite les fenêtres, comparez les valeurs :

) et j'ai continué sous Windows XP où ça a l'air de se comporter d'une manière sympathique, peut-être suite à l'ajout de AutoAdjustLayout(lapAutoAdjustForDPI, 96, Self.PixelsPerInch, 0, 0); dans la création des mémos.
(hou !, c'est pas bien, je n'ai pas fait la contre-manip, mais patience, patience).

En tout cas c'est satisfaisant :

Tellement que j'ai même carrément supprimé la bordure des mémos.

Tout serait pour le mieux dans le meilleur des mondes mais, je l'avais déjà signalé dans d'autres discussions il y a 2 semaines, certains fichiers font se comporter mon programme d'une manière un peu bizarre, qu'on en juge :


En arrière-plan mon prog où l'on voit à droite un mémo avec le texte d'exemple rendu par la police Charter, que le prog a chargé en utilisant AddFontResourceW, rien de particulier, d'autant plus que je teste la valeur de retour et qu'en l'espèce c'est RAS. (on distingue ensuite le côté gauche des exemples des 4 autres polices chargées).
Tout aurait l'air normal sauf que

• le Bloc-notes, dans sa boîte de dialogue de choix de police ne voit pas Charter ;
• l'outil Table de caractères non plus, alors qu'il voit bien les 4 autres polices : GNUTypewriter, Segoe Print, Veluvana et Zabatana Poster, parfaitement utilisables, donc ;
• pas mis pour ne pas alourdir mais Wordpad et Paint ne la voient pas non plus.

J'ai renommé le fichier en supprimant l'espace, même comportement ; je l'ai carrément renommé en 8.3 et c'est pareil.
Je n'ai pas d'autre idée, et je n'ai pas encore testé avec les autres fichiers que j'ai détecté comme suspects (faut aussi dire que c'est passablement décourageant).

Le bout de code concerné :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
    r := AddFontResourceW(PWideChar(sFontfile));
    if r > 0 then
    {msdn: If the function succeeds, the return value specifies the number of fonts added.
    If the function fails, the return value is zero. No extended error information is available.}
    begin
      FaceName := GetFontNameFromFile(sFontfile, r);
      SendMessage(HWND_BROADCAST, WM_FONTCHANGE, 0, 0);
      Memo4font := AddAMemoForFont(compteur2Memos, FaceName);
    end 
    else
      ShowMessage('Problème avec le fichier ' + FileListBox1.Items[i] + ', qui n''a pas été chargé.');

et je n'ai jamais vu le message du ShowMessage.

Le drame, c'est que ce fichier sous Linux donne une police parfaitement utilisable,
Au secours,

[Jipété]

Ce matin j'ai fait une manip simple : dans XP, double-clic sur des .otf dont je sais que certains n'apparaissent pas dans les logiciels, comme je le disais hier, alors que d'autres oui.

Résultat :


Les 3 premiers n'apparaissent pas dans la Table des caractères, le 4^e oui ; la différence ? Les 3 premiers contiennent les mots PostScript Outlines quand le dernier contient TrueType Outlines.
C'est quoi ces oiseaux ?
5 minutes de ggl et les réponses tombent :
Only TrueType fonts or OpenType fonts that use TrueType outlines (not PostScript outlines) can be used in AutoCAD® products. source

et aussi (où il y a un truc imprécis) :
PostScript data included in OpenType fonts may be directly rasterized or converted to the TrueType outline format for rendering, depending on which rasterizers have been installed in the host operating system. But the user model is the same: OpenType fonts just work. Users will not need to be aware of the type of outline data in OpenType fonts. source
Imprécis puisque, je le rappelle, un double-clic sur un fichier .otf de type CFF sera chargé par le visualiseur de polices mais pas disponible pour les applications .
Le visualiseur n'est pas une application ?
Et mon outil, alors, qui se comporte comme le visualiseur ?

Va falloir filtrer, dans un premier temps :
OpenType fonts that contain TrueType outlines should use the value of 0x00010000 for the sfntVersion. OpenType fonts containing CFF data (version 1 or 2) should use the tag 'OTTO' for sfntVersion. source


En haut une TrueType disponible pour les applis une fois chargée temporairement, dessous une CFF bien chargée mais indisponible.
Me manquerait-il donc un rasterizer ?

Tout ça aurait dû faire l'objet d'un post à part, mais comme j'ai commencé hier ici, bah, je termine ici, ça n'ira pas plus loin que ce point.

Ah, je remets , car si je fais abstraction du MinHeigth du TMemo, différent selon qu'on est sous Linux ou sous Windows, tout est réglé.
<--



PS : j'oubliais : j'ai fait le test avec ou sans AutoAdjustLayout lors de la création des TMemo, je n'ai pas noté de différence. Mais comme il y a une différence de comportement de MinHeight selon l'environnement, peut-être y en a-t-il une également concernant cette affaire de rendu meilleur sous Windows ?

[Jipété]

Une 'tite dernière, histoire de clôturer en beauté : en filtrant sur les 4 premiers bytes des fichiers .ttf et .otf, je détecte "0100" pour les TrueType Outlines et "OTTO" pour les autres, dont les glyphes ne sont pas accessibles aux applis XP SP2 (SP3 peut-être mais je n'en ai pas sous la main, et ok sous Seven), ce qui me permet d'afficher les premiers dans des mémos d'un vert très très pâle et les seconds dans des mémos teintés d'un soupçon de rouge :



C'est beau, hein !