Mike Warren

I just purchased a Mac Mini Pro 16GB/512GB. Setting it up now... Thank you all for your input.

For anyone interested: https://quality.embarcadero.com/browse/RSP-41295

I should have got that one instead. 🙂

Thank you both for replying. Any new Mac Mini bought today will be an M1/M2 variant, so an Intel version is not an option for me. My development machine is a high-end gaming laptop. i7-12700H 2.30 GHz with 32GB RAM, an RTX3070ti GPU and 5TB of SSD storage, running Windows 11. I need this laptop for work because I use some graphics-intensive software. As far as work is concerned, I only do Delphi development less than 5% of the time, but I also use Delphi at home. I need to keep my work laptop with me so have to carry it between work and home every day. That's why I was really hoping to be able to use a Mac VM rather than hardware. I run my dev environment in a Win11 VM and performance is very good. The 2 Mac Minis I'm looking at are these: Mac Mini I'd prefer the cheaper one, but am concerned about the low memory. I understand these computers can't be upgraded. I've just ordered a couple of those HDMI dummy plugs. I can see them being useful for other things I do. D11 does compile for both Intel and ARM Macs, but I can't find any information on if I need an Intel Mac to do so.

After using D1 to D7 for many years I've just started with Delphi 11.3 so I can write cross platform software. Initially, I tried a Mac VM in VirtualBox but the SDKs are not seen. From what I gather from my research, there seems to be problems using Mac VMs. I really hate the idea of carrying another computer around with me, so I'm looking at a Mac Mini as what looks like the best compromise. I can squeeze one of those in my laptop bag as long as it can be run headless. So, my questions: 1/ Will a current model low end M2 Mac Mini be suitable for Mac and iPhone development with Delphi? 2/ Can a Mac Mini be run headless and operated from a VNC connection?

It's normal to get a beep for Alt+key combinations that are not handled by the application, but it the app handles the key combination it should be swallowed by the app so Windows doesn't get it. VCL has always done this. I'll make a quality report.

Well, they shouldn't, and don't for me. VCL applications behave correctly, as they have done since D1 (yes, I've been using Delphi that long). FMX application process the keystrokes and then pass them to Windows. It should not do this. Here's a video demonstrating the issue.

Thanks for your reply. I don't want to disable the system beep globally. With a VCL based application, anything (Action, Button etc.) that has a shortcut assigned to it will prevent the key message for the shortcut being passed on to Windows so Windows will not play its default beep. The same behavior can be seen by adding a button instead of an action and setting the button's Text (Caption) property to &X. This is starting to look like a bug in FMX to me, or at least missing functionality.

Thanks for the reply Vincent. To duplicate this, do the following: 1/ Create a new blank multi-device application 2/ Add an ActionList component 3/ Add an Action the the ActionList 4/ Set the Shortcut for this action to Alt+X 5/ In the OnExcecute event of the Action, add Close; Run the program and press Alt+X. The program will close and a Windows Beep will be heard. Do exactly the same thing with a VCL program and no beep is heard. All this on D11.3 and Windows 11

I've been using Delphi since 1996, but have been fixed at D7 for many years. I've finally upgraded to D11.3 and am creating my first FMX based application, targeting Win64 and Android64. I added an ActionList and added an Action with a shortcut of Alt+X. The problem I have is that the Alt+X key press triggers a windows beep sound. This is something I do regularly in VCL based apps. As soon as an action with a shortcut is defined the Windows beep does not fire. How do I fix this in a FMX based app?

Thanks David. I had seen Bass in passing, but dismissed it as just being a playback engine. Looking at it again after your suggestion does show promise, so I'll spend some time looking at it. I'd prefer a native Delphi component, rather than a DLL, but can see that may be asking too much for cross platform.

Hello, I'm about to upgrade from D7 to D11.3, specifically so I can target MacOS, iOS and Android in addition to Windows in future applications. In one of my old applications I've been using the DCDSP components with DSPack to change the pitch of audio files without changing the speed. I want to be able to do the same thing in a new application that I want to target MacOS (Intel and Arm) as well as Windows. Does anyone have any suggestions of where I can get started with this? Google has not lead me to anything conclusive, or even promising.