msohn

I think the general approach of using form inheritance is not really suitable here, even though it might seem intriguing. In the past I've seen people write generators for this kind of work, make IDE extensions to create new specialised forms or just add preconfigured components from templates and anything between those extremes. I suspect for you it's more than just the actions, but for actions I once wrote a component editor for TActionList so I could invoke a little GUI at designtime which would then allow me to add a bunch of actions related to a custom component I had written. Maybe that's an option for you too.

My guess would be that the Designer is not yet available when Loaded is called on your actions. Looking back at your initial post on what you actually wanted to achieve: why do you want to replace the placeholder at design time? Why not just do it at runtime? I.e. leave the action alone if csDesigning is set and only modify it at runtime. That seems the cleaner approach to me.

How did you verify this? Of course if you just run the code in an application of yours it will be nil. After you modified the code, you need to recompile the package which contains the code for the component and you need to make sure the IDE is actually using that modified version. If everything else fails, you need to debug the package by running a second instance of the IDE under the debugger.

A quick google search brought up this: https://stackoverflow.com/questions/31740385/vcl-events-handles-designer-modified So you can set Designer.Modified via the parent form - but checks for csDesigning and Designer <> nil are required. Also you should obviously set Modified only if you've actually modified something.

Yes that info is outdated. Apple is providing and updating its own virtualisation framework for a couple of years now and the linked VirtualBuddy app is using that and "just" provides a GUI around it. FWIW also other tools like Parallels make use of that framework (sometimes as an alternative, sometimes, like macOS ARM guest on a macOS ARM host, it's the only available way). The problem is that the virtualisation framework is still quite limited, i.e. you still can't route USB devices into the virtual machine. That's a showstopper for me, so I'm stuck on Intel hardware for now, when it comes to debugging a macOS app and I need USB hardware. Other Delphi code or some sample in Xcode? This could still be some network thing. But good luck finding something there - google is full of network issues in Sequoia.

I'm afraid I can't add anything really helpful, but for me debugging and deploying has been painfully slow for a long time now. But that might very well be caused by the IDE running in a VM and debugging in a macOS VM with both running on the same machine. So a minute and more for deployment and the GUI to show up, even for a trivial project is the norm. But even once it runs, stepping through the code is painfully slow and I do get timeouts etc. from time to time. Have you tried debugging something trivial with Xcode to see if the debugging in general is affected? If you're suspecting the Sequoia update, one option would be to prove that with a VM and debug in there before and after updating Sequoia. If your virtualisation app cannot do macOS VMs on Apple Silicon, I can recommend VirtualBuddy.

Could you elaborate on what you found impossible to do with .pkg files? FWIW we use Packages as a comfortable way to build these. And if all else fails, you could make the .pkg run a shell script so there's almost no limit on what you can do.

Thanks for sharing Anders. I regularly run into tickets by you on the DX support site and I'm often impressed how well written and researched these are. I bet the support guys at DX very much remember your name by now 😉 FWIW I "starred" a few tickets which I'd like to see fixed as well - one can only hope. Yes that is exactly my experience as well. Sometimes one feels like your hands are being tied, but then you just need to remember how much more tedious it was without the LayoutControl. Yes that's also exactly what I did - specifically TheBezier skin with different palettes and an unskinned mode where main forms are lfOffice11 (yeah I know, looks a bit old) and all dialogs use NativeStyle - this was the original look and was kept for people not wanting to adapt the looks.

We already used ExpressBars in most of the places. And just like TListView and TTreeView (regardless if original or cx version) don't support SVGs and skinning properly, so is the skinning and SVG support for TMainMenu et al very limited. With regard to TPopupMenu, if you need to use a control which cannot handle TcxPopupMenu, you can just handle popping up the menu manually via an OnContextPopup even handler (not sure if this is the right name). But I freely admit, this is only giving good results if you go all-in on the DX controls and it's a lot of work. But for us this was just a logical conclusion and it made us clean up very old parts of the GUI. The end result using TdxLayoutControl etc. is much more flexible than it ever was before.

I spent a major part of the last 4 years making our application here HighDPI compliant. And I ended up using DevExpress TcxImageList exclusively with SVGs, partially custom made. SVGs not only solve the DPI problem, they also feature a skin-adaptable palette, so that if your app has e.g. a light and a dark skin, the SVGs actually adapt their color (which they have to, to be identifiable in dark mode). With this approach a centralised ImageList is absolutely no problem - in fact you can request a specific image from the list in any desirable size/scale e.g. for use in custom drawings etc. Would you be willing to share more info on what these are, e.g. links to DX support issues? Littering code with workarounds sounds awful. I remember that back in maybe 2020 there were still a few issues, especially with the adaptable SVG palette, but with the 2022 version and RX 11.2 I'm currently using I'm actually very satisfied. I had to stop using TcxTreeView and TcxListView altogether, they are just shells around the native controls and as such do not support proper skinning and scaling as well as the SVG palettes. DX also made it quite clear that they don't intend to put more work into these controls, but rather in the alternatives TcxTreeList and TdxListViewControl. And since TcxTreeList is also capable to replace TVirtualTreeView I went this route.

There's an excellent blog post by Vincent Parret: https://www.finalbuilder.com/resources/blogs/code-signing-with-usb-tokens

You only need to make sure you compile a universal binary. Packing and deployment is unaffected. Ensure the ARM64 platform is enabled and the compiler option set as described here: https://docwiki.embarcadero.com/RADStudio/Athens/en/Delphi_Considerations_for_Multi-Device_Applications#Universal_Binaries

Yes there is. Have a look at TSelectionEditor and its RequiresUnits method: https://docwiki.embarcadero.com/Libraries/Alexandria/en/DesignEditors.TSelectionEditor Many 3rd party products do this (e.g. DevExpress) especially when components have event handlers containing types that are defined in another unit. Because adding such an event handler will otherwise break compiling and the user going on a hunt for the unit.

You're missing TObject.InitInstance which ensures all fields are initialised before the constructor is called. Edit: link for convenience https://docwiki.embarcadero.com/Libraries/Athens/en/System.TObject.InitInstance

I'm glad I took the time to explain how I read the VTune flame graph and that you tried and verified most of what I expected (well guessed tbh). And that you now saw first-hand why the original code was written the way it was. Welcome to the world of maintaining legacy projects😉 I'm sure you figured out how to get a copy of VTune, if not refer to the thread by Anders which I linked to in the flame graph post. It contained all I needed to get going. I read your post like you reverted your changes for now, but you might want to consider a few things which could improve the solution you tried: 1. Make sure all the loaded info is kept, i.e. when opening the dialog a second time, everything is already there. That way the user has to endure the delay only once. If that proves that memory usage is of no real concern (which I'd expect), you could go ahead and 2. Consider loading the info asynchronously, i.e. in a thread/threadpool as soon as the app starts - then, if the users opens the dialog before the loading has finished, show a progress and wait for it to finish. This should behave great when it works, but making that codebase thread safe is an enormous task, especially since there don't seem to be unit- and functional tests which help you make changes with confidence