santiago

I also voted for this. Whenever I close the project, the IDE jumps to another monitor. If I reopen the project it jumps back to the previous monitor. I have always found that extremely annoying. Thx for creating the ticket! 🙂

For those of us that depend/rely on IDE Fix Pack. I have not upgraded to Rio update 2 because IDE Fix Pack is not available for it yet. This thread mentions a workaround, but it involves disabling a couple of patches. Anyhow, Russell Weetch (@urbancohort) suggested on Twitter that Andy should be granted a lifetime subscription for Delphi. It seems he does not have access to the latest releases. So I went ahead and opened a support case at Embarcadero asking for this: https://quality.embarcadero.com/browse/RSP-24928?filter=-2 So please vote for this issue, if you are a IDE Fix Pack user.

Great!!! 🙂

I am using Delphi Rio Update 1. I rebuilt our App. It consists of 24 packages. A little over 2 Mio. lines of code. This took 1 minute 38 secs. I then closed the Delphi IDE and uninstalled the IDE Fix Pack. Reopened Delphi and rebuilt our App. Now it took 2 minutes 4 secs. As far as I can tell it still provides benefits with the Delphi Rio Update 1.

Thanks Daniel! It is good to know that some of the fixes already went into the product. Do you happen to know why why not all of the fixes went into the product?

Hi there, when a TObject is instantiated, the following function is called: TObject.NewInstance: TObject; The code in this function is straightforward. It calls GetMem with the InstanceSize to allocate the necessary memory for the object. GetMem returns a pointer to the allocated memory space. class function TObject.NewInstance: TObject; begin Result := InitInstance(_GetMem(InstanceSize)); {$IFDEF AUTOREFCOUNT} Result.FRefCount := 1; {$ENDIF} end; The pointer to the allocated memory is passed to TObject.InitInstance(Instance: Pointer): TObject; This function is implemented in assembler. I do not understand what happens here. I am struggling to understand the relationship between the memory address returned by GetMem and the pointer address of the instantiated TObject. Look at this very simple code: DummyObject := TObject.Create; // DummyObject is declared as TObject DummyPointer := @DummyObject; // DummyPointer is declared as Pointer For example: With the debugger I can see that the call to GetMem returned the address: 04AEFA60 (in decimal 78576224) But DummyPointer is pointing to the following address: 69FC6BE0 (in decimal 1778150368) The addresses are completely unrelated. Does anyone have an explanation for this? I tried the same with TStringList. The GetMem address and the pointer address are also completely different. The delta between them is also different than the TObject delta. However for objects derived from TInterfacedObject there is a constant delta of 12 bytes, between the GetMem address and the pointer address. Why do I need this? I have the GetMem address which was used to instantiate a given object. I need to be able to convert the GetMem address to the object pointer address. That way I can obtain a reference to the TObject which I can then Rtti inspect. Thank you!

Thanks, got it! What I needed to do was: DummyPointer := Pointer(DummyObject);

Hi there, I need to be notified whenever any TObject is created/freed. (for debugging purposes). I have not found anything so far. Maybe someone knows of a way? Two ideas I have are: Look deeper into FastMM4. Maybe FastMM provides some mechanism to be notified of such events. See if it is possible to hijack the TObject Create and Destroy functions. Replace them with a function of mine, and then call the original function afterwards. My function would be acting like some sort of tranparent proxy. As of now I have no idea how to accomplish this, but this is something I want to investigate. Would be very grateful is someone has more insight into this.

This is the best solution I have found so far. It might be of use to someone else. I call GetMemoryManager to retrieve the FastMM memory manager and keep a reference to it. I then register my own memory manager. I only provide new implementations of GetMem and FreeMem. For all other calls I just forward the call to the FastMM memory manager. In my implementation of GetMem, I first delegate the call to the FastMM memory manager. I then call the FastMM function DetectClassInstance. {Returns the class for a memory block. Returns nil if it is not a valid class} function DetectClassInstance(APointer: Pointer): TClass; I was actually not expecting this to work, as I thought that calling this function at this stage would be way too early, and the call would always return nil. But to my pleasant surprise, it works. It returns the TClass for the just allocated memory block. 🙂

Yes we do use weak references to avoid circular references. We only pass delphi interfaces to .NET and we rely on the .NET COM interop functionallity to manage the delphi object lifetime.

We can compile our app with or without runtime packages. Unfortunately AQ Time crashes whenever I load our exe and it is NOT using runtime packages. I suspect that the problem is related to some third paty component, as I had used AQTime after the Win10 creators update. It was slow, but at least I could work with it.

@Pawel Piotrowski We do use madExcept. I need the leak report between snapshots though. While the application is still runnning.

