msohn

From my experience, DevExpress requires an all or nothing approach. If you use their controls exclusively (or build something on top of them), I'm pretty confident you could achieve what you want, as their skins are very customisable. And usage just got a lot less complicated with the recently added global application settings.

Are you kidding me? You, Sir, are a TeamB legend and as such I would have assumed you're an MVP now, with - AFAIK - much earlier access to the betas. Heck, I learned a ton from all of your posts going all the way back to when we were still hanging out on nntp://borland.* with the likes of Neil J. Rubenking and the other TeamB members (or maybe even earlier back, then CompuServe was a thing, but I'm not sure whether my memory serves me right on this one). I sincerely hope you're able to enjoy your time as a pensioner now. You've been an inspiration to me in more than just one way. So thank you a lot. FWIW I didn't receive a beta invite as a regular subscription user, but I'm actually not surprised by that - I mean how is Calvin Tang going to handle beta invitation requests if everyone with an active subscription is invited?

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.