Nous avons une application de taille moyenne à grande taille. Une version se déroule sur Delphi 6 et une autre sur Delphi 2006.
Un argument serait un support pour Unicode. Nous avons besoin de cela pour répondre aux clients du monde entier.
Autres choses que j'ai lues sont: Better IDE (stabilité, vitesse), meilleure aide et quelques ajouts frais à la langue (par exemple, génériques)
Qu'en est-il des composants tiers? Nous utilisons Devexpress, Dbisam et beaucoup d'autres. Sont-ils déjà portés?
Touch / Gestes Son Cool, mais nous n'avons aucune utilité pour cela dans notre application.
12 Réponses :
Les outils de refactorisation et globalement la vitesse et la stabilité de l'IDE vont rendre l'équipe de développement plus productif.
Utiliser avec les derniers outils facilitera la recrute des meilleurs talents.
purement comme une mesure réactive. Disons qu'il existe une nouvelle fonctionnalité de la dernière version d'un système d'exploitation non rémunéré. Disons que cette fonctionnalité brise certaines fonctionnalités à l'intérieur de votre application. S'il devait y avoir une solution globale pour cela, il ne serait probablement pas placé dans des versions plus anciennes du compilateur, mais les versions les plus récentes qui soutiennent le nouveau système d'exploitation. Le problème le plus important sur l'attente est trop long, c'est que lorsqu'une telle mesure est nécessaire, c'est généralement à l'heure zéro lorsque les ventes sont à risque.
Mise à niveau maintenant et aider à préparer votre demande à être plus réactive aux changements futurs.
Je ne serais pas si rapide à verrouiller cela. Les modifications apportées à mes applications Delphi 7 "Vista" capables fonctionnent réellement mieux sur Windows 7 que les fonctionnalités "Vista" ajoutées à Delphi 2007+. Juste parce que c'est "dans la boîte" ne signifie pas que c'est la meilleure solution. Et avec Delphi, contrairement à .NET ou quelques autres, la séparation plus claire entre le compilateur et le cadre - VCL - et le fait que le cadre peut être mis à jour même dans les anciennes versions fournies avec des compilateurs plus âgés à peu près nullifie le "doit rester à jour à jour " argument.
L'ajout de dialogues spécifiques à Vista sur Delphi 7 fonctionne mieux sur Windows 7 que ceux ajoutés à Delphi 2007+? Et le dessin thématique de TDrawGrid / TstringGrid / TDbgrid (qui n'existait pas dans D7) fonctionne mieux que ceux ajoutés à Delphi 2010? Et que diriez-vous de ce contrôle de ruban à Delphi 7 - fonctionne-t-il mieux que celui de D2009 +? :-)
@Deltics, c'est tout un risque. Vous risquez de rester, vous risquez de la mise à niveau. Je voulais juste souligner que si il y avait une "fonctionnalité de rupture de programme" implémentée dans le système d'exploitation Dernier , que les modifications du compilateur ne seraient probablement pas implémentées dans la précédente versions qui n'ont jamais soutenu le système d'exploitation en premier lieu.
Le contrôle de ruban de DevExpress fonctionne bien mieux que celui de Delphi 2009 qui est tellement brisé pour aller au-delà d'une blague. Celui à Delphi 2010 cherche à être fixé enfin. Maintenant, j'ai juste besoin de corriger le reste de mon application à la suite des ruptures d'unicode de mon code et de tous les composants que j'utilise, puis je pourrais peut-être l'utiliser.
Better Theme Support (par exemple, TstringGrid / TDBGrid prend désormais des thèmes).
prise en charge de Windows Vista et Windows 7, y compris la prise en charge de la toile Direct2D dans Win7 et le support Touch / Gestture que vous avez mentionné.
Amélioration du refactoring, y compris la prise en charge des génériques refactorisants.
formateur de code source intégré.
IDE Insight vous permet de trouver des choses dans l'IDE lui-même.
RTTI amélioré.
Améliorations du débogueur, y compris de nouveaux visualiseurs de données personnalisés et la capacité de créer votre propre. Il y a deux inclus avec la source (une pour TdateTime et une pour Tstringlist). Mieux vaut mieux prendre en charge les threads de débogage, y compris la possibilité de nommer des threads pour déboguer et définir des points d'arrêt sur des threads spécifiques.
La possibilité d'ajouter la prise en charge de la version de la version à l'IDE via des interfaces. Cela permettra aux développeurs de contrôle de la version d'ajouter du support directement dans l'IDE lui-même.
L'aide est bien meilleure que dans les versions précédentes. Il a été complètement repensé à nouveau et est beaucoup plus complet et complet. Il existe également une version en ligne basée sur la wiki (utilisée pour générer l'aide elle-même) que vous pouvez ajouter ou modifier.
Compilation d'arrière-plan vous permet de continuer à fonctionner pendant que vous compilez votre projet.
En ce qui concerne les contrôles tiers, cela dépend du vendeur spécifique; Vous devrez vérifier si les versions DELPHI 2010 sont disponibles pour chacune d'elles individuellement. (Vous pouvez vérifier le site Web de Embarcadero, cependant, pour voir s'ils ont une liste déjà disponible; Je semble me rappeler l'audition d'une ... Ah, oui.
article 9 du Test de Joel: 12 étapes pour mieux coder est:
Utilisez-vous que les meilleurs outils peuvent acheter?
Peut-être que cet argument est germe ici.
D'autre part Si vous conservez un code hérité et que vous ne générez rien qui a une dépendance sur les nouvelles fonctionnalités du système d'exploitation ou de l'outil, il s'agit d'un argument difficile à gagner. Je ne recommanderais toutefois pas de générer des projets entièrement nouveaux sur des outils anciens.
Unicode a été pris en charge sur Windows depuis au moins NT 4.0 et pour Windows 95/98 / moi depuis l'ajout de MSLU en 2001 - si sûrement Delphi 2006 le supporte !? [modifier] Non pris en charge complètement dans la bibliothèque de composants, il semble. [/ modifier]
Je suggère que le seul argument convaincant consiste à assurer une compatibilité Vista et Windows 7. Je comprends que le soutien ciblé 64 bits était prévu pour Delphi cette année. Qui peut être un autre argument; Mais encore une fois, cela ne s'applique que si vous avez l'intention de cibler une telle plate-forme, et de manière à donner un avantage tangible sur 32 bits de code. [modifier] J'ai souligné planifié parce que je ne savais pas si cela l'avait fait dans le produit, mais que cela pourrait être une contrepartie pour vous. Il semble que ce ne soit pas, donc l'argument que vous mettez à la direction pourrait être encore moins fort. [/ EDIT]
La direction ne sera pas impressionnée par le "Je veux juste que les outils cools jouent avec", vous devez l'aborder sur une base "retour sur investissement" (ROI). Voulez-vous obtenir votre produit plus rapidement ou moins cher à l'aide de cet outil? Les outils existants sont-ils une barrière technique au progrès? Inversement, tenez compte de savoir si le temps de passer du temps à porter votre code hérité sur de nouveaux outils (avec la validation et les tests associés) tuera vos budgets et vos délais sans avantage commercial?
Enregistrez vos commentaires snarky. Delphi est tombé derrière dans de nouvelles fonctionnalités pendant quelques années à cause de certaines décisions suicidairement stupides de son propriétaire précédent. Il appartient à une nouvelle société maintenant, une personne qui le prend au sérieux et que ces problèmes ne s'appliquent plus.
Aucun de vous n'a pas utilisé Windows NT 3.1? Qu'y a-t-il avec l'idée étendue que Unicode "support" a été ajoutée par magie dans la version 4? C'est quelque chose que l'ensemble du système d'exploitation a été construit, pour citer Wikipedia: "Windows NT a été l'un des systèmes d'exploitation les plus anciens à utiliser Unicode en interne." L'API publique fournit simplement une ANSI ( onefunca ) et Unicode ( quelquefuncw ) de la plupart des fonctions en plus de cela. Interne Tout est Unicode et a toujours été.
De plus, 64 bits ont été planifiés (et promis) depuis des années et ne sont jamais matérialisés. Pas à Delphi 2010 non plus. C'est donc un autre argument, mais pas un pour la mise à jour de Delphi 2010, au contraire ...
@ Mason Wheeler: Ce n'est pas la propriété ni la qualité qui me concerne. Mais le sens commercial de parier votre maison d'une langue propriétaire constitue un seul fournisseur. C'est un outil de programmeur fin; La vente de son utilisation à un gestionnaire concerné par la protection des investissements est une chose différente. Cependant, les commentaires que je crois que vous faisiez référence à avoir été supprimé.
Depuis que vous l'avez cité, le NT 4 Commentaire provenait de l'article Unicode de Wikipedia, indiquant "Microsoft Windows puisque Windows NT 4.0 prend en charge WGL-4 avec 652 caractères", mais dans son contexte, il ne dise pas que les versions précédentes n'ont pas soutenu d'autres normes Unicode. ; Je suis donc corrigé et j'ai changé le texte.
@ Gghie: Bien sûr, Unicode existait à Winnt 3.1. Cependant, Delphi a soutenu Win95, 98, et moi aussi, qui n'étaient pas unicode. Puisque NT était une petite partie de la petite partie du marché à l'époque, il a beaucoup plus de sens de soutenir les autres saveurs de Windows (utilisées dans de nombreux autres maisons et entreprises). Et vos commentaires sur 64 bits sont juste un argument de paille et n'ont pas de place ici; Personne ne discute de 64 bits. La question posait des raisons de passer à la D2010, que le monde entier sait n'est pas 64 bits.
@Ken: J'ai commenté la réponse de Deltics 'Reproduction de l'Unicode, bien sûr, il aurait dû être facultatif, comme des programmes MFC pourraient être construits pour ANSI ou Unicode. Deux ensembles de fichiers DCU et un commutateur de compilateur (je sais que ce n'est pas si facile, mais toujours). Mais ignorer UNICODE pendant près de dix ans nous a amenés à la problématique actuelle que Deltics décrit correctement. Quant à 64 bits, je n'ai fait que commenté la partie de la réponse citant un soutien 64 bits comme un autre argument. Cette partie de la réponse semble suggérer que non "le monde entier" connaît le manque continu de soutien de 64 bits.
Avec la version ancienne de Delphi (avant Delphi 2005), vous n'avez qu'avec le 1er janvier 2010 pour mettre à niveau.
Une fois que vous devrez acheter une version complète.
D2006 était une version terrible de DELPHI. Il vaut la peine de mettre à niveau juste pour se débarrasser de toutes les fuites de mémoire et des accidents de l'IDE aléatoires et des problèmes. Justifiez-le au patron comme une diminution massive de la productivité perdue. Cela signifie moins d'argent gaspillé vous payer pour ne pas produire de code parce que vos outils de développement ne fonctionnent pas. Ça va payer pour elle très vite sur cette base seule.
Tant que D6 vs. D2010, c'est un argument de fonctionnalité. Commencez avec la réponse de Skamradt, qu'elle aide votre code à être futurs. Soulignez-le avec la compatibilité du système d'exploitation. D2007 a été la première version qui comprend Vista. D2010 est la première version à comprendre Windows 7. Si vous compilez une version plus ancienne, votre application est obsolète avant même de le déployer, car il n'y a aucune garantie qu'il est compatible avec les versions modernes de Windows.
Ensuite, vous avez des fonctionnalités de langue réelles. Les grandes améliorations imo de 2006 à 2010 sont des génériques, ce qui contribue à toutes sortes de tâches répétitives et à RTTI étendue. Robert Love fait de superbes messages de blog ces derniers temps sur la manière dont la RTTI étendue peut simplifier les problèmes courants du monde réel. (Plus unicode, bien sûr.)
L'IDE est définitivement une étape de Delphi 6 et / ou Delphi 2006.
Si Unicode est important pour vos clients, alors Delphi 2009/2010 est une option claire. Mais si Unicode est important pour vous , plutôt que vos clients, alors je ferais attention.
Unicode n'est pas "gratuit". Si vos utilisateurs / clients concernent l'empreinte de mémoire WRT et / ou les performances, et / ou votre application implique une manipulation de chaînes étendue, alors Unicode exige un prix que tous vos clients devront payer et pour les clients qui ne sont pas eux-mêmes concernés par le soutien de l'Unicode, ce prix vient avec zéro avantage (à eux).
De même si votre application est assise sur un schéma de base de données activé actuellement non unicode. Migration des bases de données existantes de Non-Unicode en Unicode est non triviale et si vous avez des clients avec de grandes bases de données de production, entraînant des temps d'arrêt pour ces clients pendant qu'ils migrent leurs magasins de données sont quelque chose que vous devez examiner attentivement.
De plus, vous devrez également être très conscient de toutes les interfaces à des systèmes externes - votre code sera unilatéralement "Go Unicode", ce qui peut avoir une incidence négative sur des interfaces externes à d'autres systèmes pas . < / p>
Dans de tels cas, vous feriez bien de relier la transition vers UNICODE avec d'autres améliorations et avantages convaincants pour rendre la transition convaincante pour d'autres raisons.
En outre, si vous avez des clients réellement ayant un besoin réel de VRAI Unicode, la transition n'est pas aussi simple que de recompiler avec le dernier compilateur et le plus grand compilateur et VCL. Le support VRAI Unicode impliquera beaucoup plus de travail dans votre code d'application que vous pourriez d'abord apprécier.
Bien sûr, avoir un compilateur / VCL capable Unicode est un composant crucial, mais ce n'est pas une réponse à son propre.
Le changement Unicode a un impact significatif sur les composants tiers. Même si vous avez la source de votre code 3ème partie, vous pouvez vous retrouver face à des problèmes Unicode dans ce code, à moins que le fournisseur ait pris des mesures pour mettre à jour ce code dans une version plus actuelle. La plupart des bibliothèques de fournisseurs actuelles sont ONUICODE à l'heure actuelle, alors que je pense, à moins que vous n'utilisez plus une bibliothèque qui n'est plus pris en charge par le fournisseur, vous devriez être correct sur ce score.
Je voudrais également faire preuve de prudence lorsqu'il s'agit de ces caractéristiques de langue "cool" telles que des génériques. Ils ont bien l'air cool, mais ils ont des caractéristiques limitatives sérieusement que vous rencontrerez à l'extérieur des manifestations de fonctionnalités et peuvent entraîner des difficultés de maintenance et de débogage car l'expérience de la communauté en travaillant avec eux est limitée, de sorte que la «meilleure pratique» n'a pas encore été possible. émerger et que le support de l'outil n'a peut-être pas encore rattrapé les utilisations sur lesquelles ces fonctionnalités sont placées en code réel.
avoir dit tous que ... Etant donné que vous ne pouvez pas choisir de manière réaliste une version autre que Delphi 2010 de passer à la mise à niveau, alors si vous allez mettre à niveau, vous devez mordre la balle UNICODE Et vous trouverez-vous présenté avec beaucoup de fonctionnalités de langage tentant à Tinker avec et vous distraire. ;)
Et maintenant que Embarcadero impose une politique plus draconienne des produits de mise à niveau des qualifications de WRT, vous aurez
+1, bien que je pense que bon nombre des arguments présentés contre Unicode sont causés par l'adoption tardif de l'Unicode par la VCL seule. La plupart d'entre eux (comme des problèmes de performance, le support manquant par des composants tiers et des systèmes de base de données incompatibles) ne seraient pas des problèmes actuels maintenant si le passage aux longues chaînes de Delphi 2 avait été fabriqué de manière à soutenir ANSI et Unicode , comme même le tout premier Win32 SDK le faisait.
BTW, la prise en charge de l'Unicode est importante pour tous les clients, à moins que vous n'ayez aucun endroit dans le logiciel où les noms ou adresses des personnes ou noms de fichiers sont traités. Ou préférez-vous limiter vos clients à ceux avec des noms et des adresses ASCII uniquement? Ou dites-leur qu'il est totalement inévitable que leur nom soit montré complètement mutilé, ou ne peut-il pas être entré du tout?
Vous êtes tout simplement faux. Unicode n'est pas important pour tous les clients du tout - si Delphi n'aurait jamais devenu si largement utilisé sans support unicode ni survécu si longtemps sans cela. Il y a toujours eu des moyens de gérer les non-ASCII. Unicode n'est que une de cette manière, et il est loin d'être universellement reconnu comme la "bonne" solution. Unicode n'est qu'un seul jeu de personnages parmi beaucoup.
UTF8 est moins coûteux en mémoire et un grand nombre d'applications seraient mieux à l'aide de UTF8. UTF32 est plus efficace et plus facile à travailler avec le traitement des chaînes UNICODE normalisées, et toute application faisant une manipulation de chaînes grave devrait absolument normaliser. La prise en charge des codages autres que UTF16 dans la mise en œuvre Delphes est au mieux. C'est un choix qui aurait pu être effectué dans la mise en œuvre et n'est pas inhérent à Unicode en soi.
Et je ne discutais pas contre Unicode, en soulignant simplement certains aspects souvent négligés.
J'ai compris que vous n'ayez pas discuté contre Unicode, je soulignais simplement que certains des aspects sont de la part de Borland. Re Unicode n'étant pas important pour tous les clients - c'est une idée courante chez les personnes qui n'ont jamais vu ou ne se soucient pas des gens qui entrent dans leur nom turc ou vietnamien dans un programme Win1252 ANSI. Mais continuez dans votre ignorance, c'est très répandu, j'ai lu que Même UPS ne peut pas imprimer d'adresses internationales appropriées avec leur logiciel. Pour ce qui est que "Unicode n'est qu'un seul jeu de caractères parmi beaucoup" - sage up ou arrêt de conférence. Vous êtes tout simplement faux.
Ce n'est que l'ignorance si c'est une fausse hypothèse. Mais ce n'est pas toujours une fausse hypothèse. Pour un ISV vendant directement à des clients spécifiques, ils connaissent si Unicode est essentiel ou non pour leurs clients, et par définition un ISV à l'aide de Delphi 1 à 2007 a des clients pour qui unicode n'est pas un problème. Ces jours-ci une hypothèse beaucoup plus commune et absolument fausse est qu'une compilation réussie sans avertissements dans Delphi 2009/2010 == une "application Unicode". C'est tout à fait et absolument faux si vous n'avez pas entrepris de changements plus profonds et plus importants dans votre demande.
Jouer à l'avocat des diables, il peut y avoir des raisons de ne pas mettre à niveau. Par exemple, vous pouvez manquer la source de certains composants ou vous devez toujours prendre en charge Win9x.
Je pense que vous trouverez probablement la meilleure raison de mettre à niveau (laissant toutes les nouvelles fonctionnalités Wizz-Bang) est que vous serez de manière significative plus productive dans la nouvelle IDE. Si vous ne faites pas / que vous ne pouvez pas mettre à niveau, je vous recommande de saisir une copie de Castalia, qui peut vous donner accès à de nombreuses améliorations de productivité (par exemple refactoring) dans Delphi 6.
DBISAM est mis à jour, je viens de les envoyer cette semaine après un projet, j'espère pouvoir passer de Delphi 3 à Delphi 2010.
Tous les autres packages que j'ai examinés dans la mise à niveau de ce projet (wptools, InfoPower, TMS) Tous les sites Web sur leurs sites Web offrent une compatibilité avec 2010.
Je n'ai jamais eu d2006 (j'ai 2007), je ne peux donc pas parler de défauts dans cette version particulière (D2007 n'est-ce pas si génial, non plus), mais c'est généralement un bon principal pour garder vos outils de bonne forme. Pour une scie qui signifie pointe, pour le logiciel qui signifie actuel. Surtout dans une nouvelle année, vous souhaitez probablement la version correspondante de votre environnement de développement principal.
listes de composants compatibles qui prennent déjà en charge Delphi 2010, y compris DevExpress (article seront périodiquement mis à jour à partir de notre base de données de partenaires technologiques) est à
http://edn.embarcadero.com/article/39864
argument - dizaines de milliers d'outils et de composants disponibles pour les éléments dont vous avez besoin, en plus de l'API (S) ouvert (s) pour les composants et l'IDE.
Ne le convainquez pas pour une mise à niveau Delphi 2009/2010, faites-la pour une assurance logicielle.
Merci pour la suggestion. J'ai maintenant créé une nouvelle question: "Cela a-t-il plus de sens de passer à la mise à niveau vers Delphi 2009/2010 ou d'acheter une assurance logicielle?" (BTW, comment puis-je ajouter un lien hypertexte ici ici?)
Il suffit de l'ajouter à votre commentaire. Stackoverflow.com/Questtions/1543959/...
+1 pour pousser le modèle d'abonnement, qui permettra (espérons-le) conduira à des rejets incrémentiels plus stables et de moins de communiqués «gros billet» qui prennent quelques patchs pour s'installer.
Il me semble qu'il y a 2 aspects dans l'élaboration d'applications professionnelles:
Vous voulez gagner de l'argent: vous devez vous en tenir aux demandes de votre client, gardez votre trucs bisous, maintenir et ainsi de suite ... Vous devez être productif: peu importe les génériques, RTTI, Widgets comme Flowpannel, geste et ainsi de suite parce qu'il faut du temps pour apprendre et plus de temps à utiliser. De cette façon, le changement de D7 à D2010 n'est pas pertinent. Changer pour un autre IDE tel que de la vraie base, permettant une cible multiplaform est plus précise.
Mais en tant que développeur, il y a un enfant et un poète en vous, fasciné par les nouvelles technologies ou / et des algorithmes ... C'est la partie créative du travail. Vous devez être créatif si vous voulez être impressionnant et innovateur. Mise à niveau vers Delphi 2010 est un must, à la recherche de nouvelles classes, de nouveaux objets est un mode de vie dans la programmation d'aujourd'hui.
C'est mon point de vue humble et la raison pour laquelle je me garde de mon argent pour mettre à niveau Delphi de i à 2010.
meilleures salutations,
DIDIER
Si j'allais utiliser un IDE moins capable en faveur du soutien de la plate-forme croisée, je considérerais probablement la Lazare avant quelque chose comme de la vraie base.
Merci pour toutes les réponses jusqu'à présent, j'ai également trouvé cette page de Nick Hodges: Top dix raisons de mettre à niveau de Delphi 7 edn.embarcadero.com/article/39136
@Pato. Si vous aimez ça, vous allez adorer celui-ci: Stackoverflow.com/Questtions/305016/...
Et celui-ci: Stackoverflow .com / questions / 1406854 / ...
@Ertugrul: Vous n'avez évidemment pas regardé l'aide D2010. C'est +++ ++ mieux que les Delphi 6 pour la plupart. (Accordé, il reste encore des choses à faire.)