@PeterBelow Our program is leaking memory. If I perform a certain calculation, there are some left-over objects that should no longer be referenced, but are alive. What I need is the ability to create snapshots while the program is running. That way I can compare two snapshots and figure out which objects are still alive in the later snapshot and of course be able to have the callstack to how these objects were created. In the past I have used the AQTime allocation profiler for investigating such issues. The problem is that AQtime has become practically unusable for us. Performing a particular calculation while AQTime is attached takes forever. Our app is a Delphi App, but makes heavy use of .NET and unmanaged (c++) dll's. So far I have not been able to figure out what the reason for the massive AQTime slowdown is. So I extended an internal tool that we use for debugging with the functionality I described above. In order to have an object be taken into account, I need to derive from a special base class. This works well, is what I need. At a any point in time I have insight into live objects (incl. callstack, and can also RTTI-Inspect them). I am just looking for a way of avoiding having to change the base classes of the objects that I wish to inspect, and automatically take all objects into account. Unfortunately our base classes inherit directly from TInterfacedObject. There are also many, many classes that inherit directly from TInterfacedObject. That is why I would need to change many classes to take them all into account. Maybe I just need to bite the bullet and build in a common base class. That would would make it really easy...

@Attila Kovacs I gave it another go, and it does indeed work. Don't know what I did wrong the first time I tried... I also tested if multiple TApplicationEvents can be used simultaneously. This also works well. Thank you!

Thx, good to know!! I will give it another shot tomorrow. 🙂

@dummzeuch this plugin is only for internal use. I am chaining the event. For my use case the TApplicationEvents class which was recommended by @Attila Kovacs seems to be a good choice. Unfortunately, I could not get it to work. Have you used this class inside an ide plugin? If I understand correctly this would allow multiple event subcribers to coexist.

@Attila Kovacs yes I am keeping a reference to the previous handler in case it was set. I would prefer to use TApplicationEvents though. Thx for the tip. Unfortunately I could not get it to work. FApplicationEvents := TApplicationEvents.Create(EditWindow.Form);// nil); FApplicationEvents.OnMessage := ApplicationEventsMessage; The callback method (ApplicationEventsMessage) was never called. I also tried without setting an owner.

@Uwe Raabe The file is read-only. So unfortunately, the EditorViewModified event will never be triggered. I got it to work. Here is a high level overview of how it works, in case it might be of help to someone else: I react to the INTAEditServicesNotifier.EditorViewModified event. This is triggered whenever a new editor window is activated. Here I can easily detect whether the source file is read only or not, using EditView.Buffer.IsReadOnly. The trickiest part was then getting the handle of the editor control window (TEditControl). The Open Tools Api provides no functionality for that. It does provide you with the IDE's TCustomForm though (INTAEditWindow.Form). With the form you can find the editor control by searching for a child component with ClassName = 'TEditControl' and ComponentName = 'Editor'. Instead of working with a Windows Hook, I just added a handler for Application.OnMessage. procedure TEditorNotifier.ApplicationEventsMessage(var Msg: tagMSG; var Handled: Boolean); begin if (Msg.message = WM_KEYDOWN) and (FEditControl.Handle = Msg.hwnd) then begin // magic happens... end; if not Handled and Assigned(FPreviousMessageEvent) then FPreviousMessageEvent(Msg, Handled); end;

Hi there, On one PC we have this error when starting the IDE (Rio update 1 and Tokyo). The IDE is no longer stable and crashes constantly. So we had to uninstall IDE Fix Pack (v. 6.4.2.) We even uninstalled Delphi. reinstalled it, and then reinstalled the IDE Fix Pack. But the problem always occurs. We have several other PC's which are working just fine. Problem affects only this PC so far. Any ideas? Thanks!

Thanks for the reply! Registry seems to be fine though. My colleague was just able to fix the problem. He copied these two dll's: dcc32260.dll dcc32250.dll from another PC. Somehow they were missing on his PC. That fixed the problem. Anyhow something strange seems to have gone wrong during installation.

We use Rio.1 (heavily), GExperts, MMXExplorer as well as Parnassus Bookmarks and Navigator. We have not experienced such issues when closing the IDE.

Hi there, I want to develop a plug-in for the Delphi IDE. In that plug-in I want to be notified after a DFM file has been saved. I have been looking at the Open Tools API and am a little unsure about how to proceed. What I have found is that it is possible to attach a IOTAModuleNotifier to a Module (IOTAModule40.AddNotifier). The notifier 'AfterSave' method should be called after the module is saved. But this means that I have to keep track of all open modules and make sure to attach/detach notifiers. Ideally I would be able to register one global Notifier, that would be called everytime a file is saved. I could then check if the file is a form (*.dfm) and take appropriate action. I have not found a way to do this. Anyone know if this possible? Thank you!

@Uwe Raabe Thanks! Will give it a shot now 🙂

Hello there, I just upgraded our app to Delphi 10.3. The source code is identical to what we compile with Tokyo. I have installed the same 3rd Party Components in Tokyo/Rio (madExcept, MMX Explorer, G-Experts, Rem Objects Hydra, DevExpress VCL) If I do a 'Build All' in Tokyo, the elapsed time is 1min 14 sec. In Rio the elapsed time almost doubles to 2min 19 sec. What I notice is that while Rio is compiling the layout combo box selector and the search box (on the title bar) are constantly flickering, ca. 1.9 Mio lines of code. Is anyone else experiencing this?

@Attila Kovacs With theming disabled the problem does not ocurr. Since I do not need to move the IDE to another monitor frequently it is not a big problem. At least I know what causes it and how to easily workaround it.