News, Blogs, and Tips

RAD Studio 2015 Developer Survey is Live

Marco Cantu - Wed, 08/19/2015 - 01:50

As I already blogged on the Embarcadero community site at, the 2015 edition of the yearly RAD Studio, Delphi, and C++Builder developers survey is available and will remain open 10 days, until August the 28th. The survey has 100 questions divided in 18 pages and we estimate it can take 30 to 45 minutes to take it.

This is the link:

In case you don't have time to go over all sections, you can skip a page, as only a limited numbers of questions require an answer to continue. In this case, please complete the pages you are most interested in. Of course, we'll appreciate if you have time to complete all pages.

We know your time is valuable and so we greatly appreciate your participation in this annual survey, which will significantly affect the product development and planning for the next 18 months. There are also new questions this year to help us better understand how you are using the product.

Categories: News, Blogs, and Tips

The Story of the High Fix Rate of RAD Studio Bugs

Marco Cantu - Mon, 08/17/2015 - 07:09

Here is an overview of the process the RAD Studio team uses for processing bugs reported by customers, and the current status. Over the recent years, the effort in fixing bugs and issues reported by customers has increased significantly. We have numbers from our internal bug tracking system that can shed some light. 

Before we get to those numbers, however, it is important to understand how the RAD Studio team tracks and manages bugs, how they are categorized and processed. I won’t get to the details, but an overview will help explain the rest of the story.

From Quality Central to Quality Portal

For many years, the customer-facing tool for reporting bugs was hosted as Quality Central at This was an internally developed bug-tracking tool that mapped to the internal bug tracking system, RAID. It is still there, but don't use it any more.

