Skip to content

Easily move your Windows/VCL apps to Delphi XE5 and gain tons of benefits

Regardless of the previous version of Delphi you are using, there are a large number of benefits you will gain by moving your projects forward.  There is also a special offer for all Delphi customers (regardless of the version you are using) to move up to our latest XE5 release. I am sure that you see that there a lot of great new technology available to you as a Windows VCL developer.

Delphi XE5 Technologies you can use today in your Windows/VCL apps

  • Sensors - You can use the System.Sensors unit and classes in your Windows/VCL applications. The TSensorManager class can be used to identify the sensors connected to the computer and make them available for use within Delphi applications.
  • FireDAC - The fastest and most powerful Universal Data Access library ever! FireDAC enables native high-speed direct access from Delphi and C++Builder to InterBase, SQLite, MySQL, SQL Server, Oracle, PostgreSQL, DB2, SQL Anywhere, Advantage DB, Firebird, Access, Informix, DataSnap and more.
  • New REST Client Support - Simple invocation of REST web services from any third party provider and includes authentication support and JSON response manipulation, with dataset and LiveBindings mappings.
  • LiveBindings - LiveBindings is an expression-based framework that provides fast, easy and no-code data-binding to bind objects to other objects or to dataset fields. While you can continue to use your VCL data bound components, in XE5 all VCL visual controols contain a LiveBindings property.  You get the benefit of the LiveBindings Wizard, LiveBindings Designer and rapid application prototyping using the TPrototypeBindSource.
  • VCL Styles - Control and change the appearance of a complete VCL application with VCL Styles, including the appearance of every part and state of a control. You can also create your own custom styles using the Bitmap Style Designer.
  • 64-bit Windows - Push the envelope of performance by creating 64-bit Windows applications that take advantage of the latest hardware and access more memory.  In your the IDE project manager window, right mouse click on the Target Platforms node and choose "Add Platform" and select "6t4-bit Windows".  Rebuild your project and you now have a 64-bit executable.
  • Unicode - XE5 ensures that your apps are available to a global workforce of users and marketplace of customers. Delphi is fully Unicode-compliant. While new data types have been introduced, existing data types remain and function as they always have. Based on more than five years of in house and customer experience with Unicode, your applications should migrate smoothly to the Unicode world.
  • Surface Pro Tablets - With the Metropolis UI in Delphi, you can take your VCL applications and create applications that incorporate the latest Windows 8 styling and functionality in an easy and accessible way.
  • VCL Performance and Quality Improvements - XE5 both fixes and contains the culmination of thousands of performance and quality improvements reported against every version of Delphi from Delphi 7 to XE4.

What Delphi XE5 can give you compared to your current version

Getting the Ambient Light Lux Value on my Samsung Slate Series 7

Here is a Windows/VCL example that gets the Ambient Light value on my Samsung Slate Series 7 tablet. Create a new VCL Delphi application. Put a button and three labels on the form. Set the form caption to "Get Ambient Light VCL Demo". Set the button caption to "Get Ambient Light". Set the first label to hold the caption for the Lux (light value) label. Set the second label’s name to "AmbientLightSensorLabel" (this is used to display a message for whether an Ambient Light Sensor is found or now). The third label is going to contain the ambient light value, name this label "LuxLabel". For the Button’s onClick event handler use the following code (remember to include the uses statement in the implementation section for the System.Sensors unit):

implementation
{$R *.dfm}
uses System.Sensors;

procedure TForm1.Button1Click(Sender: TObject);
var
  MySensorArray : TSensorArray;
  MyAmbientLightSensor : TCustomLightSensor;
begin
  try
    TSensorManager.Current.Activate; // activate sensor manager
    // use GetSensorsByCategory to see if a Light sensor is found
    MySensorArray := TSensorManager.Current.GetSensorsByCategory(TSensorCategory.Light);
    if MySensorArray <> nil then begin  // check if Ambient Light Sensor is found
      AmbientLightSensorLabel.Caption := 'Ambient Light Sensor Found';
      MyAmbientLightSensor := MySensorArray[0] as TCustomLightSensor;
      LuxLabel.Caption := FloatToStr(MyAmbientLightSensor.Lux);  // display the Light sensor value
    end
    else begin
      AmbientLightSensorLabel.Caption := 'Ambient Light Sensor Not Found!'
    end;
  finally
    TSensorManager.Current.DeActivate // deactivate sensor manager
  end;
