aehimself

9 minutes ago, Fr0sT.Brutal said:

Otherwise you must use some kind of concatenating buffer/stream

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));

10 hours ago, Daniel said:

but this is also not StackOverflow

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.

1 minute ago, Stefan Glienke said:

No, because the parameterless TObjectList constructor sets OwnsObjects to True

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.

8 minutes ago, Uwe Raabe said:

    list := TObjectList<V>.Create;

 

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.

1 hour ago, Ian Branch said:

Basically it is a log of events, each entry looking roughly like..

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?

5 hours ago, KenR said:

Very strange. I take it that you just copied the contents of both zips to the bin folder!

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...

26 minutes ago, Fr0sT.Brutal said:

How the bitness of server relates to bitness of client? Nobody requires you to access x64-Apache-driven website with strictly x64 browser.

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

2 hours ago, Anders Melander said:

But why? What problem are you trying to solve?

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:

15 minutes ago, Brandon Staggs said:

ChatGPT agrees.

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

54 minutes ago, David Heffernan said:

I think the answer to the original question is no

I don't know which one is funnier. The actual punchline or the ChatGPT answer.

Well played AI, well played.

I can confirm. Rolling back the patch and my breakpoints are good as new on Win64 platform.

28 minutes ago, pyscripter said:

FWIW, I have tried the unofficial LSP patches and I could no longer debug programs.   So I went back to the original dlls and debugging was available again.   

All my breakpoints just become unavailable (like code never gets executed in that function), did you meet the same issue?