Problème de lancement de la quasi totalité de toutes mes fiches suite à une migration

Bonjour,
Un problème étrange s'est passé lors d'une migration d'un de mes projets de Delphi XE vers Delphi 10.2.3 Tokyo. Les OS pris en charge pour cette nouvelle version sont : Windows 7 et Windows 10.
Avant, avec la version Delphi XE, toutes les fiches se lançaient rapidement, quasi instantanés avec de gros appels à la création ou à l'activation du formulaire et des appels à des chargements de la base de données. Le jeu de composants tiers que j'ai est classique : de l'Unidac, DevExpress
Une fois l'application migrée vers Delphi 10.2.3 : les choses ne sont plus pareilles du tout, l'application lague dans tous les sens et ce qui est étonnant c'est que une fiche qui mettait 404 nanosecondes pour s'ouvrir (profiling fait avec ProDelphi) met maintenant 1 minute et plus pour se lancer :weird:
Je précise que sur une fiche (où je suis entrain de charger 1200 paramètres de la base de données dans le OnFormCreate et qui se lançait rapidement et sans problèmes avec la version compilée avec Delphi XE) : elle commence à clignoter sans cesse et à ramer avant de s'afficher au bout d'une minute :(:(
Comme par hasard, j'ai mis un point d'arrêt sur le OnCreate de cette fiche , j'ai fait le pas-à-pas mais ça ne m'a ramené à rien du tout.
Un autre point d'arrêt, mais avec un F9 direct et là , la fiche s'ouvre directement comme au bon vieux temps !
si on met en arrière plan l'application ou qu'on la réduit même pendant l'appel à la création d'une fiche, cette dernière s'ouvre quasi-instantané :roll:
Je ne sais pas si c'est un problème : avec L'OS , avec l'EDI ? j'ai essayé de désactiver tout ce qui Aero Peek , machin mais ça ne m'a amené à rien du tout :calim2:
Quelqu'un a-t-il rencontré ce problème ? Si oui, avez-vous une solution pour le régler ?
Merci d'avance :D:D

Bonjour,

>> dans le OnFormCreate et qui se lançait rapidement et sans problèmes avec la version compilée avec Delphi XE) : elle commence à clignoter sans cesse et à ramer avant de s'afficher

comment une application peut-elle clignoter dans le FormCreate ? la procédure contiendrait-elle des Application.ProcessMessages ?

Bonjour
Merci Paul pour votre réponse.
Une fouille corporelle minutieuse à ma source m'a démontré que la piste de ces composants tiers amenait vers la reproduction du problème.
J'ai migré les composants DevExpress et Devart vers la nouvelle version de Delphi 10.2.3
Si je prends un exemple d'un FromCreate où j'appelle le chargement ponctuel de 1200 paramètres , ça ne me posait pas de problèmes avant. Il est à savoir que commit les transactions vers la base avec un Transaction.commit quelque soit l'état du TDataSet ( en open , post ou en Execute )
Cependant, avec le nouveau jeu de composants de Devart j'ai commencé par désactiver ce chargement, j'ai plus le problème. Je remets le chargement, j'ai le problème. Si je passe sur un point d'arrêt ou que je change de fenêtre, la fiche en question se charge rapidement.
J'ai désactivé sur ma fonction générique qui contient le commit de la transaction et qui est appelée 1200 fois le code suivant :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

try UniQuParamSoc.ParamByName('SocParam').AsString := SocParam; UniQuParamSoc.ParamByName('SocUser').AsString := SocUser; (*   Select SocValue   from ParamSoc   where SocParam = :SocParam AND SocUser = :SocUser   *) try UniQuParamSoc.Open(); result := UniQuParamSoc.FieldByName('SocValue').AsString; finally UniQuParamSoc.Close; // if (UniQuParamSoc.Transaction.Active) then // UniQuParamSoc.Transaction.Commit(); end;

---

et là , je reproduis le problème.
Reste à voir quel est le point qui bloque autant les transactions commitées ( et qui n'avaient pas de problème auparavant sur la version Delphi XE ) et fixer ce bug de validation des transactions définitivement.
Une petite note : la version Unidac de Devart installé sur mon IDE Delphi 10.2.3 est la 7.4.11
Celle qui est installée sur mon IDE Delphi XE est la 4.6.12
Problème à suivre ...:zoubi::zoubi:

s'il est question uniquement de lire les paramètres, il faut basculer ReadOnly à True, cela accélère grandement les choses

Je me penche surtout sur le fait que le commit des TUniTransaction des composants Devart bloque le Thread principal de l'application.
Ce qui est bizarre c'est que cela peut être contournée par une simple réduction-restauration de la fiche MDI mère.
J'ai vu un peu sur les forums de Devart, la désactivation de tous les commit de mes transactions remet les pondues à l'heure et je retrouve les performances de mon application. Il reste à comprendre pourquoi on a fait des commit sur des TUniQuery qui ne servent à rien du tout pour le moment.
Je regarde aussi les propriétés du ReadOnly de ce descendant de TDataSet car je veux éviter de faire virer tous les Commit de mes TUniTransaction dans les source de mon projet : j'en ai des millions :aie::aie::aie:

Sinon à quoi sert un Commit sans UDPATE\INSERT\DELETE ?
Idem par habitude, ReadOnly je pratique beaucoup

Bonjour :lol:

Je reviens un peu à ce petit sujet. Il s'agit d'un bug connu de Delphi 10.2 Tokyo sous Windows 10.

En revenant vers Windows 7 avec la même version, je n'ai reproduit aucun des problèmes suivants :

• Lenteur de chargement de l'EDI.
• lenteur de compilation.
• lenteur remarquable de chargement de mes fenêtres.

Le sujet est déjà abordé dans plusieurs forums et Blogs :

http://blog.marcocantu.com/blog/2017...rs-update.html
https://quality.embarcadero.com/browse/RSP-17972
https://forums.embarcadero.com/threa...hreadID=249463
https://stackoverflow.com/questions/...omes-very-slow
https://stackoverflow.com/questions/...stom-bpl-files
https://forums.embarcadero.com/messa...ssageID=706807

Je n'ai pas testé la nouvelle version 10.3 Rio sous Windows 10 mais je conseille les développeurs qui sont sous Windows 7 de garder leur OS en attendant la confirmation de la correction de ces bugs par Embarcadero.
J'ai compris aussi que cela ne dépend pas de Embarcadero uniquement mais surtout de Microsoft avec les nouveaux correctifs déployés pour Windows 10.
J'ai compris aussi que la mécanique de chargement des dll (et donc des packages dans Delphi) appliquée par Microsoft a changé ce qui a provoqué cette déstabilisation au niveau de Delphi 10.2 ( je ne suis pas capable de confirmer si cela est aussi le cas des versions antérieures de l'EDI ).

Bonne journée :)