Leaderboard

In contrast to software a roadmap is always released when its ready.

A conflict with tMonitor declared in Vcl.Forms.pas?

@Dave Nottage Hi Dave, thanks for your nice article about a major problem in the Apple environment. Yes, Apple always keeps us busy with such unnecessary work. Since I had fallen into such nasty boobie trap in some older version before, I changed my way howto deal with these updates. So I may provide another (pseudo)-solution to this topic: Solution 3: ( prerequisites before starting any update ) Use your XCode environment for development in a VM virtual machine, like VmWare Fusion Make a backup of your VM image, BEFORE any update of the VM (if you prefer snapshots, thats fine too, if you cleanup later, but I prefer to make complete, FULL clones of the whole VM) In the VM backup also the current SDK's are backed up of course, if you ever need them again later With these FULL clones you can switch fast and easy between older and newer XCode, SDK and PAServer setups That doesn't solve the basic problem, of course, but makes it much easier to handle different SDK environments, in case of any "crash" might happen wit the new version.

I don't have a problem with it - the DotNet api is really quite nice, broad functionality, well tested, well documented. Nothing wrong with using it for inspiration. What I wish more than anything is that Embarcadero stops releasing unfinished untested features. 10.4 is up there amongst the worst Delphi releases ever and pretty much unusable for me. LSP is half baked, the IDE is a mess, the debugger barely works and it;s a sloth. The VCL is ruined by poor implementation of themes - flicker everywhere.

I guess, it is more likely taken from .NET: system.threading.monitor

Two things can happen 1. The constructor succeeds and returns a valid object reference. 2. An exception is raised, propagates out of the constructor, and the assignment never happens.

The try finally here isn't protecting the execution of the constructor. It protects against exceptions in the code that runs after the constructor completes, after the try. Look at the code in your post. The try finally is not active when the constructor runs. If an exception is raised in the constructor then the try is never reached. So, yes, you do need the try finally.

Yeah. They should really rename either System.TMonitor or Vcl.Forms.TMonitor to avoid that conflict. Frankly, I never understood why the System one was named TMonitor to begin with. Since it is inherently tied to TObject, maybe something more like TObjectLock, TObjectSync, TObjectMonitor, etc would have made more sense. Of course, on the flip side, for the Vcl.Forms one, maybe something more like TDisplayMonitor, TScreenMonitor, etc would have made more sense. Oh well, too late now, I guess.

If anyone is interested, here's the relevant section of the manifest file after I tested it works correctly: <activity android:name="com.embarcadero.firemonkey.FMXNativeActivity" android:label="ZP Remote" android:configChanges="orientation|keyboard|keyboardHidden|screenSize" android:launchMode="singleTask"> <!-- Tell NativeActivity the name of our .so --> <meta-data android:name="android.app.lib_name" android:value="ZP_Remote" /> <intent-filter> <action android:name="android.intent.action.MAIN" /> <category android:name="android.intent.category.LAUNCHER" /> </intent-filter> <intent-filter android:label="Play in ZP"> <action android:name="android.intent.action.SEND" /> <category android:name="android.intent.category.DEFAULT" /> <data android:mimeType="text/plain" /> </intent-filter> </activity> <activity-alias android:targetActivity="com.embarcadero.firemonkey.FMXNativeActivity" android:name="com.embarcadero.firemonkey.FMXNativeActivity.Queue"> <!-- Put second SEND action inside activity-alias tag --> <intent-filter android:label="Queue in ZP"> <action android:name="android.intent.action.SEND" /> <category android:name="android.intent.category.DEFAULT" /> <data android:mimeType="text/plain" /> </intent-filter> </activity-alias>

No need to report the right mouse button bug, it exists already. RSP-28235 But I think I have the solution: procedure TListBoxSelector.MouseSelectFinish(const Item: TListBoxItem; const Button: TMouseButton; const Shift: TShiftState); begin if Button <> TMouseButton.mbLeft then begin DoMouseSelectStart(Item, Shift); end; DoMouseSelectFinish(Item, Shift); end;

Calling apps from server is OK. This is how CGI works.

If one didn't know any better one might get the impression that DLLs and COM are inherently insecure, unstable and "dangerous". Yet all of Windows and every single application running on it are based on these technologies... Anyway. One alternative I forgot to mention is to implement custom functionality using a scripting system. I've successfully applied this approach in one of the applications I've worked on to replace a DLL-based plugin system.

As a former colleague was fond of saying, the nice thing about standards is that we have so many from which to choose.

The general hints in the readme are very valuable (and made me revisit some of my ifdef checks) - apart from that it reminds me a bit of https://xkcd.com/927/ Yes, jedi.inc is long and unwieldy at times but it got everything commonly needed - in case it does not - wouldn't it be wiser to add that instead of rolling a new thing? Apart from that the prefix CAPS is kinda misleading imo - why not go with the HAS_ or SUPPORTS_ prefixes? Oh a note on your comment for bitness checking - the example does not entirely match what you describe, it specifically checks for x64 - so x86 and arm would go in the else. Bitness checks would be CPU32BITS and CPU64BITS or whats also common to check SizeOf(Pointer) = 4 for 32bit. Historically the checks are rather for x86 specifically to implement something using asm and then pure pascal in else.

@RDP1974, @Turan Can To get a beatiful shadow, use the DWM API. Shadow in borderless form in VCL: unit Unit3; interface uses Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants, System.Classes, Vcl.Graphics, Vcl.Controls, Vcl.Forms, Vcl.Dialogs; type TForm3 = class(TForm) private { Private declarations } function SetBordelessShadow: Boolean; protected procedure CreateParams(var AParams: TCreateParams); override; procedure CreateWindowHandle(const AParams: TCreateParams); override; procedure WndProc(var AMessage: TMessage); override; public { Public declarations } end; var Form3: TForm3; implementation uses Winapi.DwmApi, Winapi.UxTheme; {$R *.dfm} { TForm3 } procedure TForm3.CreateParams(var AParams: TCreateParams); begin inherited CreateParams(AParams); if TOSVersion.Major < 6 then begin AParams.Style := WS_POPUP; AParams.WindowClass.Style := AParams.WindowClass.Style or CS_DROPSHADOW; end; end; procedure TForm3.CreateWindowHandle(const AParams: TCreateParams); begin inherited; if TOSVersion.Major >= 6 then SetBordelessShadow; end; function TForm3.SetBordelessShadow: Boolean; var LMargins: TMargins; LPolicy: Integer; begin if TOSVersion.Major < 6 then Exit(False); LPolicy := DWMNCRP_ENABLED; Result := Succeeded(DwmSetWindowAttribute(Handle, DWMWA_NCRENDERING_POLICY, @LPolicy, SizeOf(Integer))) and DwmCompositionEnabled; if Result then begin LMargins.cxLeftWidth := 1; LMargins.cxRightWidth := 1; LMargins.cyTopHeight := 1; LMargins.cyBottomHeight := 1; Result := Succeeded(DwmExtendFrameIntoClientArea(Handle, LMargins)); end; end; procedure TForm3.WndProc(var AMessage: TMessage); begin case AMessage.Msg of WM_DWMCOMPOSITIONCHANGED, WM_DWMNCRENDERINGCHANGED: if SetBordelessShadow then begin AMessage.Result := 0; Exit; end; else end; inherited; end; end. Note: You can do the same in FMX! See the difference in the images attached: