Jump to content

Incus J

  • Content Count

  • Joined

  • Last visited

Community Reputation

2 Neutral

Technical Information

  • Delphi-Version
    Delphi 10.4 Sydney

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I think FMX renders its UI to a surface/canvas, rather than having the OS render the controls (?) - so yes, it could be different. This is where the IcsHttpsTst seems to get stuck at startup: Line 1962 of Ics.Posix.Messages function TMultiReadExclusiveWriteSynchronizer.BeginWrite: Boolean; var Thread: PThreadInfo; HasReadLock: Boolean; ThreadID: Cardinal; Test: Integer; OldRevisionLevel: Cardinal; begin ... ThreadID := GetCurrentThreadID; The top of the call stack looks like this : :000000010001D0F0 System::_DbgExcNotify(int, void*, System::SmallString<(unsigned char)255>*, void*, void*) :000000010001D12E System::NotifyReRaise(System::TObject*, void*) :000000010001D1CA System::_RaiseAtExcept(System::TObject*, void*) :0000000100056AB8 System::Sysutils::ErrorHandler(unsigned char, void*) :0000000100015F30 System::ErrorAt(unsigned char, void*) :000000010001B252 System::_BoundErr() Ics.Posix.Messages.TMultiReadExclusiveWriteSynchronizer.BeginWrite()(0x0000000102521120) Ics.Posix.Messages.TIcsMessagePump.AfterConstruction()(0x000000020245bd80) :0000000100016B45 System::_AfterConstruction(System::TObject*) :0000000100011443 System::TObject::TObject() Ics.Fmx.Overbyteicswndcontrol.TIcsWndControl.AllocateHWnd()(0x0000000203080ff0) Ics.Fmx.Overbyteicshttpprot.THttpCli.THttpCli(System.Classes.TComponent*)(0x0000000203080ff0,true,0x000000020801e5f0) ... Maybe that contains useful information. On Posix, the System unit defines: TThreadID = NativeUInt; But local var ThreadID is Cardinal. Maybe Cardinal and NativeUInt are not compatible. If I redefine ThreadID as a NativeUInt too, then the ERangeError disappears, and the app is "[Running]" - but the UI does not appear. I think Thread #1 might be waiting for something.
  2. I remember back in Delphi 10.2 Tokyo FMX ProcessMessages seemed to behave differently to VCL ProcessMessages. With VCL I can call ProcessMessages and any queued mouse clicks are processed. With FMX I found that a call to ProcessMessages did not process queued mouse clicks. It was as though FMX UI events were handled separately. I don't know whether this is still the case.
  3. That sounds good. I've just tested the latest overnight zip, and D104InstallVclFmx builds successfully for macOS 64-bit. The sample app IcsHttpsTst builds successfully by adding the Ics.Fmx. prefix to a few IcsHttpTst1.pas uses units. When the sample app deploys and runs on macOS 64-bit I get an ERangeError "Range check error" at runtime. I think it occurs in Ics.Posix.Messages.pas but the IDE debugger can't find that unit, so I'm not sure. I must need to tell the IDE/Debugger the path to the ICS source units so it can step into them - but I'm not sure how to do this. The Delphi compiler already knows where the source units are, because the app builds and deploys OK, but the IDE itself seems unaware at the moment.
  4. I encountered this small issue with Project Options too. I don't know the cause, but I worked around it by switching the Platform Target to Win32 temporarily, before opening the Project Options dialog. Then afterwards switched the Target Platform back to macOS 64-bit after closing the Options dialog. There is a CFBundleVersion field in the options 'Version Info' section, which looks to be set to a value of 1.0.0 (that sounds a reasonable value). I am really encouraged that the IcsCommonD104Run package now builds successfully, and the FMX IcsHttpsTst sample application also builds successfully. Getting these two to build successfully feels like a significant step forward - thank you.
  5. Good news: If I edit the list of units in IcsHttpsTst1.pas as follows, the application builds successfully for macOS 64-bit 🙂 Ics.Fmx.OverbyteIcsWndControl, Ics.Fmx.OverbyteIcsWSocket, OverbyteIcsLIBEAY, OverbyteIcsSsLeay, Ics.Fmx.OverbyteIcsSslSessionCache, OverbyteIcsLogger, OverbyteIcsIniFiles, OverbyteIcsUtils, {$IFDEF USE_MODEZ} { V2.102 } OverbyteIcsHttpCCodZLib, {$ENDIF} OverbyteIcsHttpProt, OverbyteIcsCookies, FMX.Memo.Types, FMX.Controls.Presentation, FMX.ScrollBox; Basically I just added a few Ics.Fmx prefixes, which seems to avoid Vcl conflicts. Building IcsHttpsTst.dproj (Debug, OSX64) [dccosx64 Warning] OverbyteIcsUtils.pas(1309): W1073 Combining signed type and unsigned 64-bit type - treated as an unsigned type [dccosx64 Hint] OverbyteIcsWSocket.pas(10705): H2164 Variable 'phe' is declared but never used in 'LocalIPList' [dccosx64 Hint] OverbyteIcsWSocket.pas(24464): H2077 Value assigned to 'TIcsEventQueue.HandleEvents' never used [dccosx64 Hint] OverbyteIcsWSocket.pas(24491): H2077 Value assigned to 'TIcsEventQueue.HandleEvents' never used [dccosx64 Warning] OverbyteIcsWSocket.pas(24703): W1057 Implicit string cast from 'AnsiString' to 'string' [dccosx64 Hint] OverbyteIcsCookies.pas(669): H2443 Inline function 'DeleteFile' has not been expanded because unit 'Posix.Unistd' is not specified in USES list [dccosx64 Hint] H2596 ld: warning: directory not found for option '-LC:\Users\(User)\Documents\Embarcadero\Studio\21.0\Imports' Success Elapsed time: 00:00:10.0
  6. Moving on to the FMX IcsHttpsTst sample application. [dccosx64 Fatal Error] OverbyteIcsWndControl.pas(154): F2613 Unit 'Vcl.Forms' not found. {$IFNDEF NOFORMS} {$IFDEF FMX} FMX.Forms, {$ELSE} {$IFDEF RTL_NAMESPACES}Vcl.Forms{$ELSE}Forms{$ENDIF}, {$ENDIF} {$ENDIF} Although this is an FMX project, it is pulling in Vcl units. The magic {$DEFINE FMX} is bypassed, maybe because the main form currently references OverbyteIcs--- internal units directly, like this (IcsHttpsTst1.pas, line 95): OverbyteIcsWndControl, OverbyteIcsWSocket, OverbyteIcsLIBEAY, OverbyteIcsSsLeay, OverbyteIcsSslSessionCache, OverbyteIcsLogger, OverbyteIcsIniFiles, OverbyteIcsUtils, {$IFDEF USE_MODEZ} { V2.102 } OverbyteIcsHttpCCodZLib, {$ENDIF} OverbyteIcsHttpProt, OverbyteIcsCookies, FMX.Memo.Types, Perhaps this list of units should be prefixed for FMX? e.g. Ics.Fmx.OverbyteIcsWndControl Would that allow {$DEFINE FMX} to be parsed, so Vcl units are not included? This is speculation, as I don't have in depth knowledge of the project. [dccosx64 Error] IcsHttpsTst1.pas(884): E2010 Incompatible types: 'OverbyteIcsWSocket.TX509List' and 'Ics.Fmx.OverbyteIcsWSocket.TX509List' { Property SslCertChain contains all certificates in current verify chain } CertChain := HttpCli.CtrlSocket.SslCertChain;
  7. Yes, I can confirm the macOS fixes are present. Just a couple of minor tweaks before moving forward: Line 89 of IcsCommonD104Run project file, I've included the ticks64 unit for Windows only: {$IFDEF MSWINDOWS} OverbyteIcsTicks64 in '..\Source\OverbyteIcsTicks64.pas', {$ENDIF} [dccosx64 Error] Ics.Posix.Messages.pas(73): E2004 Identifier redeclared: 'System.SyncObjs' System.SyncObjs, { V8.65 } No problem - I just comment out the second declaration. [dccosx64 Error] Ics.Posix.Messages.pas(1965): E2003 Undeclared identifier: 'InterlockedDecrement' InterlockedDecrement(FSentinel); Solved by changing to TInterlocked.Decrement(FSentinel). With those in place the package builds successfully.
  8. Thanks Angus - I've downloaded the overnight zip and will give it a try. I have Linux Mint in a VM, but only the Pro version of Delphi 10.4 which (I think) lacks the Linux target.
  9. Next up is: [dccosx64 Error] OverbyteIcsHttpProt.pas(847): E2003 Undeclared identifier: 'TNtlmAuthSession' {$IFDEF UseNTLMAuthentication} FAuthNtlmSession : TNtlmAuthSession; // V8.61 OAS TNtlmAuthSession is defined in unit OverbyteIcsNtlmSsp - but it is wrapped in {$IFDEF MSWINDOWS} and a quick Google search suggests NT LAN Manager authentication, perhaps intended for Windows only (?). Though it is in THttpCli rather than a server component.
  10. I'm not sure either - maybe the sample app references the OverbyteIcsWndControl unit directly somehow (instead of via Ics.Fmx.OverbyteIcsWndControl) - skipping the magic {$DEFINE FMX}. OK I've got a little further: [dccosx64 Error] OverbyteIcsWSocket.pas(21878): E2033 Types of actual and formal var parameters must be identical Count := f_BIO_read_ex(FSslbio, @Dummy, 0, ReadBytes); { V8.51 new in 1.1.1 } ReadBytes is a var parameter, of type size_t on line 21668. ReadBytes : size_t; { V8.51 } OverbyteIcsTypes size_t is likely a UInt64: { V8.65 MacOS64 seems to be missing size_t } {$IFDEF POSIX} {$IFDEF CPUX64} size_t = UInt64; {$ELSE} size_t = LongWord; {$ENDIF} Psize_t = ^size_t; {$ENDIF POSIX} However OverbyteIcsLibEAY f_BIO_read_ex references size_t in Posix.SysTypes: size_t = Posix.StdDef.size_t; …which is LongWord not UInt64. To progress I’ve changed CPUX64 size_t to LongWord in OverbyteIcsTypes.
  11. Thanks Lars and Angus. That makes sense. So if I've understood, defining 'FMX' manually in the Project Options Conditional Defines is likely a reasonable way to go here (for IcsHttpsTst). (Side note: Interesting that OverbyteIcsWndControl.pas compiled OK for FMX Win32, presumably even without 'FMX' defined. Maybe it pulled in Vcl.Forms too but being a Windows platform was able to continue compiling without FMX.Forms in this particular case:) {$IFNDEF NOFORMS} {$IFDEF FMX} FMX.Forms, {$ELSE} {$IFDEF RTL_NAMESPACES}Vcl.Forms{$ELSE}Forms{$ENDIF}, {$ENDIF} {$ENDIF}
  12. Thanks Angus - I can also confirm IcsHttpsTst builds successfully here for Win32. Since I know that the project IcsHttpsTst really is FMX, I have defined 'FMX' manually in the Project Options > Delphi Compiler > Conditional defines. A workaround just so {$IFDEF FMX} code compiles - to progress a bit further on macOS 64-bit.
  13. Thanks Lars - I've tried this approach but haven't got it to work as yet. FireMonkeyVersion does not seem to be defined at present - perhaps it is defined in a unit that is not currently used in the project? {$IFNDEF NOFORMS} {$IF DECLARED(FireMonkeyVersion) and (FireMonkeyVersion >= 16.0)} FMX.Forms, {$ELSE} {$IFDEF RTL_NAMESPACES}Vcl.Forms{$ELSE}Forms{$ENDIF}, {$ENDIF} {$ENDIF} When I build the project in Delphi 10.4, the compiler ends up at Vcl.Forms which seems a bit odd: [dccosx64 Fatal Error] OverbyteIcsWndControl.pas(153): F2613 Unit 'Vcl.Forms' not found. I've found the following in the FMX.Types unit: {$HPPEMIT '#define FireMonkeyVersion 270'} FireMonkeyVersion = 270; {$EXTERNALSYM FireMonkeyVersion} FMX.Types is present in the uses clause of both the project .dpr file, and the main form .pas file. I must be doing something wrong here.
  14. Thank you, that helped! There were also a couple of InterlockedExchangeDecrement calls that I’ve swapped for TInterlocked.Decrement System.SyncObjs is already declared in the main uses clause, so I didn’t have to add that one. I’ve also changed line 56 of Ics.Posix.Messages from IFNDEF to IFDEF: {$IFDEF MSWINDOWS } {$MESSAGE Fatal 'This unit should not be included in a Windows project. Make sure you use Winapi.Messages instead'} {$ENDIF} [dccosx64 Fatal Error] OverbyteIcsWndControl.pas(153): F2613 Unit 'Vcl.Forms' not found. {$IFNDEF NOFORMS} {$IFDEF FMX} FMX.Forms, {$ELSE} {$IFDEF RTL_NAMESPACES}Vcl.Forms{$ELSE}Forms{$ENDIF}, {$ENDIF} {$ENDIF} I’m a little unsure here. IcsHttpsTst1 appears to be an FMX project. But the compiler is trying to add Vcl.Forms, so I suspect ‘FMX’ is not a predefined conditional, at least I haven’t spotted it here: http://docwiki.embarcadero.com/RADStudio/Sydney/en/Conditional_compilation_(Delphi)#Predefined_Constants Does Delphi have a mechanism to conditionally compile VCL vs FMX? I guess it must have one, but I haven’t found it yet.
  15. Thanks Angus. macOS went 64-bit in 2005, but still continued to support 32-bit software until recently. I guess since Macs from the last 15 years support 64-bit, introduction of the macOS 64-bit compiler makes the OSX32 compiler redundant. I've had a try building one of the ICS FMX samples relating to HTTP. At the moment I'm seeing a couple of compiler errors in Ics.Posix.Messages relating to a missing InterlockedExchange function - will post if I can't resolve.