Leaderboard

It sounds like you haven't realized why the overflow occurs. That would have been step 1; Understand the problem before you try to fix it. The problem is that GetTickCount wraps around every 49.7 days. The documentation for GetTickCount would have told you that. If you reboot Windows the problem "goes away" since GetTickCount will start from zero again. When GetTickCount wraps around the start time becomes "later" than the current time so the delta time becomes negative. Since we are operating on Cardinals (an unsigned type) you get an integer overflow error. The solution is one of the following: Use another algorithm Use GetTickCount64 and Int64 Use signed integers and cast the cardinal result to integer. Disable overflow checks locally for that particular code. In this particular case I would probably go for 3 or 4. It should be noted that this isn't really a bug. It only turned into a bug when you enabled overflow checks. You could have solved this problem on your own if you wanted to. It wasn't a difficult one. It might seem easier to ask somebody else for the solution to a problem, and sure it might even solve that particular problem, but what it doesn't do is give you the ability to solve future problems on your own. How do you suppose the "experienced programmers" acquired their knowledge? They didn't get it by asking for solutions. They got it by analyzing, doing research and experimenting.

Good to know I am not the only one with that kind of setup. And yes, the toolbars are being scrambled on my system too. And I don't even move the IDE between the HighDPI and normal display, it stays on the HighDPI display all the time. That doesn't prevent the problem from occurring though. I have ceated a bug report on this in the new qp (again): IDE toolbars get scrambled over time The toolbars of the IDE lose icons when starting, exiting and restarting the IDE multiple times (see screenshot). This bug had already been reported in the old quality portal for Delphi 11 and 12. It’s still there in Delphi 12.1. Resetting the toolbars to their default using the View → Toolbars → Customize dialog, helps for a while before the same happens again.

A lot being said above, and you need to start and fig deeper and learn why and how. Anyway, this issue is also easy to fix, the cause is this declaration in GR32.pas PColor32Array = ^TColor32Array; TColor32Array = array [0..0] of TColor32; // pain in the back, and will trigger overflow check TArrayOfColor32 = array of TColor32; And the fix or another slap work around without testing but again using my extra power procedure TRenderer.ApplyRemovedTerrain(X, Y, W, H: Integer); type TTempHackColor32Arr = array [0.. MaxInt div SizeOf(TColor32) -1 ] of TColor32; PTempHackColor32Arr = ^TTempHackColor32Arr; var //PhysicsArrPtr, TerrLayerArrPtr: PColor32Array; PhysicsArrPtr, TerrLayerArrPtr: PTempHackColor32Arr; cx, cy: Integer; MapWidth: Integer; // Width of the total PhysicsMap begin // This has two applications: // - Removing all non-solid pixels from rlTerrain (possibly created by blending) // - Removed pixels from PhysicsMap copied to rlTerrain (called when applying a mask from LemGame via RenderInterface) PhysicsArrPtr := PTempHackColor32Arr(PhysicsMap.Bits); TerrLayerArrPtr := PTempHackColor32Arr(fLayers[rlTerrain].Bits); The best is to fix GR32 with the following, but don't do that on your own, this is up to Anders PColor32Array = ^TColor32Array; //TColor32Array = array [0..0] of TColor32; TColor32Array = array [0.. MaxInt div SizeOf(TColor32) -1 ] of TColor32; TArrayOfColor32 = array of TColor32;

Easy. Isn't it?

It already does this. Again, I don't have the code at hand right now, but I remember something like a FLoadLevel which signalled what kind of data had already been loaded so you could call the method again, and if it already loaded the info, skipped the loading, i.e. a cache. So my idea would be to fully update the tree including all the loading in InitializeTreeView, i.e. you would merge SetInfo (edit: only the part that updates the tree) and InitializeTreeView and show a progress while you do that. That would also allow to to get rid of the OnExpanded node handler you added earlier in the thread here. Because of the above cache, it wouldn't actually reload it. Again, I might be wrong, if the user-data does not have the aforementioned cache. Also because e.g. the tree nodes are only updated once - for all future calls to SetInfo a node update is skipped if it's text is non-empty. That way all the initially blank nodes created in InitializeTreeView are updated only once, including image index etc. If any of the user data influences the node text or its image, then it wouldn't be properly updated. Again - might be wrong, can't check. Fair enough - this was merely directed at considering 3rd party tree views. Also because I'm still optimistic it isn't needed.

I am also using the IDE on an HIDPI monitor and simultaneously on a regular one. I also find that the toolbars are all moved or gradually enlarged. In my case, it seems to me that the problem occurs when returning from a computer standby (returning from a lunch break) or even when only the monitor goes into standby because it has been inactive for a few minutes; in these cases, when the PC or monitor reactivates, I see the IDE flickering, and I find the toolbars messed up. To fix them, I also do right-click on the toolbars, select "customize," choose the displayed toolbars, and click the "reset" button, and almost always everything goes back to normal. With this issue, I have often found the sizes of the forms open in the IDE at that moment messed up. Now I am getting into the habit of closing the IDE when I'm not using it and if I have to step away from the PC (which is ridiculous!).

I have created a new Delphi application called ChatLLM for chatting with Large Language Models (LLMs). Its primary purpose is to act as a coding assistant. Features: Supports both cloud based LLM models (ChatGPT) and local models using Ollama. Supports both the legacy completions and the chat/completions endpoints. The chat is organized around multiple topics. Can save and restore the chat history and settings. Streamlined user interface. Syntax highlighting of code (python and pascal). High-DPI awareness. The application uses standard HTTP client and JSON components from the Delphi RTL and can be easily integrated in other Delphi applications. You do not need an API key to use Ollama models and usage is free. It provides access to a large number of LLM models such as codegemma from Google and codelllama from Meta. The downside is that it may take a long time to get answers, depending on the question, the size of the model and the power of your CPU and GPU. Chat topics The chat is organized around topics. You can create new topics and move back and forth between the topics using the next/previous buttons on the toolbar. When you save the chat all topics are soved and then restored when you next start the application. Questions within a topic are asked in the context of the previous questions and answers of that topic. Screenshots: Settings using gpt-3.5-turbo, which is cheaper and faster than gpt-4: UI: Further prompting: The code is not actually correct (Serialize returns a string) but it is close. If you want to test ChatLLM you can download the executable.

Ahh, a typical reaction that started in that time.. My Commodore 64 is much better. My Apple is much better than your Windows My Iphone is much better than you Android phone. My Javascript language is much better than ...

There is a classic, if dusty, article from Donald Knuth: https://pic.plover.com/knuth-GOTO.pdf