96 replies to this topic

[emailaya]

hi
now that d2009 is out and unicode is supported built in
what about next components suite?
i believe tnt components are not needed anymore
when do u think a new version that supports d2009 will be available?

thanks

[Boki (Berg)]

Hello Emailaya,

Delphi 2009 version will be made in next few months. You may try now to open Delphi 2007 package in Delphi 2009, and maybe it will work without changing any line of code.

Best regards

[emailaya]

first i will need to buy d2009 and i want to know whether to buy or not according to the support of the suites im using (nextsuite is one of them)

do u know how did they implement the unicode? did they improve the type "string" or invented a new type or simply converted all string properties into widestring?

when and if u will make a package for d2009 remember to remove the need of the conditional TNTUNICODE - there is no need for that anymore

[Boki (Berg)]

Hello Emailaya,

I have in plan to add support for Delphi 2009. I think that string type is now automatically same as WideString. I will need to leave TNTUNICODE since some users want buy Delphi 2009.

Best regards

[deonvn]

@emailaya

Just as a point of interest:

While you are considering wether or not you should buy D2009 and convert all your apps, just keep in mind that apps compiled in D2009 may not run on Win95, Win98 or WinME since those versions of Windows didn't support unicode either.

Regards,
Deon

[emailaya]

deonvn:
since my app already uses unicode (tnt components) it doesnt work on 95/98/me even now
anyway, there is MSUL (something like that: microsoft unicode layer) for 95/98/me so unicode apps can work on those OS's as well though i never tried it

and hopefully i wont need to convert anything, i hope that will be the case when migrating to d2009. depends on the implementation of the unicode.

[bertrod]

did they improve the type "string" or invented a new type or simply converted all string properties into widestring?

I went to a conference about this topic not long ago, and I can answer you that they changed the type "string". All string functions (pos, substr, etc.) will work with Unicode. You can also name your component with unicode characters if you want to.

[emailaya]

yeah i read some more and apparently string will be stronger than before (along with a new type: unicodestring)
so as it seems now, we only need to build next package without TNTUNICODE conditional and everything will work as unicode when using d2009

i wonder if things are really as easy as stated in some forums i read

[spongebob]

Compiling Next Component Suite in Delphi 2009

As I was interested in finding out how much work I'd have with my applications, I went through the process of compiling the Next Components D2007 Packages in my 14 day demo Version of Delphi 2009 (Win32), which is available as "Registrationware" @ http://cc.codegear.com/free/delphi

