Et tout ça en un seul clic de souris!
Je vous ai fait des captures d'écran des styles disponibles:
http://guytprog.blogspot.ca/2012/04/...ui-ont-de.html
Et tout ça en un seul clic de souris!
Je vous ai fait des captures d'écran des styles disponibles:
http://guytprog.blogspot.ca/2012/04/...ui-ont-de.html
C'est vrai que ça change tout de suite
Il y en a des vraiment sympa et look pro
Je suis en train de regarder le "WinMain" d'une application XE2 et que vois-je?
Ciel! les possibilités sont énormes, comme par l'exemple changer le look de votre application selon le jour de la semaine!
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10
11 WINAPI _tWinMain(HINSTANCE, HINSTANCE, LPTSTR, int) { try { Application->Initialize(); Application->MainFormOnTaskBar = true; TStyleManager::TrySetStyle("Aqua Graphite"); Application->CreateForm(__classid(TfrmMain), &frmMain); Application->Run(); }
(si vous me plussoiyez pas avec ça, je me demande ce qu'il vous faut )
Le pire, c'est que ça marche!
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
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48 #include <vcl.h> #pragma hdrstop #include <tchar.h> #include <Vcl.Styles.hpp> #include <Vcl.Themes.hpp> USEFORM("Unit2.cpp", Form2); WINAPI _tWinMain(HINSTANCE, HINSTANCE, LPTSTR, int) { void* Mutex = 0 ; bool first ; Mutex = CreateMutex(NULL, true, L"AquaGraphite"); first = (Mutex && (GetLastError() != ERROR_ALREADY_EXISTS)) ; try { Application->Initialize(); Application->MainFormOnTaskBar = true; if (first) TStyleManager::TrySetStyle("Aqua Graphite"); else TStyleManager::TrySetStyle("Cyan Dusk"); Application->CreateForm(__classid(TForm2), &Form2); Application->Run(); } catch (Exception &exception) { Application->ShowException(&exception); } catch (...) { try { throw Exception(""); } catch (Exception &exception) { Application->ShowException(&exception); } } if (Mutex) CloseHandle(Mutex) ; return 0; }
Quand je pense que mes collègues de travail trouve déjà que je m'amuse quand je fait des interface un peu fun. Avec Xe2 ils vont carrément me dire que vu comme je m'amuse c'est pas la peine que je sois payé
Hello
Malheureusement le design sous Xe2 avec sa nouvelle version de la VCL
à un coût énorme en terme de taille de l'executable génère ainsi que de son temps de chargement avec un PC normal
J'ai constaté une augmentation de la taille qui peut aller jusqu'à un facteur de 2.8 en regard de la même application générée sous 2010
Je n'appelle ceci pas un progrès mais une régression
À ce rythme la version future XE4 produira des exécutables > 10 MB
Cdlt
En excluant les librairies statiques au profil du RTL et des packages d'exécution, j'ai une application XE2 qui passe de 2 747K à 203K. Mais le prix à payer est probablement trop lourd, ne serait-ce que pour les conflits de bpl et dll.
Ce que j'ai appris avec Borland->Inprise->Codegear->Embarcadero, c'est de ne jamais faire cohabiter différentes versions de Builder sur une même machine. À un moment donné, je travaillais avec Builder 5 avec les étudiants de première, Codegear 2009 avec ceux de troisième et je devais développer un soft de contrôle avec Builder 6 pour un petit centre de recherche rattaché à mon département. Le beau bordel, je vous dis. Heureusement, y a VM Ware.
Pour ce qui est de passer à XE2, dans la mesure où on s'en tient à des applications Win32, je vois pas l'intérêt de passer de 2009 à XE2, surtout quand on regarde la facture. Remarquez, j'ai payé la mienne au prix éducationnel (99$ ), alors je me plains pas.
En fait, ce qui m'intéressait surtout avec Rad Studio XE2, c'était RadPHP, qui m'a déçu, alors je suis revenu à notepad++.
Je m'attendais a du design 3D facile avec Fire Monkey. C'est loin d'être le cas.
Hello
j'ai ouvert un case a ce sujet (104717) sur CodeCentral
en votant et notant cette discussion on amènera peut-être les developpeurs d'embarcadero à prendre en considération ce problème, qui par ailleurs ne touche pas seulement C++ Builder mais également Delphi avec des éxécutables devenus gargantuesque
cdlt
Salut
Tu trouveras CodeCentral dans ton IDE
Je ne connais pas l'URL
Cdlt
Lien vers QualityCentral: http://qc.embarcadero.com/wc/qcmain.aspx?d=104717
Merci pour le lien totoche76.
Refait le même travail avec Borland 5 sous XP.
1 edit, 1 memo, 1 bouton, pas de RTL, pas de paquets d'exécution.
368 K.
Une inflation qui frise les 1 000%!!!
Hello
Une application Client QualityCentral est fournie avec l'EDI
elle est directement disponible depuis un menu
cdlt
Justement en activant les paquets d'execution et la RTL dynamique, cela permet l'échange d'objet entre DLL, EXE et BPL sans trop se préoccuper du ShareMem (bien pénible en D7, bien simplifié depuis l'utilisation de FastMM, je maîtrise cela nettement mois bien en C++Builder qu'en Delphi)
De plus, tu peux avoir un projet composé de 20 EXE et 100 DLL (comme celui dont je m'occupe) qui partagent les mêmes BPL !
J'ai produit dans d'ancienne boîte des Exe avec D7 de 16Mo !
Un jour, j'ai créé une simple DLL qui utilisait 1 fonction de la Lib interne de la société montait à 8Mo (trop d'interdépendance).
En utilisant strictement la VCL, 400Ko !
il n'y a pas que la VCL qui fait gonfler mais aussi les libs externes !
Faux, nos clients utilisent actuellement une version compilée de notre produit en XE2 pour une partie du logiciel et un module complémentaire dont je m'occupe encore en 2007, tous utilisant des BPL (100 et 160) ainsi que des DLL (certaines elles aussi marquées en 100 et 160)
Il suffit juste d'être propre dans son déploiement !
Faux, sur le poste d'un développeur, j'ai actuellement, BCB6, 2007 et XE2 sachant que sur le poste, il a été installé (et désinstallé) un BCB5, 2005, 2006, 2010, XE et XE2 Beta !
A part en débogage où CodeGuard ne semble pas apprécier que 2007 utilise le MidasLib de XE2, cela fonctionne très bien !
2009 est terriblement buggé, XE corrige cela nettement, bon XE2 c'est un autre soucis, c'est vrai !
Perso, j'ai utilisé Zend Studio (Eclipse) ou PHPEdit (regrettée 2.12)
Zend Framework offre côté serveur un très bon support de travail.
Côté Client, un bon petit YahooLib et surtout on reste bien découpler entre client et serveur via XML ou JSON
RadPHP a peut-être le défaut de ses qualités, c'est à dire transposer la VCL au Web, une encapsulation peut être maladroite, le même défaut qu'IntraWeb !
Soit on adhère, soit pas
Cela ne l'était pas avec DxScene, le drag'n'drop a proscrire, ça vise tout le temps à côté !
Merci pour la leçon. ShaiLeTroll
Au plaisir!
Salut ShaiLeTroll
Concernant ShareMem, la problématique existe mois en C++builder car la bibliotèque C ou STL permet de travailler sans elleJustement en activant les paquets d'execution et la RTL dynamique, cela permet l'échange d'objet entre DLL, EXE et BPL sans trop se préoccuper du ShareMem (bien pénible en D7, bien simplifié depuis l'utilisation de FastMM, je maîtrise cela nettement mois bien en C++Builder qu'en Delphi)
De plus, tu peux avoir un projet composé de 20 EXE et 100 DLL (comme celui dont je m'occupe) qui partagent les mêmes BPL !
Il est clair que sur des grands projets comportant un grand nommbre de composants EXE ,Bpl,DLL il est naturellement préférable d'utiliser la RTL et des paquets d'exécutions
cela n'enlève naturellememt rien à la problématique que la VCL devient de plus en plus grande lors de chaque release d'environ un facteur de 1,5.
tu remaqueras également que la taille de VCL.LIB et RTL.LIB grosssit également selon ce facteur
ce phénoméme a terme posera un très sérieux problème de performance
je me suis également intéréssé au ratio des exe générés en delphi ou en c++ builder
qui a également augmenté sous XE2. de 1.1 en 2010 à 1.5 en XE2 ce qui me laisse pensé que le code est moins bien optimisé sous XE2
sous C++ Builder les DLL de la RTL on pour doux non CC32xx.dll et/ou CC32MTxx.dll ou XX correspond au numéro de versionFaux, nos clients utilisent actuellement une version compilée de notre produit en XE2 pour une partie du logiciel et un module complémentaire dont je m'occupe encore en 2007, tous utilisant des BPL (100 et 160) ainsi que des DLL (certaines elles aussi marquées en 100 et 160)
Il suffit juste d'être propre dans son déploiement !
Faux, sur le poste d'un développeur, j'ai actuellement, BCB6, 2007 et XE2 sachant que sur le poste, il a été installé (et désinstallé) un BCB5, 2005, 2006, 2010, XE et XE2 Beta !
A part en débogage où CodeGuard ne semble pas apprécier que 2007 utilise le MidasLib de XE2, cela fonctionne très bien !
pour éviter tout problème de conflit mémoire avec plusieurs applications utilisant des numéros de versions différents il est plus que conseillé de stocker ces dll dans les mêmes répertoires que les composants les utilisant ce qui peut rendre à terme la maintenance du produit difficile
j'ai pour ma part dans les projets que j'ai conduit éviter de travailler avec des versions différentes de DLL qui ont les mêmes fonctionalités
cdlt
Si la RTL grossi c'est qu'ils enrichissent le Framework, n'est-ce pas une bonne chose ? (pour Delphi surtout)
Je ne vois pas en quoi, quelques Ko en plus nuisent au performance, faudrait comparer la courbes d'embonpoint avec les pseudo-loi de Moore
Je pense que le SDK Java, le FrameWork .NET, le PHP qui fanatise la POO (alors qu'il n'était pas conçu pour ça) gonfle aussi à chaque release pour intégrer les nouveautés d'OASIS ou autres idées farfelues d'IBM, ou les Gadgets à la mode !
Tu crains des pertes de performance avec un langage compilé alors que les langages dominants tournent sur des Machines Virtuelles ou sont carrément interprétés !
Pour l'optimisation du code, ça je n'ai jamais compris comment cela fonctionnait, sur MON code, on le voit tout de suite (pas de point bleu ) mais sur le code de la RTL, je pense qu'il n'y a aucune optim, la LIB\BPL est intégré purement et simplement dans l'EXE (c'est ce que je pense, si quelqu'un connait la vérité, je serais ravi de l'apprendre)
C'est un débat récurrent : de [D6] à [XE2] embompoint des exe, la remarque d'exoseven sur les RTTI n'est pas anodines, maintenant cela couvre aussi les propriétés publiques, protégés et privés et pas que les propriétés publiées, ce qui doit occuper nettement plus de place, facilement 3 à 5 fois plus !
Le fait que l'exécutable soit de plus en plus gros ne me semble être un faux problème. Les machines actuelles ont pas mal de mémoire de plus il est possible que le tout petit code de 100ko bouffe énormément de mémoire.
En plus la taille de l’exécutable ne reflète pas sa taille réelle. C'est le cas si on installe ce programme sur une autre machine on se retrouve à copier aussi des dll des bpl ce qui revient au même.
Le code grossit tout simplement parce que de plus en plus de fonctionnalités sont prises en compte (gestion des écrans tactiles à plusieurs points de contact par exemple). C'est sur que c'est pas nécessaire pour faire un "Hello world" mais en général les application sont un peu plus sofistiquées que ça
Hello
Pas d'accordEn plus la taille de l’exécutable ne reflète pas sa taille réelle. C'est le cas si on installe ce programme sur une autre machine on se retrouve à copier aussi des dll des bpl ce qui revient au même.
je parlais d'un executable autonome ne nécessitant pas de composants externe BPL ou DLL
dans ce cas naturellement la taille de l'exécutable diminue fortement mais dans ce cas la taille des BPL déployés(RTLxxx.bpl,VCLxxx.bpl) doit être prise en compte
XE 2
VCL: 3.24 Mb
RTL: 2.74 MB
2010
VCL: 2.33Mb
RTL: 1.7 Mb
cdlt
Partager