Discussion :

[Jipété]

Bonjour,

Une idée pour contourner le problème cité en titre ?

Soit une bête form avec un bête mémo et un bête bouton (et des edit).

Le mémo est censé afficher des infos d'un fichier choisi avec le bouton qui appelle "OpenDialog".
Pour aller vite en phase d'étude, je fais ouvrir le fichier dans Form.Create.
Et pour faire mon code propre, j'ai écrit une ch'tite procédure qui reçoit le nom complet de fichier, en récupère les infos et les affiche dans le mémo, procédure appelée au Form.Create et au clic sur le bouton.

Lorsque je lance le prog tout s'exécute bien sauf que le mémo est vide
Si je clique sur le bouton et que je choisis le même fichier, le mémo est plein.

Et c'est bien lié au mémo car la petite proc affiche correctement d'autres infos du même fichier dans des edit.

J'ai bardé la proc Form.Create de Show, Repaint, Application.ProcessMessages, ça ne change rien et je suis à court d'idée...

Je précise à tout hasard que le portage sous Delphi de ce petit prog fonctionne parfaitement, mais là c'est Laz 1.0.10 FPC 2.6.2 sous Debian 32 bits.

Ce qui est très ennuyeux, c'est que j'ai écrit "parfois" en titre, car le même genre de démarrage de prog fonctionne bien dans un autre projet, à lire ici.
J'y perds mon latin

Merci de vos pistes,

[Invité]

Bonjour,

Bonjour,

... et les affiche dans le mémo, procédure appelée au Form.Create et au clic sur le bouton.

Ce qui est très ennuyeux, c'est que j'ai écrit "parfois" en titre,...

Ce qui est ennuyeux en effet, c'est le "parfois". Sous Linux, les séquences d'événements ne sont pas toujours identiques à celle de Windows. Cela a fait l'objet d'un post avec Jean... Je ne pense pas que dans le cas précis cela vienne de là.

Utilisez-vous des streams ou autre opération qui pourrait être "naturellement" threadés (ie à l'insu de votre code explicite) ? Dans ce cas, les temps "de remontée" pourraient être aléatoires, des fois avant l'exécution des événements du thread principal donc affichage, des fois après...

Cordialement. Gilles

[Jipété]

Bonjour Gilles,

et merci de cette réponse.

Concernant cette histoire de threads cachés, je serais bien incapable d'y répondre, une chose est sure, ma petite procédure en appelle d'autres qui, oui, font appel aux streams.
C'est grave, docteur ?
J'ai tenté de rajouter Application.ProcessMessages et autre Sleep(2000) à la fin de ma procédure, mais pas mieux.

Par contre je viens de noter un comportement curieux, qui démontre qu'il y a bien un vice caché dans le mémo (ou dans le fourbi qui le crée) : un bête ShowMessage de son nombre de lignes en fin de procédure m'affiche un résultat correct, alors que sous mes yeux l'animal est vide de chez vide !
"Clic droit / Sélectionner tout" est disponible mais ensuite "Clic droit / Copier" est grisé.

Autre essai : pour en avoir le cœur net, j'ajoute un TRichmemo au projet, et bien sûr je modifie la procédure de log en conséquence :

Code :

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

1
2
3
4
5
procedure TForm1.Memo(s: string); 
begin 
//  Memo1.Lines.Add(s);
  RichMemo.Lines.Add(s);
end;

Comportement identique...
Bon, vous me direz, si le TRichMemo se base sur le TMemo, ça semble logique.

Et donc, si j'utilise une TListBox, ben là j'ai un comportement normal (mais je perds les avantages du mémo pour le debug et l'étude).


Petite précision :

Ce qui est ennuyeux en effet, c'est le "parfois". Sous Linux, les séquences d'événements ne sont pas toujours identiques à celle de Windows.

Quand je dis "parfois", ça sous-entend un comportement différent entre des projets, et pas des fois oui des fois non dans le même projet, le tout étant toujours sous Debian.
C'est pour être sûr de mon coup avant de poster que j'ai testé sous Delphi dans ma VM 2k.

[Invité]

Quand je dis "parfois", ça sous-entend un comportement différent entre des projets, et pas des fois oui des fois non dans le même projet, le tout étant toujours sous Debian.
C'est pour être sûr de mon coup avant de poster que j'ai testé sous Delphi dans ma VM 2k.

J'avais en effet mal compris... Donc mon explication n'est sûrement pas la bonne.
Pfffffffff... Le TRichMemo me rend nerveux J'y ai passé trop de temps !

Vous avez essayé en plaçant votre code dans un OnShow plutôt qu'un onCreate ? J'utilisais ce dernier le moins possible justement avec les problèmes* d'objets graphiques... Mais récemment, je ne me souvenais plus pourquoi... C'était devenu une habitude...

Mais je le réécris, j'estime que c'est vraiment le défaut majeur de Lazarus (avec celui d'être incapable de lire les entêtes C++ évidemment)... La gestion des objets graphiques est bâclée, mal terminée et mal mise à jour. En réalité, "ils" sont partis de Delphi et ont adapté au mieux (au moins pire) le pilotage des widgets Linux... Je crois que ShaiLeTroll avait raison... pour cette partie et d'autres aussi.... J'ai découvert cela avec C++/QT... J'aurais préféré avec Delphi mais C++/QT m'a semblé finalement (ie "raisonnablement") plus abordable que FMX... pour plus de possibilités.

Ce n'est pas vraiment le lieu pour faire de la pub mais pour un vieux Delphiste comme moi qui a pratiqué le C autrefois et s'est formé -un peu péniblement au début à la POO grâce à l'approche qu'impose l'utilisation de Lazarus et de son code ouvert-, ce "produit" vaut vraiment un minimum d'attention et progresse vraiment significativement à chaque version. J'ai commencé avec la version 4.8 et un livre "QT4 et C++" de Jasmin Blanchette et Mark Summerfield qui à mon avis est pour le C++/QT, l'équivalent de ce qu'est le livre Delphi 7 de Paul Toth... Rien que de le lire, on a envie de pratiquer !

Pour Lazarus, il y a un petit espoir, lors du passage à gtk3 car plusieurs programmeurs ont manifesté le désir de repartir à zéro... Ils sont conscients que l'approche gtk2 est bricolée et au bout du rouleau... si le bout a été atteint, ce dont je doute.

C'est ce qui m'a fait prendre (obligé de prendre) du recul avec Lazarus et je ne le regrette pas du tout. Si un peu quand même, je regrette le Pascal. Enfin, le QT/C++ a accentué mes reproches à ce niveau, quant à sa possibilité d'incorporer n'importe quelle librairie C++, je n'en parle même pas.

Il ne m'est plus possible (ie je n'en ai plus la volonté) de perdre des heures sur un malheureux TMemo, TRichMemo, ou d'autres bibliothèques parce qu'on ne "passe" pas de Win 32 à Win 64 ou de Linux 32 à Linux 64 ou de Win 32 à Linux 32... Je ne parle pas de macOS !... en 64, il n'y a rien ou presque...

Bon courage et bonne fin de journée.
Cordialement. Gilles.

*des réactions différentes sous les OS différents.

[Jipété]

Vous avez essayé en plaçant votre code dans un OnShow plutôt qu'un onCreate ? (...)

Bingo !

Merci pour l'idée, je n'y avais pas trop pensé, le nez sur le guidon !