end;

Here is the app running on my Samsung Slate Series 7 with the afternoon light here in Scotts Valley at around 3pm today:




Using Sensors with Delphi VCL

Here is a blog post showing how you can integrate Windows based sensors in your DelphI VCL applications. The blog post references Delphi XE3.  You can use the same code with Delphi XE5. See the source code and output at http://blogs.embarcadero.com/davidi/2012/10/03/41699. The following screen shots were grabbed from my Windows 7 VM (hosted on MacBookPro using VMWare Fusion for the Mac) and my Samsung Slate Series 7 running Windows 8.

Special Offer - Upgrade to Delphi XE5 from any previous version (expires Dec 31, 2013)

The offer is "Buy RAD Studio, Delphi or C++Builder version XE5 at the low upgrade price if you have any earlier version of Delphi, C++Builder, RAD Studio or Borland Developer Studio." How to get it? Purchase a RAD Studio, Delphi or C++Builder XE5 upgrade. Available only between October 22, 2013 and December 31, 2013.

{ 43 } Comments

  1. David Intersimone | December 2, 2013 at 4:40 pm | Permalink

    Kent: Thanks for your comment. Not sure what you mean by "older version" since you were not specific in your comment.

    "New, Slow, Badly Written RTL" and "highly optimized RTL for each supported platform" - would also be great to get specific suggestions from you so that I can pass them along to the R&D team.

    Thanks in advance and thanks for commenting.
    David I.

  2. Dalija Prasnikar | December 3, 2013 at 1:33 am | Permalink

    @Kent Morwath I fully agree with you.

  3. Daniel San | December 3, 2013 at 2:05 am | Permalink

    @Kent Morwath I fully agree with you too!

  4. Markus Ja | December 3, 2013 at 2:15 am | Permalink

    @Kent Morwath: Well sayed.
    I also don’t see any reason to upgrade to XE5 when only targeting Windows.

  5. Bunny | December 3, 2013 at 3:23 am | Permalink

    Thank you. The area of VCL is ok …

    Don’t worry.

  6. jake | December 3, 2013 at 11:58 am | Permalink

    "Surface Pro Tablets" do you mean it could run in win RT ?

  7. davidi | December 3, 2013 at 12:06 pm | Permalink

    Jake - Surface Pro has an Intel processor and can run all windows apps. Thisis the tablet we are talking about. We don’t support Windows/RT/ARM yet - which is what is needed to have apps run in the Surface.

    Windows/RT/ARM is listed on our RAD Studio public roadmap as work being investigated by R&D as we continue to deliver products for Windows, OSX, iOS and Android. Also listed on the roadmap is Linux Server targeting which will help developers create Linux based web services, soap servers, DataSnap servers and other Linux server apps.

    Wondering aloud about Windows/RT’s future - recently, the head of Windows at Microsoft, Julie Larson Green, was quoted ion an article on The Guardian web site saying ""We have the Windows Phone OS. We have Windows RT and we have full Windows. We’re not going to have three."

    http://www.theguardian.com/technology/2013/nov/26/microsoft-kill-windows-rt-larson-green

  8. Bruce McGee | December 3, 2013 at 6:01 pm | Permalink

    With the notable exception of the terrible streaming regression (fixed in XE5/XE5), I have yet to see a concrete example of Delphi getting slower. In fact, the two concrete examples that I know of comparing identical code in XE2 and XE5 both perform better in XE5.

    If there are clear, repeatable examples of regressions, please speak up.

    That said, I agree that the QC backlog needs some serious attention.

  9. Unspoken | December 3, 2013 at 10:33 pm | Permalink

    @Kent Morwath I fully agree with you too! Absolutely no reason for me for upgrade from XE 2 to XE 5

  10. Brian Andersen | December 3, 2013 at 10:36 pm | Permalink

    David, why didn’t you comment on the QC statements?

    Ohhh, wait… It’s fixed in the next release. You have to buy an update!

  11. Donovan | December 4, 2013 at 2:51 am | Permalink

    when they start actually doing what their customers ask for, maybe then it will be worth updating, till then, we will explore other avenues

  12. David Intersimone | December 4, 2013 at 7:11 am | Permalink

    Thanks everyone for the feedback. If you have specific QC #’s, I will be very happy to walk them over to R&D and push to get resolutions. I do know that thousands of QC reports have been fixed in the versions between Delphi 7 and XE5. That said, there will always be some bugs in software and the team holds bug meetings to review each and every problem report and assigns them to engineers via our Jira tracking system (QC is the web front end for you).

    All software has issues, and we are dedicated to not only working on new capabilities for you but also continually working to improve the quality of our products.

    Send along your QC #’s - even if you are not the one who reported them.

    Thanks again for all of the feedback and comments.

  13. David Intersimone | December 4, 2013 at 7:13 am | Permalink

    Donovan - what specifically do you mean "when they start actually doing what their customers ask for" - what are you asking for in features for our products?

    What more do we need to do to make it "worth updating"?

  14. David Intersimone | December 4, 2013 at 7:17 am | Permalink

    unspoken - You have XE2 - cool!. Did you like the Win64 support? is there some other features of XE2 that you are using that you like?

    If you want/need mobile support - then we have spent a lot of R&D time building mobile support for Delphi for iOS and Android in XE4 and XE5.

    Why multiple releases? The R&D team continues to invest in a wide range of new features and platforms as well as adding to our existing support for Windows. When the technologies are ready to move from the lab to you we release products.

    If all you need is more Windows support - let me know what you want for Windows and I will bring it directly to Product Management - or you can contact John Thomas and Marco Cantu directly if you want.

  15. David Intersimone | December 4, 2013 at 7:17 am | Permalink

    Brian - what QC #’s do you want me to escalate for you?

  16. Dalija Prasnikar | December 4, 2013 at 12:17 pm | Permalink

    As far as mobile platforms are concerned 119501 - lack of 8-bit COW strings is absolute showstopper in my case, others are 118796 application started on incompatible device shows black screen, and 118203 - lack of support for non NEON devices (as well as Intel based Android devices, but I am not aware if there is QC for that). Also, FireMonkey is still too buggy to be used out of the box without needing to do a lot of fixes and workarounds.
    And good example of performance issues mostly introduced from XE3 up, besides streaming regression is 119459.

  17. David Intersimone | December 4, 2013 at 8:10 pm | Permalink

    Kent - I am very sorry, but I accidentally deleted your latest comment when I was trying to clean up my Wordpress spam. Thankfully, I get emails for every comment that is posted on my blog. Here is the latest comment you posted - and again, I am very sorry for clicking on the wrong button.

    Author : Kent Morwath
    Comment:
    I see there is still a lot of confusion with Windows 8. First of all, WinRT is not ARM only. It’s a "new" API to deliver applications running in the WinRT subsystem, aka "Modern UI" (aka "Metro"). WinRT is the only API available in the ARM version of Windows (but for special applications like Office, but AFAIK only MS can code this ones), but it is also available in Windows 8 Intel and it is the API used to write the "tiled" applications, those who don’t need the "desktop" to run.

    AFAIK XE5 can write Windows 8 "desktop" applications (because they are plain old Windows app) but can’t target "Modern UI" applications at all - even on Intel (Surface Pro & C.).

    A skin and some controls that mimic the "Modern UI" is not writing this kind of applications. This ones run outside the desktop, integrate with "charms", etc, etc.

    Thereby, please, sell what you really have, don’t act like a weasel and use some obscure wording to sell what you don’t have. We know the reason, you can’t access some APIs you need to target RT, and you were so busy with the Android stuff you forget to force MS to open its APIs allying with those in your same situation.

    But those who need to target the latest releases of Windows don’t care about UI imitations - which looks the actual trend at Embarcadero (FM and Metropolis) - we need a tool which is able to deliver native apps on that platforms. And that’s not Delphi, any longer. Delphi is becoming a Frankenstein built with pieces get here and there that tries to resemble a human being, but which is not.

    Sorry, if people don’t upgrade often they have very good reasons. Don’t ask your customers what they can do for you… ask yourself what you can do for your customers…

  18. David Intersimone | December 4, 2013 at 8:25 pm | Permalink

    Kent - regarding my post about our roadmap (http://edn.embarcadero.com/article/42544) and what it specifically says on slide 5 in the section titled "Beyond iOS and Android": "Windows 8 ARM/RT".

    Most developers will understand that there are three versions of Windows available, again quoting directly from Julie Larson-Green: "We have the Windows Phone OS. We have Windows RT and we have full Windows. We’re not going to have three."

    We all know that there is a difference between "full Windows" and Windows RT. We know what is needed in our RTL/VCL/FMX to support full Windows vs Windows RT and also what we need to do to support Windows Phone OS. We’ve decided to focus for now on iOS and Android for mobile. We also are still committed to supporting Windows and are making sure that the IDE and everyone’s VCL applications continue to work on the supported Windows platform versions: Microsoft® Windows 8, Windows 7 SP1, Windows Vista™ SP2, Windows Server® 2008 (32-bit and 64-bit).

    The Metropolis-UI style and implementation does give you the look and feel of Windows 8. We do not claim it is Windows 8 tiled or modern UI. We do have a Live Tile mechanism that you can use, but we do not claim that it is a Windows RT based application (and never have).

    You’re right, we can create "full Windows" desktop apps, server apps, etc.

    When we complete the Windows 8 ARM/RT investigations we will find that the work we are doing will allow us also to choose to support Windows 8 Intel/RT (we do already have the Intel compilers for 32 and 64 bit).

    At the same time, everyone will be watching to see what Microsoft’s next move and incarnation of Windows will be (beyond Windows 8.1). If WinRT is going to Morph or go away altogether (ask Larson-Green), then we will not have wasted too much time or everyone’s time (I still remember how Silverlight was going to be a critical part of Windows’ future).

    I am very glad that we are focused on Windows, OSX, iOS and Android. This gives Delphi developers all of the opportunities to do build software for a wide range or platforms, users and customers.

  19. David Intersimone | December 4, 2013 at 8:31 pm | Permalink

    Dalija - we are looking at Intel on Android. We have the Intel compilers/toolchain and we know how to build Android APK files. If the number of Intel/Atom based Android devices grows beyond the starting number, we know we can do the toolchain work and testing to leverage all that we are doing in XE5 and beyond.

    As far as Android Non-NEON devices goes - we are looking to see what more we might be able to do, but for now, most of the recent and newer chips and devices are ARMv7 with Neon Support. Just as we have tested apps on GIngerbread, Ice Cream Sandwich and Jelly Bean we also have been testing on KitKat.

    As the platforms and devices keep moving forward we know we will have to continue to support new APIs, new form factors, new sensors, etc. We are on it, we are focused on additional Windows, OSX, iOS and Android support. XE5 is our first Delphi for Android release and there will be many more releases in the coming years.

    Your investment in Delphi (even if it is that you are still using older Delphi versions) allows you to quickly build applications, just as you have been able to do since Delphi 1. The same capabilities, along with the newer language features, tooling, components and RTL will continue to allow you to rapidly build apps for years to come.

  20. Kent Morwath | December 5, 2013 at 12:18 pm | Permalink

    David, the sad story is Delphi is no longer able to create "full" Windows app. Nor client, nor server. Many new Windows features are outside Delphi envelope, and not only Windows RT. Look at Datasnap, for example. Can it use Acrive Directory for authentication (and using the user secuirty toklen to handle that)? No, it can’t. In 2013, from a *full* Windows application - server and client - I expect something like that. Especially now you have AD LDS to allow for specific AD instances, even when you don’t have a full AD DS deployed - or along it for specific needs. Can the VCL use latest controls, for example Windows Ribbons? No, again, it can’t. Are there facilities to use Windows encryption libraries? Again, no. TCP/IP support is built using libraries like Indy, and not OS facilities - for example see how easy is using the configured system proxy from Indy - and use the current user authentication.
    Delphi Windows service implementation is old, and not very flexible. How do you code real server applications without services? Where are the components to write to the Windows event log? Where is support for newer APIs in the RTL and VCL, maybe with some code to compile for or adapt at run-time to newer OSes? Maybe MS will kill Windows RT as a separate OS, but I’m sure WinRT will stay in Windows - because it works well on smaller devices with a touch UI, where plain Windows UI doesn’t.
    Sadly, Delphi still supports Windows 95 only (and somewhat, NT4). It doesn’t really support Windows 7, 8, 2008 or 2012. Apps run on them just thanks to the great Windows support for older applications. Delphi has lost a lot of ground on its flagship platform, while chasing new markets where it’s still in doubt it can gain any market share bigger then Windows Phone in the phone market today.
    I’m very sorry, but you really offer very little to us, long-time, hard-core Windows programmers, to upgrade. Other tools have better support for newer Windows features, and well, even if I have to code them from scratch I’ll do it now with tools allowing me to access them out of the box, without hacks. And I do believe Delphi is - was, maybe - a great tools for Windows applications. As far as I’ve seen till now, it’s not a tool for mobile development. Too many compromises, especially for the UI, but not only. Again, we are using other ones, with better support for latest devices and UIs. Sorry - it’s up to Emb to offer us what we need…. if we don’t upgrade, there’s a reason.

  21. Markus Ja | December 5, 2013 at 9:41 pm | Permalink

    @David I:
    1) Please bring back the old Search Dialog. The new integrated is horrible to use.
    2) Please fix Error Insight.
    3) Why did you change IDE Insight in XE5? I really loved to old one.
    4) To much RTTI stuff introduced.
    5) LiveBindings are linked with strings instead of references. That makes refactoring harder. Use the compiler to find invalid references.
    6) FMX performance for Win & OSX is too slow.
    7) FMX Style designer is unusable.

  22. From Eastern Europe | December 7, 2013 at 2:03 am | Permalink

    Kent Morwath has many good arguments. Here are some thoughts from XE2 Professional user.

    I recently finished trial of XE5. Besides dog slow startup of the new IDE I was surprized that the new IDE was more snappy to code. Good work in that respect. But my main interest was checking out FireMonkey platform, I had long waited for Android support. I’m sorry to say that entire FM platform (still) looks like one big hack. I mean it. I think words "hack" and "workaround" are synonyms for current FM. It is no wonder DevExpress does not plan to support this platform. And of course the documentation, or lack of it. What is the difference of OnPaint and OnPainting events in FM? That was a rethorical question as my trial has ended for now…

    I’d give FM a chance, even with all these issues and compromises, as I really like idea to have one familiar code base and compiler for different platforms. But looking at current pricing of XE5 I can’t see how I can "Buy XE5 at the low upgrade price" as quoted. I see this "low" price touted everywhere. To upgrade to XE5 with Mobile add-in and maintenance from XE2 Professional I need to pay around EUR 1800 (about USD 2400). And for that money I only get FireDAC with local databases, no remote database support. Thanks but I think that is ridiculuous "low" price. Get back the the Earth. You are pricing your hypothetical dream product that you don’t have. What you have is buggy FireMonkey hack where even simple things like TEdit.OnTyping does not work (Android). 2400 dollars, my assembler…

    This may sound stupid but consider creating new cross-platform framework instead of FM. The new one uses native basic controls (menus, edits, listbox, listview, tabs etc) on each platform. Is lightweight and not bloated. Forget useless eye candy and focus on basics. Get basics working first. You already have compilers. You know what went wrong with FM. You have potential to have great tools. Repainting a rotten house only makes it look better, it is still rotten.

  23. From Eastern Europe | December 7, 2013 at 5:36 am | Permalink

    I forgot to ask - where is Delphi encryption library? Nowadays encryption is everywhere but there is no decent and up to date encryption suite available for Delphi/FM. There are few old freeware ones for Delphi but these are basically discontinued and not properly maintained and up to date.
    I think it is in interest of Embarcadero to have cross-platform encryption library included with the product. I suggest Embarcadero to domesticate once popular freeware DCPCrypt and keep up to date.

  24. davidi | December 7, 2013 at 1:55 pm | Permalink

    There are several Delphi encryption units out there - including wincrypt. We don’t ship encryption (especially heavyweight) as we would them have to pursue export licenses from our US government. There are plenty of encryption resources for Delphi developers - just search Google.

    For DataSnap we ship encryption filter examples for RSA and PC1. Danieli Teti on his While..Do blog list other filters.

    Yes - we will do more and your suggestion that we join an open source project and ensure it moves along (like we have done with other components/libraries we ship) is a good one. Thanks.

  25. David Intersimone | December 7, 2013 at 4:40 pm | Permalink

    Kent - I am not sure what you mean when you talk about Delphi not being able to build Windows apps, especially when you use terms like "full" Windows app. Nor client, nor server."

    I can build a lot of Windows apps of all kinds. Maybe you can be more specific? What new Windows features are you talking about - I think I see Active Directory (you can do this via code). When you talk about DataSnap authorization you can do all that you need including calling Windows API calls, using attibutes, using username/passwords, etc. You can always create a service that provides the active directory support you want and call it from your DataSnap server to validate, authenticate and use the attributes on DataSnap methods to restrict what can be called from remote clients.

    I guess I will assume that you want us to provide components and other pre-built options for additional authorization and functionality. I agree that we want to provide more pre-built components and options and Marco Cantu is putting those features into the plans for that and more for DataSnap. At the same time, we have Linux Server on our roadmap for server side things like DataSnap, web services, etc. Windows Active Directory will not help in those cases, unless I am missing an ActiveDirectory capability in Linux.

    " TCP/IP support is built using libraries like Indy, and not OS facilities - for example see how easy is using the configured system proxy from Indy - and use the current user authentication." - We have a ton of Project Indy components ready to be used on Windows, OSX, iOS and Android both in clients and servers.

    "Delphi Windows service implementation is old, and not very flexible. How do you code real server applications without services?" I am not sure what more you want and not sure what you mean by "not very flexible" that is a squishy term and if you want to pass along your thoughts, I will pass them along to the R&D team.

    "Where are the components to write to the Windows event log?" I agree that we and other partners/developers can provide additional components for all sorts of Windows APIs and features. Good idea here. At the same time there are solutions out there (do we have to provide everything?):

    http://www.delphi-central.com/components/eventlog.aspx
    http://windows.software.informer.com/download-windows-eventlog-delphi-component/
    http://www.online-admin.com/twmisystemevents.html
    CodeSite from Raize Software allows you to do a lot of logging :)

    "Where is support for newer APIs in the RTL and VCL" - what newer APIs do you want us to wrap and provide support for?

    We’ll see what happens to Windows RT - and we list this on our roadmap for future releases.

    "Delphi still supports Windows 95 only (and somewhat, NT4). It doesn’t really support Windows 7, 8, 2008 or 2012. " What? We don’t really support Windows 7? We supported the Touch APis before MS VS did. We supported the sensor interfaces before MS VS did. But I am sure if you list some of the Windws 7,8,2008,2012 things you want us to support we will do it. At the same time, you can always call Windows API calls (except for WInRT) - we have all of the SDKs and APIs for you to write code and use :)

  26. From Eastern Europe | December 8, 2013 at 9:28 am | Permalink

    With Windows API-s the thing is that you are not staying current. You don’t need to offer components for new functionality but just make the new Windows API easily accessible by providing declarations. I already uninstalled XE5 trial and can’t check it, but does it have declaration for new CopyFile2 function that was introduced in Windows 8? I suspect not. And it is not just 10 seconds minute to declare it by developer, as it uses extended data structures that all need to be declared and tested as well. All this is can be done by the user, yes, but requires additional effort and testing. If you tell your new release has Windows 8 support then one assumes you really have it, not just have made some new skins and components that just *simulate* certain new OS features. Or things like VSS (Volume Shadow Services) API header translations, which also require considerable time to implement and test, completely missing.
    Yes, developers can do many things by themselves, you are correct, but this all requires additional time and testing, additional effort. Instead of relying on 3rd parties to provide quick header translations of questionable quality I expect this to be done by Embarcadero and included with the product. If you release new IDE and tell it is compatible with Windows X then I assume you have also provided header translations to new APIs provided with Windows X. But of course that is just wishful thinking…

  27. davidi | December 8, 2013 at 6:00 pm | Permalink

    Eastern Europe - Windows API coverage - we have all (most?) of the most recent Windows header files converted into Delphi units. Look in the RAD Studio\12.0\source\rtl\win folder. There are 105 Windows API files with Delphi interface units created.

    I checked the RTM for XE5 - and while we have CopyFile, CopyFileA and CopyFileEX, etc in Winapi.Windows.pas but no CopyFile2 yet. I will pass that along to the R&D team.

    Any other important Win API functions we need to wrap in Delphi units?

  28. From Eastern Europe | December 9, 2013 at 12:10 am | Permalink

    David,

    "we have all (most?) of the most recent Windows header files converted into Delphi units" — sorry , this is your wishful thinking but not reality. Yes you have many but almost always new APIs are not translated, there is very long delay, often several releases long. And only subset of new (and old) APIs are declared in your units. Do you think me and others are here complaining with no reason? What bothers me is that this complaining and reporting does not lead to much improvement because you think you already have everything fine. I can’t report every missing item the same way I can’t report every missing help topic. It is your responsibility to check that you have declared all new Windows APIs on new release as it is your responsibility to have help topics describing each property of provided controls. If your automation is fails to check that you have help topics for all properties then hire someone who is happy to manually move from property to property in IDE and invoke F1 help for each property and component to see if there is really something coming up, not just "Embarcadero does not currently have anything to say about this"… And do this before you release your product.

  29. Bunny | December 9, 2013 at 5:25 am | Permalink

    I don’t bet a lot on what MS officials say. I see no realistic option for the WinRT OS to become a success. If there is no must for an ARM based device for whatever reason - Surface Pro is enough. Those who already need those devices that allow usage for days without recharging will
    a) have already been purchased and solutions could be found already
    b) their purpose is still limited.

    We are still in the state advanced but yet successful - Tric-O-Tronic.

  30. Bunny | December 9, 2013 at 5:26 am | Permalink

    Mobile devices - still equal Tric-O-Tronic. Not Delphi.

  31. David Intersimone | December 9, 2013 at 7:21 am | Permalink

    Bunny - "Mobile Devices = Tric-O-Tronic. Not Delphi." Really? I know a lot of developers are still only developing for Windows. Yet, there are millions of developers also building mobile applications or exploring adding mobile application development to their client app designs and implementations.

  32. David Intersimone | December 9, 2013 at 7:25 am | Permalink

    Eastern Europe - "almost always new APIs are not translated" - I will agree with you that we do not have 100% Windows API coverage and am forwarding developer feedback to the team to help us get there. I know there are document links that end up with "Embarcadero has no info on this topic" at this time. Our doc team knows where these links are and continues to add help every day.

    A couple of quick question for you and everyone else on this thread:

    1) What is the most recent version of Delphi do you own?
    2) What is the latest version of Delphi that you use for your everyday work?
    3) Besides Win/RT, Windows Phone, Android Widgets and Linux platforms - what are a few (3?) of the applications you need to build that you can’t build with Delphi?

  33. Markus Ja | December 9, 2013 at 9:44 pm | Permalink

    @David I:
    1) Delphi XE
    2) Delphi XE
    3) It’d not a question of what application I can’t develop. It’s about how productive I am with Delphi. Currently, my concerns are:
    a) The code quality is going down.
    b) EMB doesn’t look at the performance anymore. (If it works, ship it).
    c) LiveBindings and too much RTTI stuff is making refactoring and code maintainence harder. With so much "string" references, bugs are not found at compile time anymore.

  34. From Eastern Europe | December 9, 2013 at 11:08 pm | Permalink

    1) XE2
    2) XE2
    3) Try to first get it properly working on Andoid/IOS/Mac/Win, then see what more can be done.

    "Our doc team knows where these links are and continues to add help every day." — on some reasons they have been doing that for years now and that is still one of the most complained issue about Delphi? I have difficulty of understanding what is so complicated about it.

  35. From Eastern Europe | December 10, 2013 at 1:57 am | Permalink

    Today I wanted to start Windows project that uses smart cards, specifically API defined in WinSCard.h and introduced in Windows XP. I was not surprised to find that my Delphi XE2 does not include header translation of WinSCard. Latest Porject-JEDI also does not include it. I found one older translated WinSCard.pas header file that has been part of Project-JEDI earlier, but on some reason it is not included now. There is TODO "convert" note regarding it in JEDI, so perhaps it is not compatible with Unicode.

    I’ll stop now complaining here.

  36. Yusuf | December 10, 2013 at 4:43 am | Permalink

    Hi, we’ve recently upgraded from XE2 Enterprise to XE5 Enterprise but having problems within the IDE.
    Directly after opening the IDE with our project, the IDE is consuming more an more ram … without doing anything.

    Reacing the 700mb mark, the iDE is frozing or we’re getting exceptions AND we can’t compile.

    Is this really fixed in update2 and is there any info when we can expect the update2 …

  37. Dalija Prasnikar | December 10, 2013 at 5:28 am | Permalink

    1) XE4
    2) XE4 and 7 - not because code is not migrated to XE4, but because exe size is intolerable in some cases - for instance my Delphi 7 app size is 1Mb and same code compiled with XE4 is 3Mb
    3) it is less about what apps you cannot write, but more how much effort you have to put in for anything that uses FireMonkey

  38. IL | December 10, 2013 at 6:09 am | Permalink

    Well, just today we have searched and failed to find something about PTP and MTP Windows APIs in Delphi. MTP is in Windows XP SP2 since 2004 as Wikipedia says. There is ImageEn component, which has great support of TWAIN, WIA and DCIM folder image sources. Unfortunately, it lacks support of PTP or MTP. Would it be possible to add some basic support of PTP, MTP or Windows Portable Devices (WPD)?

  39. IL | December 10, 2013 at 6:42 am | Permalink

    I’m sorry, I didn’t write our intention clearly to use of PTP&MTP. We are in progress of adding image aquisition support in our application. Just one simple action - take picture. As for TWAIN and WIA we are succeeded thanks to ImageEn, yet having problems with web cameras and mobile cameras. DirectShow (again in ImageEn) seems can solve the problem for web cameras, but not the problem with mobile cameras using WPD. We use Delphi XE.

  40. Vladimir Srednikh | December 10, 2013 at 7:14 am | Permalink

    Please, look at http://qc.embarcadero.com/wc/qcmain.aspx?d=115832

  41. Vladimir Srednikh | December 10, 2013 at 8:23 am | Permalink

    http://edn.embarcadero.com/article/43446
    Error: the video you are trying to watch is currently unavailable

  42. Simon Vidanovic | December 10, 2013 at 1:05 pm | Permalink

    Lets put it simple. When we can expect Delphi to work on Mac OSX as well and not just Windows?

  43. John Williams | December 10, 2013 at 1:20 pm | Permalink

    Currently using Delphi 7 for lots and lots of legacy code. Will eventually move this code to XE5 but the change to zero-relative strings is a hold up.

    Doing all new projects on XE5. These are almost 100% iOS and Android apps. The market for new, non-corporate, Windows desktop apps is very small now.

    Overall I have been very happy with all versions of Delphi since before Delphi (Turbo Pascal). I’ve used a lot of other platforms too and none are perfect.

    With XE5 I’ve been able to get 3 Android apps into the Play Store within a month of purchasing the product. Yes, there are bugs and workarounds for FM and other parts of the platform. But is there another product that can offer this kind of developer efficiency?

Bad Behavior has blocked 4 access attempts in the last 7 days.

Close