Remy Lebeau

Why? For an import lib, you should instead simply create a new import lib file for C++Builder using the IMPLIB (32bit) or MKEXP (64bit) tool on the DLL itself. There is no point in converting import libs, only static libs.

Yes, they do, but those child processes are specifically designed to interoperate and sync with their host process. That is not the case when you simply host someone else's UI inside of your own. That is when bad things can happen, because the child process doesn't know it's being hosted and so the parent and child don't sync their states together.

There is no GetProcessWindow() function in the Win32 API, since windows are not tied to processes, only to threads. So I'm assuming that function is implemented in your own code, yes? Probably a combination of EnumWindows() and GetWindowThreadProcessId(), though using EnumThreadWindows() with the pi.dwThreadID instead might make more sense. That can be very dangerous if you are not careful. Is it legal to have a cross-process parent/child or owner/owned window relationship?

The '%f' specifier in ...printf() style functions expects 'double' (or 'long double' if you use '%Lf'), not 'float'. There is no specifier that accepts 'float'. So, you will have to cast the values when passing them in, eg: snprintf(buffer, sizeof(buffer), "%f", (double) *zMap); // or: double(*zMap), or static_cast<double>(*zMap) Alternatively, you can format the 'float' to a C++ 'std::string' first, and then copy it into your buffer, eg: std::ostringstream oss; oss << *zMap; strncpy(buffer, oss.str().c_str(), sizeof(buffer)-1); Or: strncpy(buffer, std::format("{}", *zMap).c_str(), sizeof(buffer)-1); Of course, being a Delphi guy, you could just use the Delphi RTL in C++Builder to convert the 'float' to a 'System::String' first, and then copy it into your buffer, eg: strncpy(buffer, AnsiString(FloatToStr(*zMap)).c_str(), sizeof(buffer)-1); // or simpler: strncpy(buffer, AnsiString(*zMap).c_str(), sizeof(buffer)-1); Or, simply get rid of the buffer altogether and use the 'std::string'/'System::(Ansi)String' as-is instead. That being said, your two examples are logically equivalent, so if the above approaches don't fix the issue, then make sure the pointer being returned by SomeFunctionThatReturnsABuffer() is actually valid to begin with (ie, that the memory buffer is not being freed before you copy the data, etc).

I question the design of the code shown. I would have opted to implement it more like this instead: procedure AnalyzeException(const E: Exception); begin // ...Do something with the object ... end; procedure TestCase (ReRaiseException {or: SwallowException}: Boolean); var OneThousand, Zero: integer; d: double; begin Zero := 0; OneThousand := 1000; try d := OneThousand / Zero; except on E: Exception do begin AnalyzeException(E); if ReRaiseException {or: not SwallowException} then raise; end; end; end;

Unfortunately, you will not be able to do that with FMX's native interfaces, at least on Windows (I didn't look at other platforms). You will have to resort to using the Win32 API directly. On Windows, FMX's default IFMXClipboardService implementation natively supports only the CF_UNICODETEXT and CF_DIB standard clipboard formats. For other clipboard formats, FMX does offer IFMXExtendedClipboardService. However, it only supports clipboard formats that are registered at runtime via its RegisterCustomFormat() method, which on Windows is based on the Win32 RegisterClipboardFormat() API. But files are stored on the Windows clipboard using pre-defined Shell clipboard formats that are not registered at runtime (ie, CF_HDROP, CF_FILENAME, CFSTR_FILEDESCRIPTOR+CFSTR_FILECONTENTS, CFSTR_SHELLIDLIST, etc), so they cannot be accessed with IFMXExtendedClipboardService at this time. I have just now opened a QualityPortal ticket to request that feature be added in a future Delphi release: RSP-41923: Allow IFMXExtendedClipboardService to access custom formats by ID, not just by name For Windows, definitely yes. For other platforms, it depends on how their system clipboards store files, and how FMX implements support for them, but I suspect the answer will be yes for them as well.

@bravesofts This was already covered on your StackOverflow question yesterday: delphi Thread ITask.ExecuteWork not wait until Task finish in mobile devices? Guess you didn't like what you were told there? So you came here instead, just to be told the same things. Funny how the same knowledge can span across multiple forums, huh? 😉

Can you please show the code in SolidBridge.h, as well as the Delphi code it is based on? What do you mean, exactly? VCL's TApplication::MessageBox() method simply calls the Win32 API MessageBox() function, using either TApplication::ActiveFormHandle or TApplication::Handle as the owner window for the dialog. So, it does not use any VCL font resources.

