Leaderboard

- Take care on the Application events - Take care on the permissions - Don't make configurations earlier than FormShow, better as lazy and delayed as possible - Use a most modular approach, all single units decoupled and separately testable, just build your plug-and-play system - Start as low-level as possible, use TRect, TGlyph, TPath, TForm, TButton, TEdit, TListView ... Thats no drawback, you can use nested controls without much problems - Use System.IOUtils for any URL composition - Use TFrame as base for your views (some use TForms, but I have no issues with Frames, as long I create them in runtime) - Be aware of fancy controls, they are very likely to fail. - Don't think "desktop", consider "mobile" UI right from the start ... ... (to be continued)

I'll need some more mushrooms to fully decipher that.

Ref the title "Prefix unit local variable names" I avoid unit local variables as far as possible. Those I have made in recent years are declared under the implementation part of the unit. Any interaction with them from outside the unit uses procedures and/or functions Alternatively, they are implemented as class properties on a specific type.

I've tried a few times to write a decent reply... I'll just leave it at: Whatever dude.

How it started. A brilliant tool that was miles ahead of anything else in its main sector. How it's going. A huge pile of bugs that is falling further and further behind the competition.

Better Translation Manager https://bitbucket.org/anders_melander/better-translation-manager The Better Translation Manager (BTM) is a replacement for the Delphi Translation Manager a.k.a. the Integrated Translation Environment (ITE) and External Translation Manager (ETM). Why is it better? Well, for one thing, it's free but more important; It actually works - unlike the ITE/ETM. Why? The standard Translation Manager that ships with Delphi today was originally an individual product known as the Borland Translation Suite. With Delphi 5 it became a part of the enterprise edition. The Borland Translation Suite showed great promise but unfortunately it never evolved from its roots as an external tool and has always been hampered by severe bugs that made it completely unusable in practice. As a result nobody uses it. This can be witnessed by the plethora of homegrown and commercial alternatives. The great benefit of the standard translation system is that it just works (this is the system itself I'm talking about, not the tools. The tools suck). Apart from the requirement that you must use resourcestrings you don't need to do anything special when writing your code. At run time you just place the compiled resource modules in the same folder as your application and the Delphi Run Time Library automatically takes care of loading and using the translations based on the current Windows user interface language. Anyway, since Embarcadero has now finally admitted that they are never going to fix the Delphi Translation Manager and instead recommend that we find alternative solutions, I decided that it was time I solved this little problem once and for all. The core functionality of the Better Translation Manager was written in two weeks during my summer vacation in Italy 2019. Amazing what you can do with a little pasta! Features Does not require any changes to the source code of the application being translated. Works with the existing standard Delphi localization system. Translates resourcestrings and all strings in forms regardless of any 3rd party components used. Works on compiled application. Source code is never used. Generates localized binary resource modules (resource DLLs). Does not use an external compiler. Can import existing translations from compiled application and resource modules or from XLIFF localization source files (dfn, rcn files). Read and save TMX and TBX translation memory files. Import Translation Memory from TMX (Translation Memory eXchange), TBX (TermBase eXchange), Microsoft Glossary and CSV. Machine Translation using Translation Memory, Microsoft Translation Service or Microsoft Terminology Service. Forms, Components, Types and Values that should be ignored can be specified in a Stop List. Translations are Spell Checked. Validation Rules to catch common translation mistakes. Supports Right To Left (RTL) editing based on translation language. Translation project is stored in a single XML file. Command line interface for use in automated build systems. Fast! Refreshing a large project typically takes less than a second vs. many minutes with the ITE/ETM. Supports all Unicode versions of Delphi (i.e. Delphi 9 and later). Resource modules contain the version resource of the source application. What it doesn't do There's one task that BTM, by design, doesn't attempt to solve: Localizing the placement and size of controls. Since it has been my experience that it is a far better idea to design the user interface in such a way that the layout automatically accommodates changes in font- and text size and shorter/longer texts due to translation, I decided from the start that I would not be supporting localization of size and position of controls. This also relieved me of having to create a run time form designer, supporting 3rd party controls visually (something that nobody so far has managed to find a foolproof solution to) and deciding what individual properties constitutes size/position values. Instead I just localize all string values - and only string values. But wait... There's More! Yup, you not only get this little wonder for free. You get the full source code too. Grab it at the repository linked at top. More details at the repository. Enjoy / Anders Melander