Over the years, RAID was replaced with an instance of Atlassian Jira (, and Quality Central was remapped to it. Since last year, the team introduced the new Quality Portal (, which is also based on Jira but has different configurations and settings. The current flow from Quality Portal to the internal system and back is very smooth and it is significantly improving the communication between the team and customers reporting bugs.

Bugs Flow and Status

The second information worth knowing, before looking to the actual data, is the flow up bugs and their status over time. For this, I’m considering the current system (there were differences in the previous combinations).

When a bug gets reported, it is copied in the internal system and is validated by a QA (Quality Assurance) team member. He might open it and send to the proper developer, close it because it is not considered a bug but the expected behavior, a “test case” error, close because it cannot be reproduced, open it as a feature request for future consideration, ask for more information to the bug reporter, close it as duplicate of an existing issue… and a couple of other scenarios.

At that point, if the bug is open, it is assigned to a developer, who can provide a fix for it, but also suggest a temporary workaround, can decide this is expected, or suggest merging it with future work. An individual developer doesn’t actually do this process alone: There are team meetings, “bug council” meetings, and many steps to access and re-evaluate over time the priority of issues.

There are a couple of further considerations here. The first is that when a bug is closed internally, its status is not immediately reflected in the public system. The reason is simple: Telling a customer the bug is closed but he or she cannot get the fix would be of no value. The bug is marked fixed in the public system when a fix including the bug is released. This is why in the public system there are huge spikes of fixed followed by periods in which it seems nothing is done. The internal system, instead, tells a more complete story.

The second consideration is that a significant number of bug reports that are not considered “errors” in the current implementation, but requests to extend a given capability are kept in the system. While internally tagged as “feature requests” they stay open and look like bugs not being addressed. In theory we could close them indicating the feature works as "currently" designed, and open a separate internal request for enhancements.

The last and final consideration is here we are looking to publicly reported bugs, but you have to consider that the majority of bugs is reported internally by the QA team, other developer, or internal users (incuding myself). Our goal and more consistent effort, of course, is to fix bug before the software is released. So the internal numbers tells a different story, but for this blog post we are focusing only on bugs reported by customers.

Let’s Get to the Data

With this picture in mind, I’ve recently dug some data and some graph that help understanding the current status and the extra effort done recently on RAS Studio quality.

Faster Resolution Time. The first graph shows the yearly average resolution time over the last 4 years. This is how many days it takes on average to resolve an issue. Thinks are improving significantly, I’d say.

70% of Reported Bugs Have Been Solved. If we consider all bugs that have been reported over the same time frame (from 2012) and came from customers, we get a real picture of the effort. If you add closed and resolved issues, it’s a 71% of the total. Many of the re-open issues are also partially closed (they might not be optimal or complete solutions). Also among the open issues there are 279 (at a recent count) marked as feature requests, which brings the real number of open bugs further down.


There is certainly much more information we can dig in our system to show how many publicly reported bugs have been fixed over time in the various product areas. The new public bug tracking system is also making it easier to follow the bugs status and it’s ensuring a better communication between customers, quality assurance team, and development team.

The RAD Studio team is focused on further improving the process and devoting more resources in fixing issues. The trends have been encouraging, but this doesn’t mean we think our effort is good enough and we are going to stop here. On the contrary, we see a positive trend and want to keep focused on that direction, increasing the timeliness of bug fixes, their numbers, and (which is what really matters) the overall product quality.

PS: Clarification on Closed Vs. Fixed Issues

Some of the comments (including a few I didn't approve) hint to the fact that not all "fixed" issues have been specifically addressed by the team, given some might have been duplicate or coud have ended as being considered "test case errors". So I dug some extra information. Out of that bucket of closed bugs, over 3,200 individual and distinct issues have been fixed with actual changes in code. Wiht is roughly half of all of the issues that have been addressed. 


Categories: News, Blogs, and Tips

Generate Meaningful Test Data with Data Generator for SQL Server v3.5

DAC Team - Thu, 08/13/2015 - 05:23
Why meaningful test data important? While developing an application, you need to make sure you are testing it under conditions that closely simulate a production environment. Most tests rely on sample data for testing. If you manually enter data into a test environment, one record at a time using the UI, most probably, you will […]
Categories: News, Blogs, and Tips

Object Pascal Handbook Now in Print

Marco Cantu - Fri, 08/07/2015 - 08:32

My latest book, Object Pascal Handbook, is now available in print on Amazon and other outlets. I finished the book 2 weeks ago, got my proof copy earlier this week, and given it was good, I gave it the green light. The book, in fact, is self-published through CreateSpace, where it is available at  (this is the online store I earn more from, but Amazon is also quite good on margins).

On the site the book is  (and already selling, given it is going up in places in the "Langauges and Tools" category under programming). You can buy it also from the UK site ( and the German one ( in which case I understand they print the book in Europe and ship locally. Other Amazon stores should have it, and other non-Amazon sites should get it as well in the coming weeks.

Cover price is 46.50 US Dollars, 31.50 UK Pounds, 43.50 in Euro (but Amazon has it a little higher). The final book is well over 500 pages.

More information is at  although I still need to udpate that page with the buy links, the complete TOC and the index, and more information. Should be done in the coming days. Along with sharing more of the source code of the demos.

The ebook remains a free download for XE7 and XE8 registered users, and should be updated with the complete version (3 more chapters from the last draft) shortly. I'm considering making it available as a paid ebook as well, but not immediately.


Categories: News, Blogs, and Tips

IDE Fix Pack 4.4 for Delphi 2007 – Windows 10 Edition

Andy’s Blog and Tools - Tue, 08/04/2015 - 13:45

For all developers that got stuck at Delphi 2007 and who want to upgrade to Windows 10 can now use the special “Windows 10 Edition” of IDE Fix Pack 4.4 for Delphi 2007. The “Windows 10 Edition” also supports Windows 8.1.

Requirement: Delphi 2007 December Update.

Name IDE Version File Size Downloads Added IDE Fix Pack 2007 4.3 (may work with Windows 8) 2007 59.74 KB 5392 times 2011-08-20 IDE Fix Pack 2007 4.4 (Win8 is not supported) 2007 61.85 KB 11175 times 2011-08-28 IDE Fix Pack XE2 4.5 XE2 UP2 only 125.47 KB 2311 times 2011-11-02 IDE Fix Pack XE2 4.6.6 XE2 UP3 only 152.4 KB 3561 times 2012-01-04 IDE Fix Pack 2007 4.4 Windows 10 Edition 2007 Dec.Update IDEFixPack2007Reg44Win10.7z 88.51 KB 1098 times 2015-08-04

Categories: News, Blogs, and Tips

IDE Fix Pack 5.93 – Windows 10 support

Andy’s Blog and Tools - Mon, 08/03/2015 - 10:48

Those who tried to use IDE Fix Pack on Windows 10 got the uncritical error message “failed: Faster IDE startup [IDE.Startup.Fast]” that appeared on every IDE start. The problem is that a byte sequence changed that IDE Fix Pack tries to find. Windows 10 uses “INT3” instead of “NOP” instructions to align functions and IDE Fix Pack 5.92 and earlier looked for “NOP”. The new 5.93 now allows both instructions.

IDE Fix Pack 5.93 only adds support for Windows 10 otherwise it is the same as 5.92.

For the next IDE Fix Pack I’ll work on the Delphi Win64 compiler’s performance. (not the generated code)

Name IDE Version File Size Downloads Added IDE Fix Pack 5.94 2009 (UP4) IDEFixPack2009Reg594.7z 179.96 KB 7 times 2015-11-01 IDE Fix Pack 5.94 (unsupported) 2010 (UP5) IDEFixPack2010Reg594.7z 176.29 KB 5 times 2015-11-01 IDE Fix Pack 5.94 XE (UP1) IDEFixPackXEReg594.7z 162.23 KB 8 times 2015-11-01 IDE Fix Pack 5.94 (unsupported) XE2 (UP4+HF1) IDEFixPackXE2Reg594.7z 236.08 KB 9 times 2015-11-01 IDE Fix Pack 5.94 (unsupported) XE3 (UP2) IDEFixPackXE3Reg594.7z 190.48 KB 6 times 2015-11-01 IDE Fix Pack 5.94 (unsupported) XE4 (UP1) IDEFixPackXE4Reg594.7z 192.67 KB 4 times 2015-11-01 IDE Fix Pack 5.94 (unsupported) XE5 (UP2) IDEFixPackXE5Reg594.7z 191.81 KB 8 times 2015-11-01 IDE Fix Pack 5.94 (unsupported) XE6 (UP1) IDEFixPackXE6Reg594.7z 322.4 KB 7 times 2015-11-01 IDE Fix Pack 5.94 XE7 (UP1) IDEFixPackXE7Reg594.7z 334.91 KB 11 times 2015-11-01 IDE Fix Pack 5.94 XE8 (UP1) IDEFixPackXE8Reg594.7z 331.97 KB 13 times 2015-11-01 IDE Fix Pack 5.94 D10 IDEFixPackD10Reg594.7z 334.77 KB 23 times 2015-11-01

Download (fastdcc):
Name IDE Version File Size Downloads Added fastdcc 5.94 2009 (UP4) fastdcc2009v594.7z 77.29 KB 2 times 2015-11-01 fastdcc 5.94 (unsupported) 2010 (UP5) fastdcc2010v594.7z 84.28 KB 1 times 2015-11-01 fastdcc 5.94 XE (UP1) fastdccXEv594.7z 86.14 KB 3 times 2015-11-01 fastdcc 5.94 (unsupported) XE2 (UP4+HF1) fastdccXE2v594.7z 111.79 KB 3 times 2015-11-01 fastdcc 5.94 (unsupported) XE3 (UP2) fastdccXE3v594.7z 121.67 KB 2 times 2015-11-01 fastdcc 5.94 (unsupported) XE4 (UP1) fastdccXE4v594.7z 125.38 KB 1 times 2015-11-01 fastdcc 5.94 (unsupported) XE5 (UP2) fastdccXE5v594.7z 124.31 KB 3 times 2015-11-01 fastdcc 5.94 (unsupported) XE6 (UP1) fastdccXE6v594.7z 153.28 KB 3 times 2015-11-01 fastdcc 5.94 XE7 (UP1) fastdccXE7v594.7z 164.01 KB 4 times 2015-11-01 fastdcc 5.94 XE8 (UP1) fastdccXE8v594.7z 164.57 KB 5 times 2015-11-01 fastdcc 5.94 D10 fastdccD10v594.7z 164.58 KB 10 times 2015-11-01


  • Added: Support for Windows 10
Categories: News, Blogs, and Tips

Random Thoughts on the Passing Scene #162

Nick Hodges - Mon, 06/14/2010 - 14:07
Categories: News, Blogs, and Tips

Delphi Pretty Good Practices #5 – Don’t Use Literals

Nick Hodges - Wed, 06/09/2010 - 10:03

If there is a bedrock, bottom line, everyone-should-follow-it-all-the-time rule in programming it is “The DRY Principle” – Don’t Repeat Yourself.  This simple rule states that you should write code once and only once, and that you shouldn’t allow the same code to be used all over the place.  Or, as the Wikipedia article deftly states: "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system."  Put more simply, it means that you shouldn’t have the same thing repeated all over your code, but that you should create a single identifier and use that in the many places where it might be needed.

As a practical matter, the DRY principle in its most basic form tells us that we should, as a matter of course, not use literals in our code, but instead should declare constants (or resourcestring types as we’ll discuss in a minute) and use those instead. That way, if you need to change the value for something, you can do it in a single place instead of having to make multiple, error-prone changes throughout your existing code.

For example:  Say you have a system that has an arbitrary number of required repetitions, say 17.  You might end up writing a whole bunch of code like this:

for i := 1 to 17 do begin ProcessStuff; DoSomeMoreStuff; end;

Now imagine that you have that kind of code all over the place, and then your boss comes around and says "Hey, we need to repeat all that stuff 18 times now, not just seventeen.” Well, if you haven’t followed the DRY Principle, you could very well end up with a lot of code to change.  And don’t use search and replace, because what if you change the 17 that is part of a variable name or something?  Things could get ugly fast.

Of course, the thing to do is to declare a constant:

const NumberOfRepetitions = 17;

and declare your loops as

for i := 1 to NumberOfRepetitions do begin ProcessStuff; DoSomeMoreStuff; end;

and now when your boss switches things up, you have but one simple change to make, and all is well.

Now this is a pretty simple, basic thing to do, but I’m constantly surprised at how often I find myself forgetting to do it.  (For instance, if you look through the code for TextScrubber, you’ll probably notice that I need to apply the DRY Principle to the TVersionInfo constructor in uTextScrubberTypes.pas.) You might be surprised how many literals you use in your code. I often take advantage of the syntax highlighting feature to scan code for specific colors for strings and numbers and replace them with constant values as much as possible. For instance, some code from TextScrubber used to look like this:

procedure TStraightTextMainForm.InitializeMainFormInformation; var IniFile: TIniFile; begin IniFile := TIniFile.Create(IniFileName); try TextScrubberOptions.ClickChoice := TClickChoice( IniFile.ReadInteger('Options', cClickChoice, 0)); TextScrubberOptions.ShouldTrim := IniFile.ReadBool(cOptions, 'ShouldTrimText', False); finally IniFile.Free; end; end;

with a bunch of string literals.  Instead, now, I’ve declared two constants in the uTextScrubberConsts.pas unit

const cOptions = 'Options'; cClickChoice = 'ClickChoice'; cShouldTrimText = 'ShouldTrimText'; cVersionLangCodePage = '040904E4';

and the new code looks like this:

procedure TStraightTextMainForm.InitializeMainFormInformation; var IniFile: TIniFile; begin IniFile := TIniFile.Create(IniFileName); try TextScrubberOptions.ClickChoice := TClickChoice( IniFile.ReadInteger(cOptions, cClickChoice, 0)); TextScrubberOptions.ShouldTrim := IniFile.ReadBool(cOptions, cShouldTrimText, False); finally IniFile.Free; end; end;

Those constants are also used when I write out information to the INI file, so that I can change the value in one place if I need to, and so that I can know that there won’t be any typographical errors in my strings that will cause a bug.  The same string value is always going to be used for the INI file entry.

Now let’s take a look specifically at strings.  Strings are a bit special because they are very often used to communicate information, and as such, they frequently need to be translated into other languages through the process of “localization”.  Windows provides an easy way to do this via string resources, and Delphi provides an easy way to create string resources via the resourcestring identifier.  These strings are then created as resources, making them easy to translate.  And “easy to translate” can often be, well, translated into “cheaper to translate” and that is a good thing.

Practically speaking, I apply this principle by placing as many const and resourcestring declarations as I can in a single file, thus centrally locating them for easy management and translation.  In our case with the TextScrubber project, I’ve created a file called uTextScrubberConsts.pas and put constants and resource string values into it.  If you look through the project code, you’ll probably notice that I need to apply the DRY Principle to the TVersionInfo constructor in uTextScrubberTypes.pas, even if it is keeping those constants within the unit.

One question that might get asked is “How do you choose what to make a const and what to make a resourcestring?”  My answer is that as a general rule, any string that could change without changing the UI or the functionality of the code, make a const.  Any string that, if changed, will trigger a change in UI or translation should be made a resourcestring.  There are exceptions to that, of course. More simply, a rule to use that anything that might get translated should be a resourcestring.

Now, this is a pretty simple “pretty good practice” to follow, but for you folks who have not been following this principle,  simply doing so can make your code more readable and maintainable.

Categories: News, Blogs, and Tips

Random Thoughts on the Passing Scene #161

Nick Hodges - Tue, 06/08/2010 - 14:27
Categories: News, Blogs, and Tips

Random Thoughts on the Passing Scene #160

Nick Hodges - Fri, 06/04/2010 - 09:43
  • The topic of newsgroup participation came up in our Delphi.non-technical group, and I mentioned that it appears that more people seem to be using StackOverflow to get answers to their questions.   Craig Stuntz turned around and in his own inimitable way, proved that such is the case.  I know that I check StackOverflow a couple of times a day, and try to make modest contributions.  I endeavor to vote for good answers and to give good answers when I can.  The cool part is that if you are only interesting in Delphi Programming questions, you can really make it “DelphiOverflow” by simply paying attention to the correct tags. 
  • Speaking of stuff on StackOverflow, Robert Love pointed out something I hadn’t seen before on there: Code-Golf.  This is a question that asks a small development problem, and then folks post their answers in their favorite languages using as few characters as possible (low score wins, like in golf).  Kind of fun.  Robert threw in a Delphi answer for this question, and he inspired me to post my own Code Golf problem.   So, if you are so inclined, I’d love to see a Delphi solution, though I’m sure it will be tough to compete with some of the command line scripting languages. Next time I’ll make the criteria be a command line EXE. 
  • Forgive me, but I found this quite funny. Please note the text bubble near the end. Now if she had decided to use Delphi, well, that might have been a different story.  I am also reminded that Jack Bauer uses Delphi – and I strongly recommend against crossing Jack Bauer.
  • I’ve mentioned that there is a new version of Delphi Prism – and one of it’s new features is the ability to put some C# code on the clipboard and paste it as Prism code.  If any of you is interested in automating the process, there is a command line version of that tool available.
  • Oh, and don’t worry, I haven’t given up on the “Pretty Good Practices” series.  I’ve got a few drafts in the queue, but they are a bit tougher to write than the Random Thoughts items.
Categories: News, Blogs, and Tips

Random Thoughts on the Passing Scene #159

Nick Hodges - Wed, 06/02/2010 - 11:52
Categories: News, Blogs, and Tips

Coin Flip

Nick Hodges - Sun, 05/30/2010 - 18:28

I had occasion to write a little routine called CoinFlip:

function CoinFlip: Boolean; begin Result := Random > 0.5; end;

I don’t know why I found it mildly amusing.  And I bet someone will tell me that it is slightly biased in one direction.  Because it is.  Anyway, thought you all might enjoy it, too.

Categories: News, Blogs, and Tips

Random Thoughts on the Passing Scene #158

Nick Hodges - Wed, 05/26/2010 - 09:01
Categories: News, Blogs, and Tips