There are a couple of things I would suggest to improve your product, IM-Magic Partition Resizer Pro, or whatever version...

1. Having the "Change License key" and "Buy now" buttons in the top row are just fine to begin with...have to have some nags...but after the user pays for their registration, installs and activates the program, remove them, to another area, such as in the next suggestion; 2. Once registered and activated, remove those two and possibly others, moving their functions as links to a general "Help" button on the top row, allowing you to have some added flexibility, as you find in virtually all software nowadays; click on it and a drop down menu appears. You would want a link for "Registration Renewal" and "Access License Key Entry." The last entry link in this this drop down list would be an "About IM-Magic Partition Resizer xxx" link that would, when clicked, pop-up a small window showing the user program info (i.e., program name, version number, date of release, serial number, registration status along with the registered user's name, or company name, date registered and date of expiration, operating system and its version, etc. This simple popup could also have links for Licensing Information, End-User Rights, Privacy Policy...what ever you think could be beneficial or interesting to your users. Of course, since this is a Help button, your help options would be the first links at the top of the list. A general help that draws from local data, then another link that could accessed online. Of course the "How to do" link would be here, too.

Now you have plenty of room as your program develops, without having the top row become cluttered. When you get to it, you'll need a button for "Configuration" or "Preferences." You're off to a good start and the quality programming and knowledge you exhibit as looking at commands and such from the perspective of the users' eyes/needs is a big plus. One last bit of advice, don't ever code in numerical limits, thinking nobody would ever need to enter anything higher...the year 2000 fiasco was a prime example and shows how so many programmers, regardless of skill level, have this inherent mindset that makes them assume to know what limits are required by users. And none of them learned a thing about that, as exhibited by the way "they" decided how to handle years for the future. You don't need date entries prior to 1900(?) and the top end is set for somewhere around 2036(?) - not sure of the dates offhand. Use years above their top limit and the low limit loses the no of years and vice versa...real smart. ;)