Leaderboard

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.

Yes maybe. I guess I'm just puzzled by the need of posting questions about stuff one can easily or better answer oneself - and the walls of text that has little to do with the topic, I'm not against rubber ducking, I use it extensively myself, but rubber ducking in public is just wasting other peoples time.

Doesn't matter how many threads you use. It's an issue with the Python GIL that requires special treatment with threads.

I would just set the property Style to csExDropDownList.

We've got some old, handcrafted Delphi code that produces dynamic HTML/CSS content that we use as a web UI to a service. I would NOT have done it the same way today.

V is more commonly used for method arguments that are declared as var, while A is for arguments that are not var. L is more commonly used for method local variables, and G is more commonly used for unit local variables that are not consts.

I have never exported EML files from Gmail before, but it is not common for email to contain lines starting with periods, so it may be difficult to see at first whether dot transparency is actually being used or not. So, as a test, I just sent an email containing such lines to my Gmail, and sure enough the resulting EML file DOES NOT use dot transparency. Which makes sense, it shouldn't be. That will be true for any emails that do not contain lines starting with periods. But try loading such EMLs using just TIdMessage by itself and you will see the periods get chopped off. Hence the need for the TIdMessageHelper unit. 99.999999% of EML files will likely NOT be using dot transparency. Just the ones created by TIdMessage, or any other similarly broken email clients (which hopefully is rare). The problem with that approach is that you won't know when the load fails in step #2. There is no error reported, lines containing leading periods will simply have those periods chopped off. I would say instead to use TIdMessageHelper always with AUsesDotTransparency=False, unless you KNOW the EML file came from TIdMessage. And even then, you can still use TIdMessageHelper, just set AUsesDotTransparency=True instead in that case. I don't know where you read that, but it is not true.

As of revision #3395 the grep submenu should now work again and also have working shortcuts.

To be fair, there's a Catch-22 in that idea. ie don't implement Generics until you have experience implementing Generics. (and the same would apply for trying to use a c++ like move feature) If someone publishes open source ... not part of a (reasonably big) commercial product like RAD ... and it is useful to maybe 80% of people, then sure it's valuable to point out edge cases - but it doesn't mean it should be discouraged. We need *more* Delphi out there. And more understanding of these elements that weren't even part of Delphi in say 2005.

Thanks! That is some real valuable information. What pops out in the change log between these two versions is the update to a newer VirtualTrees version (7.0 -> 7.4). When I get some time I will try to reproduce that here and track down the cause.

,due to urgency I had posted there as well, based on responses will stick to one going further.