Please highlight the word “integer” in the editor and press F1.

——————————-
Description
Embarcadero Technologies does not currently have any additional information.
Please help us document this topic by using the wiki Discussion page. Click the
Current Wiki Page button below to access the wiki.
——————————-

(the onle information about the topic “integer” – and that is only one example)

Is that better then in D2009?

I don’t have access to D2010 yet so I don’t know if they work as expected now.

For example I have 10 labels on a form. I click on 1st label, press F11 and change “Name” property. Then I click another label and press F11 again, “Name” property should get focus so I could type name but I have to doubleclick bc focus is not there.

Events have same problem, on “Events” I press CTRL ENTER for example on “OnEnter”, type //, press F12, F11 and try to press CTRL ENTER again but OI has lost focus.

QC39853
QC30150

I wanted it. See no reason why some methods should be alphabetically ordered and others not. Events are methods.

{$IFDEF UNICODE}
…
TUnicodeFunc = function(AText: string): string;
…
UnicodeUpperCase: TUnicodeFunc;
…
UnicodeUpperCase := @AnsiUpperCase;

to avoid the extra CALL/stack setup/RET – sometimes it may matter. Something they could have thought themselves. You get an indirect CALL, better than nothing…

- Alphabetical ordering of new events ( WTF, who wanted this ?? )
- F11/F12 does not work properly
- New component palette ( fixed in 2010 )
- Help

I will upgrade when all above gets fixed and 64bit version is available.

//just a proof of concept
function UnicodeUpperCase(aText: string): string;
begin
  Result:=AnsiUpperCase(aText);
end;

What do you say?

In attempting to make old non-Unicode code “just compile” under the new Unicode regime, CodeGear made some horrendous blunders imho.

Just trying to get to grips with which version of Uppercase() to use was enough to give me a headache, especially when I discovered that the version that seems most appropriate to a UnicodeString is…. (drum roll please)… .ANSIUppercase() WTF!!!

I have a feeling it’s too much to ask for, but really a massive cleanup effort needs to go into rationalising the Unicode RTL support in the VCL to make it sensible for people actually writing Unicode applications, rather than people who have written ANSI applications and then want them to just behave as before, but with Unicode strings.

Properly supporting Unicode in an application just isn’t as simple as that, and the approach taken in the RTL/VCL seems to make it frustratingly difficult (i.e. counter-intuitive) to actually implement what I would call “real” Unicode applications, i.e. ones that consciously consider and cater for the implications of Unicode, instead of just “hoping for the best”.

What will help to upgrade? A strong and quick release of new versions from the third party component vendors. Granted, not a lot that EMB can do about it, but they can always offer some help. Speaking of 3rd parties tools, will QuickReports still be included?

Now, regarding some misses (understandably not everything could be fixed), it would be nice to feel some love to the C++ side of the tool. Case in point, still no way to have a report of memory leaks on a C++ application closing as there is in Delphi (ReportMemoryLeaksOnShutdown). Nowadays, with application servers running for months it’s a must to be able to early (and natively) debug any leaks. And yes, there are better third party tools for that, but it’s just something that has been asked on a prior live launch product preview and still didn’t make it into this one.

But that’s “slightly” OT, sorry. Bottom line is that for everything I’ve seeing RAD2010 it’s a truly, truly remarkable product.

Why the Help ever got so seriously broken is beyond me. But this is good news.

I hope the updated wiki info can be downloaded and integrated into the help. For security reasons, not everyone likes connecting business critical PCs to the internet.

“what holds you back to upgrade to Delphi 2010?”

Unicode damage is still a big reason. All my 3rd party libraries are with source code, but to fix the TurboPower text editor is going to be a project in itself, something clients just expect to happen and I don’t earn money on.

Also, lack of UnicoWS.dll support (target Win95/98/ME) is a problem on older industrial projects.

But the more I read about it, the better it looks.

Come to think of it, that would be a really great feature for a future Delphi: downward (or upward, depending on how you look at it) compatibility of libraries so that you don’t have to wait for all the vendors to make upgrades available — that is, if the vendor itself is still available