aehimself

Precision-wise probably nothing, multimedia timers are supposed to be the closest you can get. It is transparent though (you can see what is happening under the hood) and it is a drop-in replacement for TTimer which means 0 code change is required. It's also good to leave a variety of options so OP and future visitors can choose their favorite flavor.

I'm sorry, but that command became my Achilles heel. Don't use it.

You can give a try to TThreadedTimer. Not sure if it's that precise at millisecond level but it beats TTimer on everyday use.

I wrote my helper class for this purpose, it can be used and abused as one feels like it: Maybe it worth to revisit that code, I don't remember what lurks within it's lines.

var buffer: TBytes; read: Integer; Begin [...] read := Self.Receive(@buffer[0], Length(buffer));

So we can use ChatGPT for reputation farming? 🙂

You put your files wherever you like, just make sure you add those paths to the global / project settings. Copying them to the Lib is not a good idea so please don't do that 🙂 Let's say you create a folder, C:\DelphiComponents and you start to put your components here. For example, you download ICS and extract it to C:\DelphiComponents\ICS directory. In Delphi, go to Tools -> Options -> Language -> Delphi -> Library. The easiest solution is to add the folder where all source files are to the Library path field in all platforms, in our example C:\DelphiComponents\ICS\Source. At this stage you are ready to install and use the components and you don't have to worry about DCU locations, as the component will compile from the source and compiled DCUs will be placed in the project's own .\$(Platform)\$(Config) directory. Basically, Library path: the place Delphi will look for a referenced file, can either be a pre-compiled DCU or a .PAS source file. DCUs should be compiled in Release configuration Browsing path: locations where the editor's Code Browsing will look for source .PAS files when navigating Debug DCU path: in case you have pre-compiled DCUs in Library path, you can specify the same DCUs but in Debug configuration. During debugging these will be used so you can step in and debug the components source My suggestion is you set your library path to the source of the component and forget about platforms and configs if you are unsure.

So for years now I added that parameter without any particular purpose...? 😮 Time to revisit my old codes, then. Thank you for bringing this to my attention!

I have a hunch you can do the same if you override the protected Notify method somehow but yes, Uwe's solution will definitely work. Shouldn't this be TObjectList<V>.Create(True); ?

The only downside is, when adding a new key you'll have to do two commands: _dictionary.Add(myKey, TObjectList<TMyClass>.Create); _dictionary[myKey].Add(myObject); The neat thing is, you can nest them down until infinity, if you have the stomach to bear it. I personally start to feel uncomfortable after 2 🙂

Only if you create them like: TObjectDictionary<T>.Create([doOwnsValues]); TObjectList<T>.Create(True);

You always can use a TObjectDictionary<String, TObjectList<TMyClass>>. That way you can have multiple instances of TMyClass assigned to the same string key.

There are also open-source alternatives: https://github.com/MahdiSafsafi/DebugEngine https://github.com/Fr0sT-Brutal/Delphi_StackTraces I never used JCL as I only wanted stack traces and I had to import half of the library just to achieve that.

I know I'm being picky, so feel free to completely ignore my "suggestions". But, in the era of OOP you might want to consider plucking all logic into a class, like TGamePascalGame. So instead of GameRun(nil, GameEvents); you simply could derive from TGamePascalGame, and say... mygame := TMyGameDerivedFromGamePascalGame.Create; Try mygame.Run; Finally mygame.Free; End; With this you immediately can get rid of the mandatory, huge Case statement in the method and simply provide a protected virtual procedure like DoStartup, DoShutdown, DoUpdate, DoRender and DoRenderHUD what your consumers can simply override. If you are thinking on the long run this will also make your life easier as adding new controllable features can simply be published by properties: mygame := TMyGameDerivedFromGamePascalGame.Create; Try mygame.EnableHardwareAcceleration := True; mygame.DataFolder := IncludeTrailigPathDelimiter(ExtractFilePath(ParamStr(0))) + 'mods'; mygame.HResolution := 1024; mygame.VResolution := 768; mygame.VSync := False; mygame.FullScreen := True; // etc, etc.. mygame.Run; Finally mygame.Free; End; The demo looks really good. I was thinking on trying myself out in game development so an easy-to-use library could keep my initial struggles at a minimum. So keep up the good work, I'll keep an eye on the repo for sure!

...and 64-bit breakpoints broke again today using the patch.

If it's a log, definitely put them in a separate table, one log entry being one record, and store the timestamp in a separate field. Maybe even add a log category field, like "backgroundworker", "httpserver", "cache". On the long run, being able to quickly search log entries between a specified timeframe is a lifesaver!

Depends on your application. I'd break the list up to elements (and store them in their separate table) because of two reasons: - You can use simple VarChar fields instead of MEMO / CLOB, which is more easy on resources - You can filter the list with your select if needed Edit: by having their own table you can even extend each list element with further properties later on

You might want to include the differences, pros and cons in the GitHub readme not to leave the impression of a library that gets outdated as soon as you get used to it. Let's leave that feature to some JavaScript frameworks 🙂

It would be nice to see an actual demo of what the engine can do. Things are a little bit confusing, what happened to GameVision toolkit, and what it Delphi GameKit?

My process: - Install 11.2 and use it - Rename 4 affected files to *.*.original - Unzip both unofficial fixes to \bin folder - Try to use it, breakpoints broken, so - Rename patched files to *.*.patched, rename *.*.original to *.* and use it - Since 32 bit is working and DelphiLSP.exe is a part of the 32 bit version, I decided to use 32 bit version only. Rename those files to .original, rename .patched to normal - Breakpoints working, so I start to wonder and do the same with 64bit - Confused as hell, as it's working...?!

I honestly can not understand this patch. After reverting back to the original files and reapplying it, breakpoints work fine on 64 bit as well, even in a new method of an unsaved unit...

You really never heard of amd-x64.google.com or itanium64.en.delphipraxis.net? 😄

I have only one valid explanation, which is I usually forget to sync and build a new language file and therefore the .xlat goes in in a separate commit. However, for the actual translation you need the GUI anyway and if you update the .xlat beforehand, you'll have no idea if there was a change or not (especially if we'll have the option to see changed entries only). So after all it would solve my issue of the file going in in a separate commit, but it's still not translated and built, so it would add no actual value.

@Anders Melander Was does this mean? 🙂 Edit: A nice addition would be to have an option to show only changed entries (whether added, obsoleted or marked as unused). That would probably tell me if I should be worried. Edit-edit: Git showed it. An item has been un-unused:

Ask if it has any affiliation to / what it knows about SkyNet as it already seems to be self-aware 😮