Davide Angeli

To get that kind of info from a file I use the JCL class TJvVersionInfo (https://github.com/project-jedi/jvcl/blob/master/jvcl/run/JvVersionInfo.pas) that is a wrapper of that kind API. For me it works both 32 and 64 bit.

I'm using SecureBlackBox for other purpose (quite expensive tool!). In the suite (very rich) there is also an SFTP client: https://cdn.nsoftware.com/help/SBJ/dlp/SFTPClient.htm#SFTPClient

Hi all, if I try a reverse assignement on a code like this one: O.F['v1']:=edV1.AsCurrency; // RA - Value 1 O.F['v2']:=edV2.AsCurrency; // RA - Value 2 O.F['v3']:=edV3.AsCurrency; // RA - Value 3 O.S['v4']:=edV4.AsString; // RA - Value 4 O.S['v5']:=edV4.AsString; // RA - Value 5 I got this one: edV1.AsCurrency := O.F['v1']; edV2.AsCurrency := // RA - Value 1 O.F['v2']; edV3.AsCurrency := // RA - Value 2 O.F['v3']; edV4.AsString := // RA - Value 3 O.S['v4']; edV4.AsString := // RA - Value 4 O.S['v5']; it seems to have problems with end-of-line comments. Is this the right place to report bugs?

TControlList

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 don't know if could help but a rewrite of the old dependency walker is here: https://github.com/lucasg/Dependencies

With Delphi 12.1, this error has reappeared quite annoyingly... With Delphi 11.3, I had practically forgotten about it (it never happened to me). Obviously, the error is completely random and disappears when closing and reopening the IDE. But is there no way to get more information from the compiler about the error to understand if it's possible to do something to prevent it? However, it always occurs in the context of a global recompilation of a project group that contains both runtime packages, DLLs, and executables.

https://embt.atlassian.net/servicedesk/customer/portal/1/RSS-611

I've just switch to 12.1 too (from 11.3). For me no longer works the block selection mode: combination CTRL+O+C doesn't work properly.

I'm using almost only this library to interact with json stuff and for me it works fine. This library is the json serialization/deserialization base tool for the REST library WiRL https://github.com/paolo-rossi/WiRL (other great free tool that I'm using). I'm also using NEON to interact without problem (and forgetting what json is) with some web services like Brevo, Skebby and others.

Yes I totally agree I'm using frames in my projects sometimes in descendant forms and this is the biggest problem I have encountered. Especially in managing events on descendant frame components that often become disconnected. At some point I started managing and connecting them at runtime.

Hi, I'm using D11.3 on HIDPI monitor 3840x2160 with 200% zoom (Windows 11). I've just updated GExpert to latest r4210 and now I'm experiencing some annoying problems realated to hidpi: "Procedure List" is unusable: the form is opened incredibly big it is even larger than the screen and only the first column with a very large font is visible. The only way to move is to press alt-space The "Grep Results" window is a mess: has some parts very small, some big same normal.. Grep Results: Procedure List

Done

I don't know if this can help and perhaps you have already done this, but according to FB4 documentation, to use embedded version to connect to one database from several applications, you need to set the parameter "ServerMode" as "Classic" in firebird.conf (this was the default behaviour of FB2.5 embedded now changed in FB4 in "Super"). https://ib-aid.com/download/docs/fb4migrationguide.html (read section "1.5 Installing Embedded") firebird.conf comments: # ============================ # Settings for Architecture Configuration # ============================ # # Controls the method Firebird engine uses to work with databases and # related Firebird server startup parameters. # # The values are: # Super / ThreadedDedicated - databases are opened exclusive by single server process, # attachments share single DB pages cache inside process # SuperClassic / ThreadedShared - databases are opened by single server process, # but it does not prevent opening them in other processes (embedded access), # each attachment has its own DB pages cache # Classic / MultiProcess - for each attachment to server a separate process is started, # each database may be opened by multiple processes (including local ones for # embedded access), each attachment (process) has its own DB pages cache # # Type: string # #ServerMode = Super

True!!! Thanks for help!

I spent some time to deep analize the MadExcept callstack and I discovered that the thread in exception was created by another thread not even executing (I can't find his "father" in the thread list reported by madExcept). Now I've rearranged same things in the steps involved in the app terminating phase to avoid this; I've also moved the IOmniTimedTask instance as a global variable to avoid strange dependencies. Now I cannot reproduce the error. So OTL seems working fine as usual! It's always a mess working with threads!

It depends... I use both I'm using madExcept

I abandoned that trail: the problem is not the REST call. I've substituted it with a sleep(1000) and I get the same random error... The problem is somewhere else. Still investigating...

WiRL client seems using THTTPClient.Get and then THTTPClient.DoExecute to execute my REST operation (a PATCH). So I suppose that it is synchronous.

I rely on the fact that by calling the stop method it waits and completes any ongoing operations. When the application ends, each TimedTask is stopped and its end is awaited. But in fact, if the REST execution is asynchronous, this might still be running. I don't know how the WiRL client works at a low level. Now I'll delve deeper.

It's not so easy to debug this; when I debug and put breakpoints inside threads, thanking our beloved IDE, I get often debugger freezes. In my case "DoSomething" code is a simple rest call (I use WiRL client to send data to WiRL server); the rest call is incapsulated in a try except to avoid errors. Til now my "DoSomething" was an anonymous method. Now I've changed my code and I pass a normal procedure to timedtask.execute. Things seem to going better but I don't think this was the cause of the error.

Before posting I tried several solutions, some of these suggested in this post: According to Primoz OTL book it seems to be enough to assign the IOmniTimedTask instance to nil to get the call to Terminate(INFINITE) and Terminate should stop the task... This works perfectley in a little sample demo. In my case leads to random errors (the app is very complex). I've tried calling the Stop method and then assign the instance to nil but I get the random errors too. I've tried calling also Stop + Terminate(INFINTE) + WaitFor(INFINITE) + assigning to nil without results

I recently started using Parallel.TimedTask and now when I close the application I get the same error in completely random mode. I can't simulate the problem in a small project. I'm using D11.3 and the latest OTL version. Some idea?

too many "w" in links 😊

On QP is set as resolved in D12.... https://quality.embarcadero.com/browse/RSP-42024