![Delphi-PRAXiS [en]](https://en.delphipraxis.net/uploads/monthly_2018_12/logo.png.be76d93fcd709295cb24de51900e5888.png){kind=logo}
All Activity
This stream auto-updates
- Past hour
-
Seems back to normal for me. 👍
-
Destroying a TThread recreating TThread the destroying again hangs Process
Kas Ob. replied to JackT's topic in Delphi IDE and APIs
By not returning TThread in the first place, and using smaller creature (TAnonThread, TThreadWorker, TThreadedRoutine....) with only can-be-used properties (with getter/setter) before start, now let see what one can use before start,... hmmm... nothing !, except priority and name and a maximum of three events OnBeforeExecute, OnDoneExecute and OnTerminate, everything else is useless and dangerous from this point after the method "Start" CreateAnonymousThread is mute and return a class that can not be extended, so fundamentally is wrong to return a class that has dangerous publics, it should return a class that can't be abused, right ? (by the way i don't use anonymous thread and hate them more than anything, their exceptions are anonymous and their call stack is unreadable and different platform like ARM their exceptions are fatal and time wasting), Now back to FreeOnTerminate, the danger of using FreeOnTerminate is coming from it allowed to be used and might work, but really put the undefined behavior in hidden state that might fail in the future or with different parameters like parsing smaller files than expected or under different OS state, what i am saying is that if WaitFor worked most the time but hid that dangerous behavior then the the design should be fixed, and it should raised exception with FreeOnTerminate is True on lets say WaitFor, this will prevent the working state (the dangerous state) from stay hidden and force the developer to rethink their design, so no more it it is working fine then it will work forever fine. - Today
-
That is correct, I also wondered why this was not simply copied to the main Embarcadero/37.0/PAServer/ folder, as it should be the normal way patches shall work, IMHO. I also had to search this for little while.
-
fatersoft joined the community
-
var connectionstatus : DWORD; Result := InternetGetConnectedState( @connectionstatus, 0); ( Google InternetGetConnectedState to get all the info. Result is a boolean in this case )
-
TR_HS joined the community
-
I have faced the similar issue with D13 when the 13Patch package failed to install. Solution is to clean-up a Registry Item values: Computer\HKEY_CURRENT_USER\Software\Embarcadero\BDS<BDSVER>\CatalogRepository\DeferredComponentsInstallFailed Computer\HKEY_CURRENT_USER\Software\Embarcadero\BDS\<BDSVER>\CatalogRepository\DeferredComponents (this is optional if you do not want GetIt install a deferred packages on next RAD Studio launch). P.S. Do not forget to replace <BDSVER> with the actual RAD Studio version
- Yesterday
-
When I turned on the code insight that restored greying out inactive code in an IFDEF, the Find Declaration came back.
-
Offline Help updates available from Embarcadero
DelphiUdIT replied to DelphiUdIT's topic in Delphi IDE and APIs
This is the new link for offline help chm updates. https://docwiki.embarcadero.com/docs/products/rad_studio/ The help published now works offline, the original released and the previous update didn't work offline. The help files are dated September 11, 2025. -
Yes, there is here.
-
"Find declaration" stopped working in Delphi 13
efortier replied to Jud's topic in Delphi IDE and APIs
At some point, everything stops working; Find declaration, Error insight, etc. When that happens, try the following. I am not sure it will work for you, but for me that was the cause of so many aches that I made an expert that does it for me. Try this: 1- Delete ALL .DCU files that your project or the DelphiLSP can see. For me, that was *.DCU in my project directory. 2- From the tools menu, restart the LSP server. 3- Wait 5-15 seconds. For me, this solves the problem. Note: a "Clean" does not fix the problem for me because there are always some DCU file left. I found out that when the LSP server encounters some DCU file it completely stops working. And since a lot of the IDE functionality is based on the server, a lot of things break. Very janky workaround. This has been going on since Delphi 12. Someone at Embarcadero told me the disabling of "legacy" code in Delphi (refactoring, find references, etc) will allow them to rebuilt the features better and improve the LSP. Right now, the sad state of release 13 prevents me from using it. HTH! -
Destroying a TThread recreating TThread the destroying again hangs Process
Dalija Prasnikar replied to JackT's topic in Delphi IDE and APIs
Because TThread can be self destroying or not based on the value in FreeOnTerminate property which can be configured after construction. Besides that property, there are others that can be configured before thread starts running, Also how would you prevent developers from taking reference of any abstract class that is meant to be extended and is therefore publicly accessible? -
https://en.delphipraxis.net/topic/7289-line-break-after-i-type-if/
-
Thanks, that was the problem! I had "none" selected. I turned off a lot of this stuff because it is so annoying for it to add "True then" every time I type "if".
-
Cursor positions in multiple edit windows
Uwe Raabe replied to dummzeuch's topic in Delphi IDE and APIs
IMHO, that is an oversight (i.e. nobody raised this use case in the past, so nobody added that to the specification). The ToolsAPI provides IOTAEditLineTracker to handle that. Getting the cursor position of an EditView tracked while being deactivated should be an overseeable task. I suggest filing a report. Multiple EditViews of the same source seem to be used rarely. We need more reports like that to drag some attention to it. -
I just noticed that the cursor position in additional edit windows does not move if I insert new lines above it. E.g. In EditView1, the cursor is in line 10. In EditView2, the cursor is in line 15. In EditView3 I insert a new line above line 5. I would expect the cursor position in EditView1 move to line 11 and in EditView2 move to line 16, so they stay at their positions relative to the source code. But apparently that's not the case. Is that a bug or working as designed? The reason why I as noticing this: If just fixed bug #450: Formatter does not store cursor position of additional edit windows in GExperts. But now I wonder whether I should have bothered, since the IDE apparently doesn't handle this either.
-
Is there any Delphi component/library/code for IOS development that can detect whether internet connection is present or not present and what type of connection if present [Cellular or WIFI]
-
abaloush joined the community
-
Destroying a TThread recreating TThread the destroying again hangs Process
Kas Ob. replied to JackT's topic in Delphi IDE and APIs
So what is/was the point from design point to return TThread ? (shouldn't be different creature with single method "Start") I know the details, i pointing the failure to protect the developer by design and depending on well you have been warned (somewhere). IMHO, once FreeOnTerminate is true then most methods should raise exception to make sure it will work always as expected, not sometimes, and here i am pointing to the fact FreeOnTerminate was runtime adjustable at anytime, while it should fixed since the creating that TThread, again it is my opinion. -
Destroying a TThread recreating TThread the destroying again hangs Process
Dalija Prasnikar replied to JackT's topic in Delphi IDE and APIs
I guess it was not anticipated that developers would store references to self destroying threads. And without having a reference you cannot wait for such thread. References to self destroying threads basically become invalid the moment the thread is started and they can only be used for initial configuration for threads that were created in suspended state. Once thread starts running, you should not touch the reference anymore. From documentation: https://docwiki.embarcadero.com/Libraries/Athens/en/System.Classes.TThread.CreateAnonymousThread https://docwiki.embarcadero.com/Libraries/Athens/en/System.Classes.TThread.FreeOnTerminate I am not going to discuss about how one can potentially use anonymous threads beyond their intended purpose: being fire and forget kind of thread, because such code can be very fragile and cause more problems than it solves. And like I mentioned earlier in this thread, without having a very specific code and a use case, it can be hard to discuss potential problems and solutions because in multithreading even slight changes in code and how it is used can make a huge difference and break it. -
It does not work when the Code Insight Manager is set to Classic Code Insight, but that is expected.
-
Greying out suppressed code is working as expected in D13 for the ICS component library. ICS has a lot of defines and optional code, greying is a very useful feature. Angus
-
Destroying a TThread recreating TThread the destroying again hangs Process
Kas Ob. replied to JackT's topic in Delphi IDE and APIs
Great, correct and make sense, but the documentation should say so, also that is bad design in the first place, and i don't want to go there, but have to say you don't design such always loaded foot gun and remove the safety. Someone should open a ticket and request to make WaitFor raise an exception in case the FreeOnTerminate is true, doesn't that make more sense ? -
Hi Team, We went to Daylight savings in Australia this morning. At this moment my local date time is Sun 5 Oct'25 @ approx 13:54. Using Delphi 12, if I try to create a new Unit I get this: I am running Windows 11. I have checked my date/time sync: All seems good: Any thoughts/suggestions appreciated. Regards & TIA, Ian
-
In addition to greying out unused code in IFDEFs not working for me in Delphi 13 (another tread), now "Find declaration" has stopped working in Delphi 13. I've tried Building the project, restarting the IDE, and rebooting the computer - nothing helped. Does anyone else have this problem?
-
Best strategy to set up global Release/DebugDCU paths in the IDE, as example for Spring4D DCUs
pyscripter replied to HaSo4's topic in Delphi IDE and APIs
What @Anders Melander is advocating is closer to how people work in python. For every project you create a self-contained virtual environment that includes all the dependences. Python has the tools to make this workable and fast. The equivalent in Delphi would be to have for every project a virtual machine with the required version of Delphi installed and just the dependencies you need. But this is not as practical, with Delphi. FWIW, what I do for projects of moderate size (about 1m lines including dependencies) is: Minimize the use of third party tools. For instance, although I know that the Spring4D collections are better than the RTL ones and that there are faster JSON libraries than System.JSON I stick to the RTL libraries. Having said that, PyScripter has 16 external dependencies, many of which I developed or maintain. Only use open source projects with available source code, preferably actively maintained. Try to use the latest versions of all dependencies and Delphi. This sometimes leads to incompatibilities and troubles, but I think that the benefit of getting the latest features and bug fixes outweighs the trouble. My library paths point to the source code (typically in cloned git repos) and not the compiled dcus. I know this will be frowned upon. However, in my case it saves me time. When a dependency gets updated, I just pull the latest updates from the git repo without having to install the components. When I upgrade to a new Delphi version, I use MultiInstaller to install all the dependencies in one step. MultiInstaller can install dependencies from git repos, zip files or existing folders. It can also install components in the 64 bit IDE of Delphi 13. The whole process takes minutes not hours. - Last week
-
I thought it was working the other day, but I'm not certain. I just noticed that it wasn't working yesterday. I was using 12.3 and installed 13.0. It is still working in 12.3 (same computer).
-
Destroying a TThread recreating TThread the destroying again hangs Process
Remy Lebeau replied to JackT's topic in Delphi IDE and APIs
Yes, there is - use the TThread.OnTerminate event to signal your waiting code, such as via a TEvent object. Just know that the event handler is called in the main thread, so if that will cause a sync issue, you can always override the TThread.DoTerminate() method to call the OnTerminate handler directly (or do anything else) without syncing it, as DoTerminate() is called in the worker thread and calls the OnTerminate handle via TThread.Synchronize() by default.
