One could write books on this subject (and people have done so). Of course what is good for one person may not be seen as such by someone else. This is particularly so when designing UIs to be used by people with little or no familiarity with the digital world.
One of the problems is that a good UI is also a moving target.
I used to advocate Windows applications as being easy to use if you just followed the simple rules:
1) Tell the computer what you “thing” you want to do something to, by selecting it (often a single click with the mouse or a click and drag).
2) Right click and pick what you want to do with the pop up menu.
This scheme used to work with all good Windows applications. Sadly this uniform approach has gone and users (particularly those in the “addicted to mobiles” category) seem to be happy with the chaotic “every application has it’s own way” approach.
Thinking and planning the basic approach to your UI design must be sensible. I find that David Millington’s three postings about this subject are a good succinct set of documents to read and consider before starting a new project.
David Millington’s Good UI Design – part 1
David Millington’s Good UI Design – part 2
David Millington’s Good UI Design – part 3
One of the recent Embarcadero “CodeRage 2018” webinars was about some of the features in C++ 17.
This included some talk about the “auto” key word and associated encouragement to use it. I’m less convinced about using this in a carefree manner. When you declare a variable or (in C++ 17) a return value who is the sensible person to choose what type it is? The compiler or you?
It’s a great typing saver when you are declaring an iterator for one of the standard library containers (eg a vector). So use it for this.
But I’m not so sure about using it in cases where some careless modification of code might unintentionally change the type of a variable or return value. I feel (because I am used to it) that the strong rigorous typing enforced by earlier C++ standards (before the introduction of the “auto” keyword) is an advantage of the language not a disadvantage.
So yes, use “auto” but only WITH CARE.
Behind Embarcadero’s first class products are a strong on-line community and a company keen to keep it’s customer base bang up to date with what’s going on. One way they achieve this is an annual on-line event, “Code Rage. This is a free series of presentations that cover a very wide range of programming aspects. It most definitely is NOT a series of sales or marketing talks!
It’s free to anyone and registration is simple and quick. Once registered there is no obligation to attend any o the on-line events, but when you see the line up, why wouldn’t you?
To register, head over to Embarcadero CodeRage 2018
Embarcadero have just announced the availability of RAD Studio Rio 10.3. The road map published this summer promised this before the end of the year so they have delivered on time.
This release has many major new features and enhancements. I talk more about this release in future postings here, but in the meantime to see “what’s new” information have a look at this link.
What’s new in Rio 10.3
There is an ongoing debate about the advantage of using/not using an automatic reference counting approach to compiler memory management.
Embarcadero are not immune to this discussion and have recently hinted that they may be changing direction here with their Delphi compilers. This is a big step which will affect virtually everyone who uses Delphi so you can be sure that the designers at Embarcadero will have taken this decision after much discussion.
For a little more information have a look at this link.
Embarcadero blog about Delphi ARC
I mentioned the release of the free version of the Embarcadero C++ or Delphi development environment back on 19th July 2018.
This version is free to most people who make litte or no money from s/w development. There are full details of the precise license restrictions at the download links at the bottom of this posting.
This has gone down very well with hobbyists and open source enthusiasts and also allows “start up” companies to get going with a professional s/w development IDE and only have to pay when they start to make some genuine income.
Since it’s release two other advantages have occured to me.
a) Customers who are worried about ongoing support their software that I have supplied, should my company suddenly collapse (or be taken over) can now get hold of a genuine copy of community edition and can prove to themselves that the source code package I am supplying can actually be compiled and linked by someone else. I’ve always known this but now they can check for themselves. [This only applies to customers who are not in the software development business of course, but this applies to all of my company’s customers (that’s why they use my company)].
b) Anyone applying for a job at my company can now be asked to get a copy of Community Edition and be asked to develop or debug code using their copy as part of our interveiw/selection process.
Community Edition is great: Here are the links, if you are new to Embarcadero products go get it now!
C++ Builder Community Edition
Delphi (object pascal) Community Edition
Embarcadero continue to add innovative features to their RAD Studio (C++ Builder and Delphi) product. They have just released an updated product road map which shows their plans for the rest of 2018 and the start of 2019.
The introduction of C++ 17 support and the improved support for high DPI screens are two of the many features mentioned.
For full details of the road map go to
Road map (Aug 2018)
For convenience we reproduce a copy of the road map here:
Embarcadero have anounced new editions of their C++ IDE and Delphi IDE. Known as “Community Edition” these are free licensed versions of the “Professional edition” for students, home users, open source developers and anyone who programs but does not generate an income. There are accurate details of the restrictions on use at the links below.
This is a very positive move by Embarcadero. It makes it easy for anyone to experience first hand the quality of their products. It can’t help but increase the popularity of the Embarcadero C++ and Delphi programming environments.
Here are the links, if you are new to Embarcadero products go get it now!
C++ Community Edition
Delphi (object pascal) Community Edition
Many functions in third party libraries, APIs or in your own code often return some kind of error indication as to the success or otherwise of the function call.
Always check errors when a library (or other) function returns an error (even if you are going to ignore it !).
Why do we make this statement? For all the following reasons.
a) It documents in your source code the fact that the function returns an error (you may decide to check this later).
b) It makes it easier to check the error status when you are debugging your code as/when it doesn’t work.
c) It makes it easier to add error checking at a later date.
d) It encourages you to think “should I be really ignoring the error code returned by a function” at the time that you write your code. In most cases the answer to this question is probably “no”. Checking errors almost always adds little to code complexity and often saves time in the long run.
When developing C++ code it is very common to declare a pointer to a variable of a specific type (either as a local variable, a class member or (hopefully more rarely) a global variable.
Consider the following two exactly equivalent lines
TMyType *Variable; // no space between the * and the variable – *** preferred ***
TMyType * Variable; // space between the * and the variable
Similarly when using the value pointed to (dereferencing) consider the following two exactly equivalent lines
TMyType X = *Variable; // no space between the * and the variable – *** preferred ***
TMyType X = * Variable; // space between the * and the variable
In each case we prefer the first of the two lines. Why? because the second form looks too much like the multiply operator (z = x * y).
It is very important to be consistent throughout all your code. Knowing that we always use the first form allows us to use a search on “*Variable” and find ALL the instances where the pointer is dereferenced.