Après 6 mois, voici une liste des soucis migratiques de bcb 6->bcb 2009 (update pack 4):
1. Composants devenant indisponibles en natif:
composants fastnet/NetMasters (remplacés par indy),
composants QuSoft QuickReports (mais on peut acheter une version bcb2009).
2. Les composants indy inclus sur le dvd/en download sont bogués. Pour les upgrader:
Suivre la procédure à la fin de la page:
https://forums.codegear.com/thread.j...19011&tstart=0
après migration d'un projet bpr->cbproj, enlever tous les indy.* référencés dans le cbproj (laisser à la place indycore, indysystem, indyprotocols)
3. codage:
L'intégration avec delphi est meilleure, on peut mélanger des .pas et cpp dans un projet. Tout le vcl passe en unicode: les AnsiString sont remplacés par des UnicodeString.
Si des composants / projets utilisent designintf/designeditors:
les include peuvent rester (si encore nécessaires)
les .pas doivent être enlevés du projet
l'option -LUDesignIDE doit être ajouté aux options du compilateur (delphi ou c selon le module qui les utilise), en mode debug et en mode release
dans les modules requis, DesignIDE.bpi doit être ajouté
include / souce: les dossiers avec des références aux bcb6 doivent être enlevés (manuellement)
UnicodeStrings:
ShowMessage(AnsiString.c_str());
ne marche plus
à convertir comme:
ShowMessage(UnicodeString(AnsiString).c_str());
(utilise wide chars)
Variant to TDateTime:
TDate m_dDtCde=TDate(ds->FieldValues["DTCDE"]); //provoque une erreur de compilation (et ca marchait bien sous bcb<=6).
Workaround:
m_dDtCde.Val=ds->FieldValues["DTCDE"];
Variant to string:
if (AnsiString(q->FieldValues["ALLOWED"])!="zut")
ne compile plus=>
if (q->FieldValues["ALLOWED"]!="zut")
Classes vcl "disparues" alors qu'elles sont encore référencées dans l'aide:
throw(new EFOpenError(sFileName));
ne passe pas non plus, même si le type d'exception est dans l'aide. Idem pr EFCreateError.
TPrinterOrientation doit être remplacé par Printers::TPrinterOrientation
Variant to String:
AnsiString s= AnsiString(Query1->FieldValues["toto"])+ "/" + AnsiString(Query1->FieldValues["tota"]);
A réécrire comme
1
2
3
4
5
|
AnsiString sTemp1=Query1->FieldValues["toto"], sTemp2=Query1->FieldValues["tota"];
s=sTemp1+"/"+sTemp2;
/* c'est très très chiant!!! */
/* Même souci avec les TDateTime */ |
1
2
| AnsiString s;
s.sprintf("%s\t%s", Edit1->Text, Edit2->Text); |
Après l'opération, s ne contient pas les deux zones concaténées, mais le premier caractère de chaque zone.
C'est une conséquence que les Text sont unicode. On peut résoudre le souci en tapant:
1
2
| UnicodeString s;
s.sprintf(L"%s\t%s", Edit1->Text, Edit2->Text); |
De plus,
1
2
3
4
5
|
//%s: unicode avec unicode, ansistring avec ansistring
AnsiString s="toto";
UnicodeString us="17/4/2009 10:21:00";
us.sprintf("%s",s); |
et us contient ... du chinois.
Includes:
1
2
|
#include <algorithm.h> |
ne marche plus.
Utiliser au lieu:
1
2
3
4
5
6
|
#if __BCPLUSPLUS__ >= 0x570
#include <algorithm>
#else
#include <algorithm.h>
#endif |
et remplacer min par std::min, max par std::max.
Les migrations de projet comportent souvent des références aux anciens composants bpl non borland. Il faut adapter le projet (enlever les bpi) et parfois ajouter $(BDS)\Lib\Debug_build,$(BDS)\Lib\Release_build aux lib directories.
appels aux services web: UnicodeString partout
Ne pas utiliser (wsdl/service/port): ne marche pas.
Utiliser adresse (idem url wsdl sans ?wsdl à la fin)
TDate[Time]::FormatString("yyyymmddhhnnss") renvoie aussi de l'unicode
Ole:
1
2
3
|
Variant m_vExcelApplication=Variant::CreateObject("Excel.Application");
Variant m_vOleObj=m_vExcelApplication.Exec(PropertyGet("Application")); |
provoque une gpf, soumis au support codegear
Workaround: ajouter variant.cpp du qc 58472 au projet (= variant.cpp de borland avec modif assembler). (Etonnant que des bugs signalés début 2008 sur bds 2007 ne soient pas corrigés dans la version 2009!!!!)
TQuickReport: Evènement after preview:
en bcb6, se produit lorsqu'on clôture la fenêtre de prévisualisation
en bcb2009, se produit après affichage de la fenêtre de prévisualisation ET à la clôture de cette fenêtre. Mail envoyé à QuSoft.
Patch installable de QuSoft, corrigé.
Un TQuery-> 2 TDataSource-> 2 TDBLookupComboBox (un par TDataSource): modifier un des TDBLookupComboBox remet l'autre à NULL. 
Soumis à CodeGear, workaround : multiplier les query
ou remplir des combobox
si on a un formulaire avec une unit nommée ufForm, si le .h ne commence pas par
#ifndef ufFormH #define ufFormH
alors il n'est pas possible d'éditer la form en mode design (même si ca compile et s'exécute parfaitement)
WorkAround: adapter le #ifndef #define dans le .h
InstallShield: bpl's non stoqués dans $TARGETDIR mais bien dans $PROGRAMFILES\$APPLICATIONNAME (qui n'est bien sûr pas dans le path et donc ne marche pas!)
Si dans un formulaire, on fait un appel à Close() suivi d'instructions, le thread peut bloquer ou des instructions (showmessage par exemple) peuvent être ignorées.
WorkAround: Faire suivre chaque appel à Close() par un Application->ProcessMessages();
WDSL importer / HTTPRio web services: memory leak lors de l'appel aux web services renvoyant des valeurs (bug côté CLIENT)! (10 appels ok, 500 appels avec paramètres différents: memory leak causant des gpf) Le même code (outre le prototype AnsiString au lieu d'UnicodeString) marchait très bien en bcb6, nous n'avons trouvé aucune manière de contourner le problème, et c'est ce dernier souci (en espérant que c'est le dernier) qui nous empêche de passer en production les applications converties.
Attente réponse codegear. (mais "any help welcome!").
(Bref, jusqu'à présent, bcb 2009 ne sert qu'en test )
C'est vraiment dommage car bcb 2009 est BEAUCOUP plus rapide que bcb6 pour compiler un grand projet (on passe de une heure à 5 minutes).
Migration vers C++ 2009 ou RAD 2009, retours d'expérience
Répondre avec citation
Envoyé par Fbartolo
Mais pas de réponse à ce jour. 
Partager