Darian Miller

Type definitions are different... I definitely prefix with uppercase T Except for Error class types that start with uppercase E Interfaces with uppercase I

I have switched over the years but current prefixes include f for Fields p for Parameters v for Local Variables You could also use v for Var parameters I no longer prefix constants - I add them to classes and scope all uses with the class name. If I don't use class scoped constants, I slip back into old school mode and use all uppercase for unit constants. TMyClass = class public const DefaultMessage = 'Hello World'; ... ShowMessage(TMyClass.DefaultMessage) Globals are treated similar to constants...if used, add them to a globals class or record. Since I have a strong preference for lower case prefixes, I prefer v over l for local variables as the l prefix can lead to readability issues. I just don't reading: FThreadCount, AThreadCount, LThreadCount. I'd rather see fThreadCount, pThreadCount, vThreadCount. I believe the prefix used for parameters and local variables is stricly for collision prevention purposes only and shouldn't be highlighted with a capital letter. There are a few coding standards on the web for reference if you'd like to review: http://www.sourceformat.com/coding-standard-delphi-econos.htm http://mc-computing.com/languages/delphi/Style_Guides.html https://edn.embarcadero.com/article/10280#3.5 https://wiki.freepascal.org/Coding_style https://www.gnu-pascal.de/h-gpcs-en.html https://wiki.delphi-jedi.org/wiki/Project_JEDI_Delphi_Language_Style_Guide I think we had about 8 Delphi developers on staff at my previous job when we all got together and voted on style rules. The daily Code Reviews started enforcing those style rules. It wasn't enforced 100% of the time but it did help standardize the code better than before. (4+ million lines of Delphi code written by a few dozen different developers.) These prefixes came from that vote about 12 ago now.

It was a simple example and the Encoding is selectable, but it really depends on what you are going to do with those TBytes... If you are getting it from Edit1.text as in the example, fidding with the bytes somehow, and then shoving it into Edit2.text, why convert to UTF8?

Example. Start a new VCL app, drop an Edit and a Button on a form. In the click event of the button: procedure TForm7.Button1Click(Sender: TObject); var x:TArray<Byte>; begin x := TEncoding.Unicode.GetBytes(Edit1.Text); ShowMessage(IntToStr(Length(x))); end;

Sorry for the double post...double clicked the Submit button I guess

Curious if you ever received a response?

I don't recall if this is on by default: TStyleManager.SystemHooks := TStyleManager.SystemHooks + [shDialogs]; But also look at: http://delphiprogrammingdiary.blogspot.com/2019/05/how-to-apply-vcl-style-to-delphi-common.html

Ancient subject, but after years of progress on both sides... how does it look today for a new, small Windows desktop project? Don't need outrageous speed, or size, just a dependable data store. One nice feature is to be easy to backup/restore as needed. Another alternative is PostgreSQL. Does anyone even use InterBase anymore?

There are quite a few different avenues you could take to support API development. The first step in any is to get it "to work" which you seemed to have accomplished! Your next question is valid - will it scale? The question remains, how much do you need it to scale? How many concurrent connections are planned, what sort of total throughput is required and what are acceptable latencies? Once you define those, you can test those things yourself by using tools like JMeter and BlazeMeter and see if your performance is acceptable. If it's not, then you can look at scaling methods, either locally with Windows Clusters or migrating to cloud services on AWS or Azure. If the performance isn't satisfactory, you could also look into different implementations. One of the most commonly used frameworks is mORMot which has been highly optimized. If you join their community you'll likely get some help getting started. There's a LOT of code available, and much you can ignore to get started. Another option is to get a commercial finely-tuned multi-tier approach from Components4Developers. This option has been around a very long time and is quite mature, and quite performant. Another commercial option to look into is the Remoting SDK from remobjects. This also has been around quite a long time and is widely used. For a real simple and performant commercial toolkit, also look at RealThinClient components. There are plenty of other choices out there. The next step that I would recommend is to analyze your projected usage and start establishing some real testing metrics that you can validate current and future decisions on. Get the tools in place to back up your API infrastructure with measurements and validation. In addition to API testing, get line-by-line performance measurements with ProDelphi or Nexus Quality Suite to track down different implementations.

That's a honest question, when you know the answer?