Here are my hints for developers trying to compile the Next Component Packages (I've got the "Next Developer Suite", so all the nice stuff you can get here)

0. Expect lots of warnings about WideChar/Bytechar/PAnsiChar/String Conversions

1. The arguments of some Windows API calls changed e.g. Windows.DrawTextEx : lpchText is a pWideChar now, not a pAnsiChar.

Solution
- examine the hint you get when you place the mouse cursor over API Calls
- cast/convert to correct type where appropriate

2. Parameters of system string functions have to be of the same type, e.g

CODE

if Pos('bold', Value) > 0 then // Value is a Widestring

has to be changed to

CODE

if Pos(Widestring('bold'), Value) > 0 then

3. As the nextcomponents contain a bunch of pretty common type names or procedure names, you may have to
qualify using the unit name in order to tell the compiler what you want :

CODE

FBorderLeft := TNxCellBorder.Create(nil, bpLeft);

has to be changed to

CODE

FBorderLeft := TNxCellBorder.Create(nil, nxSheetCell.bpLeft);

because bpLeft is defined in ExtCtrls, too

4. TWidestrings was defined in WSDLIntf in D2007, now there's a unit WideStrings.

NxSuite.inc should contain something like this :

CODE

{$IFDEF VER200}
  {$DEFINE DELPHI2009UP}
  {$DEFINE DELPHI2007}
  {$DEFINE D2005UP}
{$ENDIF}

Which lets you fix References to WSDLIntf :

CODE

{$IFDEF UNICODE}{$IFDEF DELPHI2009UP},WideStrings{$ELSE},WSDLIntf{$ENDIF}{$ENDIF UNICODE}

5. NxVirtualDataset may need major changes (pChar is used in quite some places
and TDataSet seems to use pAnsiChar nowadays).

The Delphi 2009 Demo does not install VCL Source code, so I don't know how to fix it (yet)

-> Package AddOnsRun needs some work and can not be compiled easily

6. uses vcljpg has to be replaced by uses vclimg
(Just in case you run into this one)

(Total Time needed : 30 Minutes for researching and fixing and another 15 Minutes to write this..)


Note : What I did is the brute force method of compiling the next components.

What Boki has to do, may take quite some time - so don't expect him to be "D2009 ready" next week

- Find the best way to Fix all errors in a way which is compatible with Dx - D200x
- Fix some warnings, hopefully (No, I'm not talking about {$WARNINGS OFF} here !)
- Test compilation with Dx - D200x
- Test if components / Demos / Applications work as expected

After all I changed only 9 Files :

Next Addons/NxAutoCompletion.pas
Next Addons/NxDBGridPrint.pas
Next DBGrid/NxDBCommon.pas
Next Grid/NxColumns.pas
Next Inspector/NxPropertyItemClasses.pas
Next Sheet/NxColumnList.pas
NxClasses.pas
NxSharedCommon.pas
NxSuite.inc

Regarding my own applications, I ran into a little roadblock in another component :

CODE

function StrNScan(Text : PChar; Chr : Char; Chars : Cardinal): PChar; assembler;
asm
        PUSH    EDI
        MOV     EDI,Text
        MOV     ECX,Chars
        MOV     EAX,0
        CMP     ECX,0       //Exit if Chars = 0
        JE      @@1
        MOV     AL,Chr     // compiler error E2107 ("Argument Size mismatch")
        REPNE   SCASB
        MOV     EAX,0
        JNE     @@1
        MOV     EAX,EDI
        DEC     EAX
@@1:    POP     EDI
end;

Any Ideas how to fix this, anyone (I don't even know what this function does) ?

[Boki (Berg)]

Hello Spongebob,

As soon I get copy of D2009 I will follow your instructions to compile NextSuite in it.

Best regards

[Thrawn123]

I am also waiting for Delphi 2009 support

[Thrawn123]

Hello Spongebob,

As soon I get copy of D2009 I will follow your instructions to compile NextSuite in it.

Best regards

Do you have any updates on Delphi 2009 support? I am anxious to use it, but I have a lot of projects using NextSuite (which I absolutely LOVE) so I haven't been able to use it. I am not trying to rush you, as I would prefer a solid working release, but am just curious if you have a time frame? Thank you in advance

[Boki (Berg)]

Hello Thrawn,

Maybe using patch from user sponge bob may help until I finish official release.

Best regards

[Victor Printing]

I've got a package set that I've made enough changes to that it can be single-source compiled in BDS2006 and D2009. I haven't tested other versions because I don't use them, but it should be fairly compatible.

Enough changes have been made that there's very few string warnings in either IDE.

The TDataSet interface seems to have changed quite a bit, so I didn't bother doing anything with TNxVirtualDataset.

Don't know how it will interact with the TNT Controls in D2009, for people migrating such projects.

Boki, if you'd like a copy of the files, let me know.

All of this is a "first rough draft" kind of thing. I think that the "most correct" solution involves a thorough audit of the code to make sure that strings, WideStrings, and UnicodeStrings (typedefed to WideString on Delphi 2007 and earlier) are used to ensure maximum compatibility and performance within the constraints that the controls provide. Maintaining Support for Win9x and the TNT controls on D2007 and earlier may increase the complexity of this quite a bit. What makes the most sense for Boki only he can decide.

Rough change summary:
NxSuite.inc: Add defines for D2009.

NxAddonsReg.pas: Don't register TNxVirtualDataset in D2009.
NxAutoCompletion.pas: typedef TAcWideStrings to be a TStringList in D2009 instead of TWideStrings
NxPreview.pas: Have A2S internal function use PWideChar on D2009
NxVistaCtrls.pas: Compile TNxVEditButton in $M+ state to eliminate warnings in D2009.
NxDBCommon.pas: Typecast Field.Value to AnsiString in GetBlobGraphic(). This feels hackish, but I think a better solution would be more invasive.

NxClasses.pas: Reimplement CharInSet on versions of Delphi below D2009, along with changes listed for various units below.

NxCollection.pas, NxCells.pas, NxColumnClasses.pas, NxColumns.pas, NxDisplays.pas, NxGridReg.pas, NxEdit.pas, NxPopupControl.pas, NxSharedCommon.pas, NXSharedDraw.pas: Have Win32 API functions point at -W or -A versions based on UnicodeSupported variable. Make sure that parameters are correctly typed. Change "char in [Set]" calls to "CharInSet(char, [Set])" to eliminate warnings from D2009. Include NxClasses.pas if necessary.

[Victor Printing]

Another set of changes that don't really fit in with the Delphi 2009 migration:
Created D2009 packages.
Added lib suffixes to both D2006 and D2009 the packages. (Without this, I couldn't have the components installed into bother BDS2006 and D2009 at the same time.)
Created NxAddonsDsgn, NxThirdpartyDsgn, and NxDBThirdpartyDsgn packages.

[Boki (Berg)]

Hello Vistor,

Thank you, I will use your post when converting package to D2009 support.

Best regards

[emailaya]

now that a new version is out and d2009 is available for long time
any chance the next version will support it?

thanks

[Boki (Berg)]

Hello Emailaya,

It will support Delphi 2009, but I need some time and not to rush.

Thank you

[emailaya]

ofcourse
i didnt ask if it will be 2morrow, just if it will be in the next release
whenever it will be

[Boki (Berg)]

Delphi 2009 version will be ready in next 30 days. It seems that lot of things need to be changed.

Best regards