Leaderboard

Maybe if they just built the web servers with Delphi and use the Delphi philosophy, they'd work

For me it's the lack of communication. Errors happen, but at a certain stage they should start to communicate about the error and give some advice about expected timeframe for fixing the problem, possible workarounds and so on. I really don't care (that much) how long this takes - but it would be nice to get some regular updates about the progress made. We are now in a situation where we have to review our development environment and make it as independent as possible from the availability of Embarcadero servers. In result we have to stop using GetIt, and other services may follow.

Or is that the root cause?

The event is signaled when TerminatedSet() is called. TerminatedSet() is called by the Terminated property setter. If the thread is still running when the TThread object is being destroyed, the inherited destructor will set the Terminated property and wait for the thread to finish running.

Since these interfaces are not identical they should have different GUIDs. If only one of them (IBindCompFactoryExecuteContext) is ever instantiated, only this one should have a GUID. So yes, that's a bug. Probably caused by copy and paste, as most of these errors.

Hello everyone, What disappoints me is that the individuals responsible for creating and maintaining these services are not juniors. They are experienced professionals who often give lectures on developing excellent software. I've mentioned this before: the Embarcadero team needs to take some time specifically to address these issues. It's tiresome to witness so many flaws coming from professionals who should set an example. As a friend pointed out, mistakes happen, that's normal, but not with such frequency. It's truly disheartening.

Dear Professor, thank you for support! Step 1. Make sure that Python is installed on the system and find the name of the .so On my system Ubuntu22.04 it is libpython3.10.so.1 and libpython3.10.so.1.0 Step 2 The make sure property UseLastKnownVersion = False. It was trying to use libpython3.3m.so instead. Now it all works well!! Thank you for your support!

They should also ask the oracle.

The problem is not the monitoring. The problem is that very often it becomes a problem with these services. Is it the fault of the sysadmin or the programmer, but this service drop needs to stop

How some other company monitors their package manager.

I agree. It leaves a really bad impression - especially when it happens over and over.

See

https://blogs.embarcadero.com/we-are-experiencing-a-hardware-outage/

The problem is not so much the bug/fault on the site (it happens to everyone) but the time taken to resolve it. Not serious.

RTTI does have nothing to do with it but TObject.GetInterfaceEntry - try the following code: type IFoo = interface ['{5DEC09C5-FADC-46A5-814F-9ED91259A37F}'] function GetFooName: string; end; IBar = interface ['{5DEC09C5-FADC-46A5-814F-9ED91259A37F}'] function GetBarName: string; end; TFooBar = class(TInterfacedObject, IFoo, IBar) function GetFooName: string; function GetBarName: string; end; function TFooBar.GetFooName: string; begin Result := 'Foo'; end; function TFooBar.GetBarName: string; begin Result := 'Bar'; end; var i: IInterface; begin i := TFooBar.Create; Writeln((i as IFoo).GetFooName); Writeln((i as IBar).GetBarName); end. The interesting thing with those two interfaces in the RTL is that coincidentally they will not cause any harm because of how they are implemented and related to each other - the one inherits from the other and they are also implemented by classes that inherit from each other.

FYI cross posted here (unicode - Delphi - Data is not encoded in given format - Stack Overflow) and with no code there either. As a rule, I think cross-posting is fine on this site, but you should always note that you've done so to avoid people spending time giving you help when you already received it elsewhere. It's just a good courtesy to the people that you are asking for help. But in any case, you should improve the post (in both places) by giving details of your code so that we have something concrete.

I didn't know what I was missing, thanks, @Lars Fosdal.

I am sure I remember something like this, back in Delphi 10.0 or even XE7. The compiler will only check the attributes if the source code file (the binary .dcu it ends up in) gets rebuilt. So if you just change something about the attributes but nothing else, it will not trigger a warning. If you do a full rebuild, it will always trigger the correct warning. I think I never bothered to file a bug report.

Ahhh, now I get it. Thanks!! Much better now!

You can get rid of the coloring book background in Tools | Options | IDE | Welcome Page, press Clear

Which will happen during the cleanup in TThread destructor because of fEven.SetEvent which is called in TerminatedSet. Please read everything I posted before. If you don't trust me, then run the code yourself. We are running in circles now.

Self destructing threads, while useful, have their own issues. They cannot be terminated directly, waited for, or properly cleaned up during the application shutdown and can cause various issues and exceptions during the shutdown. Basically, you lose proper application cleanup. Actually, you can do proper cleanup with such threads, too, but only if you add plenty of code that will also have to fiddle around with Windows API, and when doing all that, you are effectively rewriting infrastructure that is already in place inside TThread class. And then you are back to the square one, where you need to handle thread cleanup in proper order, basically achieving nothing comparing to using thread class that you need to manually Free - which again will work properly, if you pay little attention.

So, if you intentionally refer to a non-existing custom attribute - you get no warning? This compiler warning setting exists in my D12 project - and it appears to be True by default.

Finally found the solution. Apparently, I need to close the handle to the thread and process of the executable run in the new desktop in order to properly terminate the new desktop. So I added CloseHandle(pinfo.hProcess); CloseHandle(pinfo.hThread); After WaitForSingleObject, before switching to original desktop. Case closed 🙂

Great example ! and i want to expand on this a little System.SysUtils; type IFoo = interface ['{5DEC09C5-FADC-46A5-814F-9ED91259A37F}'] function GetFooName: string; end; IBar = interface ['{5DEC09C5-FADC-46A5-814F-9ED91259A37F}'] procedure Dummy; function GetBarName: string; end; TFooBar = class(TInterfacedObject, IFoo, IBar) function GetFooName: string; function GetBarName: string; procedure Dummy; end; function TFooBar.GetFooName: string; begin Result := 'Foo'; end; procedure TFooBar.Dummy; begin Writeln('Dummy called !'); // this is procedure without result ! // yet it might don't raise an exception here because the result in a register could be 0 or valid value end; function TFooBar.GetBarName: string; begin Result := 'Bar'; end; var i: IInterface; begin i := TFooBar.Create; Writeln((i as IFoo).GetFooName); Writeln((i as IBar).GetBarName); Readln; end. The result Dummy called ! Bar