Leaderboard

Edit: I rewrote this on my blog: https://larsfosdal.blog/2019/10/31/demystifying-pointers-in-delphi/ Having a general understanding of how memory and addressing works, helps a bit for pointers. Learning assembler gives you that knowledge, but there are simpler ways to think about it. A pointer is a memory location that contains the address to the actual data you want Think of a street with houses. Make a list of the houses and their addresses. This is a list of pointers. Each pointer leads to the actual house it refers to. As you move through the list and follow each pointer, you can visit each house. Street of houses (i.e. your blocks of data, 1Kb each) 10k 11k 12k 13k 14K +------------+------------+------------+------------+------------+ |Apple |Pear | |Banana |Orange | | H1 | H2 | | H3 | H4 | | | | | | | +------------+------------+------------+------------+------------+ Your list of addresses (aka 4 byte pointers) is stored at memory address 100k var ptrlist: array[0..3] of pointer; assuming the list has been initialized with the correct addresses ptrlist[0] 100k contains 10k ptrlist[1] 100k+4 contains 11k ptrlist[2] 100k+8 contains 13k ptrlist[3] 100k+12 contains 14k for var ix := 0 to Length(ptrlist) - 1 do begin here, ptrlist[ix] = 10k,11k,13k,14k, and ptrlist[ix]^ = whatever value that is stored in the respective house the pointer addresses f.x. ptrlist[1] contains 11k (and that value is stored at 100k+4, and ptrlist[1]^ points to 'Pear', i.e. whatever is stored from address 11k Why the empty house? To exemplify that your list of pointers may be a consecutive array or linked list, but the data each pointer points to does not necessarily need to be consecutive. Now, if you address ptrlist[4] - you are out of bounds on the pointer list, and if you are so "lucky" that the address @ptrlist[4] (which is 100k+16) is not inaccesible, then ptrlist[4]^ will point you to whatever random value that pointer contains,, and most likely give you an access violation, or for sure - point you to data you are not meant to visit.

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

As part of a service I'm writing using mars, I'm exposing a sign-up page for users to sign up to the service. However, I want to prevent attacks on the service by bots and possibly detect multiple accidental clicks on the submit button. Right now the way I'm considering doing this is by keeping a list of IP addresses and verifying that only one sign-up per time-frame is allowed. I have two questions: 1. Using MARS, how do I read the client's IP address? 2. Are there other recommendations for defending mars?

Eh? No, if I in my host application code keep a TRttiContext and keep around some of those TRtti* instances retrieved they will be or contain dangling references. The removal of TRtti* instances of an unloaded module is triggered from TRttiPool.GetPackageList which only triggers if I go through any methods of TRttiPool which is an internal class accessed by TRttiContext. Been there, suffered from that

Thank you. I have just slightly modified provided code to my taste and get rid of "deprecated" message for JObjectToID on Delphi 10.3.2. Final working for me version is below. uses System.SysUtils, Androidapi.JNI, Androidapi.JNI.Java.Net, Androidapi.JNI.JavaTypes, Androidapi.Helpers, Androidapi.JNIBridge; function BytesToHex(const ABytes: TBytes): string; var I: Integer; begin Result := EmptyStr; for I := Low(ABytes) to High(ABytes) do Result := Result + IntToHex(ABytes[I], 2) + ':'; SetLength(Result, Result.Length - 1); end; function GetMacAddress(const InterfaceName: string = 'wlan0'): string; var LInterfaces: JEnumeration; LInterface: JNetworkInterface; LJavaBytes: TJavaArray<Byte>; LBytes: TBytes; I: Integer; begin Result := EmptyStr; LInterfaces := TJNetworkInterface.JavaClass.getNetworkInterfaces; while LInterfaces.hasMoreElements do begin LInterface := TJNetworkInterface.Wrap(TAndroidHelper.JObjectToID(LInterfaces.nextElement)); if JStringToString(LInterface.getName).ToLower().Equals(InterfaceName) then begin LJavaBytes := LInterface.getHardwareAddress; if LJavaBytes <> nil then begin SetLength(LBytes, LJavaBytes.Length); for I := 0 to LJavaBytes.Length - 1 do LBytes[I] := LJavaBytes.Items[I]; Result := BytesToHex(LBytes); Exit(); end; end; end; end; It seems Mac address is still way to go. At least for a while.

Type delphi pointers into a search engine and start there. I'm sure there will be a mix of hits. Some better than others. Read the top 10, form a view on which are good and which are not. Reread the good ones.

We continue to add Fluent UI demos with our StyleControls VCL. http://www.almdev.com Now you can see project template with UI like MS Paint3D...

Destroy the form when you close it. It's as simple as that. If you want to preserve some state between invocations, put that in a separate object. Forms should just present views anyway, and not be part of your apps business logic.

However, saving an entity before editing does not always help, MMX rarely hangs, but it still happens. But I have new observation. If I manually add new property to the class, but without the getter and setter (as in the picture) and press the ctrl+E shortcut, first the question appears about adding accessor methods and only after clicking "Yes" MMX hangs.

There is another subforum for announcements and information about third-party packages: https://en.delphipraxis.net/forum/13-delphi-third-party/