@Kas Ob. Thanks a lot! - It helped narrow down the bug (looking in Call Stack helped - not sure why I didn't do that before...): The error comes from Vcl.ABAccessibility.TActionBarAccessibility.accHitTest. I'm not sure why it's called when YouDao is enabled - else it doesn't get called. In TActionBarAccessibility.accHitTest the following code generates the error (my comment) : function TActionBarAccessibility.accHitTest(xLeft: Integer; yTop: Integer; out pvarChild: OleVariant): HResult; var Pt: TPoint; Control: TControl; begin VariantInit(pvarChild); TVarData(pvarChild).VType := VT_I4; Control := nil; Result := S_FALSE; if FActionClient is TActionBarItem then begin Pt := FActionClient.ActionBar.ScreenToClient(Point(xLeft, yTop)); Control := FActionClient.ActionBar; if Control <> nil then begin pvarChild := TCustomActionControl(Control).ActionClient.Index + 1; //This line fails - TCustomActionControl(Control).ActionClient is not assigned! Result := S_OK; end; If the "if Control <> nil then" line is replaced by: if (Control <> nil) and (not (Control is TCustomActionMainMenuBar)) then Then the error is gone 🙂 Again thanks a lot (and I'll make sure to create a bug-report in QualityCentral)

https://www.ideasawakened.com/post/delphi-programming-how-it-started-how-it-s-going

You would have to ask Embarcadero to confirm, but AFAIK no. The IDE creates the LSP processes and expects them to stay running, so if they die unexpectedly behind the IDE's back, a restart of the IDE is likely needed.

Staying in touch with other C++Builder programmers is now very difficult without the Embarcadero forums. I just found this community. Thanks for adding this C++ Builder category. If anyone knows any other place C++Builders talk to each other please post it.

A new version (v1.3.1) is available on github with bug fixes (https://github.com/sempare/sempare-delphi-template-engine) Hope to have the update in getit shortly too.

I noticed in the library source code that some of the uses of TEditCharChase constants were not prefixed with the type. For example, in DbCtrls there is this: case CharCase of ecUpperCase: S := AnsiUpperCase(S); ecLowerCase: S := AnsiLowerCase(S); end; When you ctrl-click the constants there you are sent to a line in StdCtrls that is part of this sequence of declarations: const { Editors common support } ecNormal = System.UITypes.TEditCharCase.ecNormal; ecUpperCase = System.UITypes.TEditCharCase.ecUpperCase; ecLowerCase = System.UITypes.TEditCharCase.ecLowerCase; type TEditCharCase = System.UITypes.TEditCharCase; So, some people seem to want to work around the SCOPEDENUMS.

We use ssh from our dev machines (we're all working from home in Canberra) to the server (in Sydney, 300km away) over vpn's and have not had any issues with large files. We do have some issues with mercurial and filename encoding on windows as it doesn't fully handle unicode properly on windows - there has been a frustrating lack of urgency to fix this, since the main devs don't use windows.

Attracs company in Finland looking for Delphi developer. Our main application do transport planning and logistics. The office is in Kokkola. Now, most work is done remotely but hopefully, COVID-19 will end someday. So we would prefer someone in the neighborhood. We use Delphi Sydney, Bold for Delphi and Windows. Currently, we are 4 developers plus 2 consultants. In case you are a senior Delphi developer you can also work remotely as freelancer. Experience of ORM or Bold for Delphi is a merit. Ask for more details.

What were the errors?

@JDS2018 It is time now, you the original poster, to give explanations about what you need to do. This looks like a home work you have been assigned to do. If this is the case, this would be bad that we write the code for you. You would learn much more if you try by yourself and ask small questions, one at a time, about what you cannot do. You have to prove you have done some research by yourself. And if you did and you can't still find, I'm sure someone here will help you. If you are a developer and faced with a real world problem such as a way to protect some software and make it stop working after one year, then explain that. If this something else, explain what is it. In any case, you have to prove you have done some research by yourself. And if you did and you can't still find, I'm sure someone here will help you. Understood?

You do know that the RTL has its own native streaming framework for that exact purpose, don't you? It is called a DFM. It is not just for designing Forms at design-time. It can be used by anyone to stream any TPersistent-derived class, which includes UI controls. Look at the TStream.WriteComponent() and TStream.ReadComponent() methods. This implies to me that you are probably using overlay classes in C++ (C doesn't have classes) to access private members of those UI classes, by aligning members of the overlay class to coincide with the members of the UI classes. You should not be doing that. But even if you were, there are better ways to access private members, such as this template trick (and this follow-up). Yes, it does. It just doesn't report the size you are thinking of. It only reports the size of the class itself (same as sizeof() does in C/C++), but it does not account for any additional memory that members of that class allocate dynamically for themselves internally (strings, lists, buffers, etc). That only works if you are serializing a class into a stream. You are getting the total flat size of the data the class wrote to the stream, not the size of the class itself.

I'll write almost as you do except: 1) First letter is always uppercase. 2) Constant have no prefix but always all uppercase with underscore to separate words like MAX_CLIENT 3) Local method variable have no prefix at all since all other have a prefix. As you said, it is much of personal taste but your asked so my answer.

waden = want a damn exclusive name

As a guideline: try to remove overhead from prologues and epilogues caused by variables of managed types (explicit or implicit) such as strings or interfaces that are only there for the uncommon path. Another example was the error raising code in the hextobin thread that can be put into a subroutine that gets called only when the rase case of a invalid char occurs. Eric Grange wrote a nice article about this some years ago that I like to recommend: https://www.delphitools.info/2009/05/06/code-optimization-go-for-the-jugular/

Thanks very much for creating a space here for C++Builder users. There is not a lot of community support out there for C++Builder (and none from Embarcadero anymore - what a shame). It looks like the Delphi-PRAXiS forum is well used which is great. Even though I don't use Delphi I still learn about VCL and other topics from the Delphi crowd. Glad to see that it is active.

Thankyou for adding this! I do know of C++ customers who lurk here, semi-anonymously since it's always been for Delphi. I hope we'll see some uptake here now there's an official C++ area. I appreciate you making it, thankyou. Atilla, I'm sorry to see you want to hide it. I hope seeing the sister language / second part f RAD Studio won't bother you or others too much. At Emb, we try to emphasise the benefits of integration (eg, getting access to C++ libraries from Delphi, or math performance, or similar.) I personally feel (from observation) there are many Delphi users who would find a little C++ in their apps a benefit.

It is now available via GetIt as well

Would be nice if you translate all your comments in English.