DevArt subscriptions default to 1 year of support and upgrades. You have the option to buy 2 or 3 years up front at a discount. It's a perpetual license, but you won't get any updates after your subscription expires if you don't renew. Renewals are typically 40-50% of the price of the initial subscription, but you are correct, they don't display that cost. I assume you can get a close guess of what the cost of annual renewal will be by comparing the 1 year to the 2 year initial price, and add about 10%. (Rough estimate) Before purchase, I sent them an email and specifically asked what the renewal price was. I purchased pgDAC Pro last year for $500, which is the current list price. I can renew the annual subscription today for $250. It's getting close to be a real good time to buy tools and components. As I posted on my blog last year, many component vendors offer Black Friday discounts: https://www.ideasawakened.com/post/black-friday-discounts-from-delphi-related-third-party-vendors DevArt is apparently using the same URL as last year and this page contains discount codes good from Nov 23-29th, saving 20-50% off. https://www.devart.com/blackfriday.html I'll probably do a 2020 blog post with Black Friday deals once more are announced from various vendors.

Roadmap released: https://blogs.embarcadero.com/rad-studio-roadmap-november-2020/

Thanks. I don't think I ever torqued him off and got banned, but then again I don't remember what I ate for lunch yesterday...

Who runs that group?

Thanks! Maybe I angered the moderator....called him a Visual Basic programmer or something.

Thanks. I am a member of these 3 facebook Delphi groups: Delphi Dev: https://www.facebook.com/groups/delphidevelop 3.3k members Delphi Developers: https://www.facebook.com/groups/DelphiDevelopers 4.4k members Delphi Programmers: https://www.facebook.com/groups/DelphiProgrammers/ 6.2k members For the Facebook group link you provided, I get an error message below so it must be a private group. Or maybe I've been banned! 🙂

Thanks. I guess I don't have access to that group. Can you invite me?

Curious - which Delphi facebook group? I didn't see your post listed in the few groups I checked. (I'm wondering if I'm missing a group.) Also - have you received your payment yet? Try contacting their "VP of Product" Kurt Smith. The email I have for him is firstname at fastspring.com

I think a new roadmap is past due.... any news @Jim McKeeth or @Marco Cantu?

I imagine one of the biggest problems of being self-taught is missing out on some well-documented practices. Well, I confess that I did not know about the use of double-dabble to quickly manually convert a base-2 representation to base-10, for example: 1001000110 to 582. Quick blog post published today: https://www.ideasawakened.com/post/double-dabble-and-conversions-from-base-10-and-base-2-number-systems

Which version of Delphi? Sometimes corrupt .FRM files cause an issue. Test in a new directory and convert all To / From text to binary.

No, not all the time but the more I do it, the more I like it. You were wanting a better system of not having to remember a specific enumeration like htTemplate. One suggestion was to just create a HTML related unit that contains the main generic HTML related types that you want to use so you can remember the general unit name and then lean on code completion to find the type/enumeration. Create a naming system that you like for these types of units, something like HTMLTypes.pas, HTMLUtils.pas, HTMLShared.pas, or whatever naming style you prefer and then you can type HTMLTypes. and invoke code completion to get all of your shared HTML related types and drill down to the one you want. If you have HTTP related items you also create HTTPTypes.pas (or whatever) and then DBTypes, EmailTypes, etc. These shared units usually have type definitions with little code. One code smell is if you are including a bunch of code in one of these shared units, then that code should be split out to its own unit (likely several new units.) Defining where the code should live is a primary key to the ability to maintain the code over time. It also helps you code much faster if the organization makes internal sense. Choice 1 is one unit with every single line of code. Choice 2 is a separate unit for every class or type definition, no matter how small. There's a balance somewhere in the middle, leaning greatly towards 2.

It's a "feature" not a bug. But, yes, I would love a compiler warning.

Note: A real good Delphi reference book is "Delphi XE2 Foundations" by Chris Rolliston. Well worth the money and it will help with issues like this.

In your example, HTML is a field variable of the TReportEnums structure with the specific type defined to be THTMLType. You are trying to access it as an Enumeration and not as a variable. Delphi offers meta classes where you can define a variable to be a class type such as: TMySomethingClass = class of TMySomething, and you can define a variable of type TMySomethingClass, but this only works with classes. AFAIK there's no similar thing for records. Not a great solution, but if you could group your defines in one class you could get code completion from a master class like: TMasterRecordTypes = class type THTMLType = (htTemplate, htStatic, htHeader, htCustom); TSecondRecordType = (srOne, srTwo, srThree); end; vHTMLReportType := TMasterRecordTypes.THTMLType.htTemplate; Or just put all your related record types into a particular unit and use the unit name as the scope, which is how it's normally done. vHTMLReportType := MyUnitName.THTMLType.htTemplate;