Putting the program name in argv[0] is only a convention, not a guarantee. It depends on how the caller passes parameters when spawning the process. And it is possible to spawn a process without the program name as the first parameter. You can instead use ParamStr(0) (or Application->ExeName in VCL) to get the program name.

No. AProp2 is just a TRttiProperty, you can't cast it to anything that is related to the actual object. You can't specify Generic parameters at runtime, only at compile-time. So you will have to change GetById() into a normal function that takes a TClass input parameter, eg: function TEntityManager.GetById(ClassType: TClass; AID: Int64, ALock: Boolean = False): TObject; ... AProp.SetValue(LObj, Self.GetById(LObj.ClassType, LRelationID, ALock));

I think only {$WARN} has that option, but most other directives do not.

You are not actually reading the TPerson.Address property value to access the TAddress object. AProp.PropertyType.AsInstance is not the way to do that, use AProp.GetValue() instead and cast the result to an object pointer, eg: var ... LObj: TObject; ... for AProp in ARelations do begin LObj := AProp.GetValue(SomeModel).AsObject; LClass := LObj.ClassType; for AProp2 in AProp.PropertyType.GetProperties do begin if (AProp2.Visibility in [mvPublished, mvPublic]) then begin for LAttr in AProp2.GetAttributes do begin if (LAttr is ColumnAttribute) then begin if (AProp2.PropertyType.TypeKind in [tkString, tkUString, tkWString]) then AProp2.SetValue(LObj, 'Orange'); Break; end; end; end; end; end; ...

Yes, simply use TStringList.CustomSort() to sort the strings however you want, eg: function MySortFunc(List: TStringList; Index1, Index2: Integer): Integer; begin Result := StrToInt(Copy(List[Index2], 4, MaxInt)) - StrToInt(Copy(List[Index1], 4, MaxInt)); end; ... var SL: TStringList; SL := TStringList.Create; ... SL.Add('ABC10'); SL.Add('ABC1'); SL.Add('ABC2'); SL.Add('ABC21'); SL.CustomSort(@MySortFunc); ... SL.Free;

I don't have SvCom's source code to look at, but offhand I would appear that SvSetservicestatus() is acting as some kind of proxy and is using ASM to preserve the original call stack when jumping into other functions, rather than pushing its own data onto the call stack using normal function calls.

In C++, yes (via __LINE__), and even in FreePascal, yes (via {$INCLUDE %LINE%}), but not in Delphi, no.

That error is raised by Indy's TIdMimeTable class when a file extension is being added that has already been added. But looking at Indy's default logic, although I do see several duplicates being added, the dupes are explicitly ignored when invoked by Indy itself. It is only when user code adds an extension that such error can be raised. And even so, TIdMimeTable is typically used only on-demand at runtime. never at design-time or at program startup.

It's a shame that Delphi does not have {$PUSH}/{$POP} directives like FreePascal has, that would clean up that code a bit, eg: {$PUSH}{$R-} TempInt := TempInt * 11; {$POP} This has already been requested in Delphi for many many years, but nothing ever came of it: QC #56908: Save and restore compiler directives with push/pop RSP-14045: {$BEGINOPT R+,Q-} ... {$ENDOPT} RSP-38847: Implement stack-like push/pop for compiler directives to preserve/restore state

FYI, you don't have to resort to that pointer hack if you enable the Writable Typed Constants compiler option.

I have a recruiter messaging me on LinkedIn offering a position for a Sr Software Engineer with Embarcadero RAD Studio experience: Anyone interested?

Probably 😒 Oh well...

Agreed. I've written many services, but I have written only 1 service that ever needed to run in dual GUI/service modes, and even then I eventually broke out the GUI into a separate project that communicates with the service. All the more reason to break out the GUI into its own project, to reduce the complexity of the service project. Not really. The IDE debugger can be attached to a service process. If I ever need to debug a service's startup code, I simply define a command-line parameter that I can issue in the SCM, and then I have the TService.OnStart event handler look for that parameter to invoke a pause until I attach the debugger to the process. Then I can debug the remaining startup code normally.

The recruiter hasn't replied yet with details...

Use HOW, exactly? Please be more specific and clarify the issue. Are you asking how to REPLACE Indy's TIdHTTPServer component with CSI's SimpleHttpServer component? If so, then obviously you can't use a TIdHTTPServer.OnCommandGet event handler as-is, you would have to re-write the handler code to meet CSI's requirements.

OK, I asked the recruiter for details and am waiting for a reply...

It is a pull request in Indy's GitHup repo, it has not been merged into Indy's main code yet: https://github.com/IndySockets/Indy/pull/299 Also see this recent discussion: https://github.com/mezen/Indy/issues/12