DelphiUdIT

You can share the form and the code a design time between the applications. But at runtime they are all isolated. You can exchange data between them via the methods mentioned in the previous posts, but also with a database where every application put their results ... you are able to process all these informations like you want. Bye

If components such as DBEdit, DBGrid or similar (dataware components) are present in the Form and these are active at RunTime, it may be that the delay is linked to the connection timeout with the DB engine.

I never use them, but may be some are "Konopka Controls" (aka Raize Components). You can download them from My.Embarcadero (or from getit when it will be available). Bye

I read that sometimes delete the .DST file (for example "Default layout.dst") will help (make a copy before .....) When the IDE start the file will be recreated again. I use this layout:

Sometimes, but years ago, I had the same problem. The executable is not show in the Task Manager or in Process Explorer, but it was running ... or better is locked in the shutdown state wait for something. Sometimes you can delete it from disk, but pressing F5 will see it reappear. Other times, as you reported, you can't erase it. At that time, not being able to understand what was happening, I inserted an "exitprocess" in the "destroy" event of the main Form and that solved the problem. Then subsequently starting to remove the "exitprocess" I no longer had any problems. But I can't tell you if it depended on the Delphi version or the operating system. However, if I remember correctly from "Process Explorer" you can do a search with the name of the executable and it should find it for you (use "Find Handle and DLL" from the menu). Bye

For me is working now, but like you told their services are not stable.

For me all the sites are working, except getit ... I don't think is a good idea to insert your credentials here, until they are official announced like partners of Idera.

You can read this: https://en.delphipraxis.net/topic/8569-indy-with-openssl-111-support-is-fine/?do=findComment&comment=72163 EDIT: The "299" repository was archived and it will not be upgraded anymore. This means that all updates from the official Indy repository will not be applied. Trying the route you indicated could be a good solution to temporarily implement compatibility between the official Indy distribution and OpenSSL 1.1.1. Let us know what's next. Further note: on the Indy github page if you go to the TAGS there is the official distribution supplied with Delphi 12 with all the packages too... the 290 package is still missing.... However, I think that it can easily be derived from the 280, not It seems to me that the components at design time have changed between Delphi 11 and Delphi 12.

Look at this: https://github.com/IndySockets/Indy/wiki Read <Updating Indy> on the right side. I do it more than one year ago and Indy is working also with OpenSSL 3.1.4 (for lot of functions, not for all). I did it with Delphi 11.x and 'cause actually problems with Embarcadero I have not tried with Delphi 12. Take care that this is not a good moment, is better to wait that Embarcadero restore all services. Bye

I cannot help more than this, it's a lot of times that I don't work with Windows Server.

In Server version WOW64 is disable lot of times. You must use "dism" tools to enable it. I have no refer to Microsoft doc, but you can try these if you know what you are doing: dism /online /get-features /format:table You should see a long textual table with the features active in your server, the WOW64 features should be like this if disabled: ServerCore-WOW64 : Disabled If you want enable it, do this: dism /online /enable-feature /featurename:ServerCore-WOW64 Hope to help you

TRectF is declared in "System.Types"

Look at the bottom, the end of the list of files in the folder .... DXEInstall is the last ...

May be you can use the Mutex (refer to https://learn.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-createmutexw ) : Uses WinApi.Windows; var hMutex: THandle //Create a global mutex (valid for all system) hMutex:=CreateMutex(Nil,False,'Global\DBiAdminSemaphore'); //If the Mutex is already owned then exit (this means that another application take it) if (WaitForSingleObject(hMutex,0) = wait_TimeOut) then exitprocess(255); //The Mutex will close automatically when the program close Bye

I don't have any source that I can report, only chats and some information from unofficial sources. But the optional WOW64 in Windows Server configuration is surely a start. Of course, like @Brian Evans said this path is not clear.

You are right. Windows 7, as was the case with Windows 98 SE, have made their way into the industrial world (and also services) and precisely for this situation they have not been completely abandoned. The new Delphi 12 environment, as already mentioned, can still compile executables that run under Windows 7, but that doesn't mean we have to stop there. The IDE policy on all current and past systems is typical of Lazarus/FPC. But it still has its limitations, which may be fine for one group of users, but certainly not for others (and I am among the latter). As the latest rumor, more or less accredited, it seems that (* NOTE) Microsoft will abandon WOW64 technology (emulation for 32-bit applications). The transition will be gradual but inexorable. It has already started with Servers, where WOW64 is optional. (*NOTE): This is a personal evaluation and has nothing to do with Microsoft's statements.

"anything i like " ... for those who work it is not enough, it should be "anything I must do" and I would like to challenge you to develop a 64 bit application with Delphi 7 or perhaps an app for Linux or Android. And let's forget about all the concepts of security or anything else. It's true that frills are often not needed, but you just need to set up your environment to make you work at ease. However, everyone is free to work as they wish, and fortunately developments continue regardless of certain opinions. I don't think the fact that the new IDE doesn't run under Windows 7 or Windows 95 where Delphi 7 runs is such a serious problem. Any professional working with tools to bring home pay needs the right tools, and many times these tools need to be updated (and after 22 years of Delphi 7 and 15 years of Windows 7 ..... may be it's the right time).

I think what you said is simply a meaningless criticism of Delphi. The fact that there are themes in the IDE (or in the final product) is only a good thing. Then the IDE must make the most of existing technology and therefore it is normal for the features of the latest operating systems to be exploited. Then if someone wants to work with clubs and stone tablets... well he is free to do so. Furthermore, the fact that the IDE only runs on Windows 10 or Windows 11 does not limit the development of applications that run on Windows 7 or Windows Server (or on Mac, Linux, Android) And although you say that the IDE is too far ahead, some would like it to be even further ahead and therefore with more stringent features. It's really funny to see how there are exactly opposite positions: someone would already like to think about 128 bits and someone would like to go back to 8 bits....

This is a little screenshot for Parnassus (not the last):

I have some getit packages in private Repo (like Styles and FastReport) and others in common Repo (like Parnassus, FmxLinux).

In the offline Rad Studio installer you can set those path before start the install process.

Sorry for the inaccuracy but I wrote quickly:

Why don't you set your new path for CatalogRepo ? In TOOL menu you can set you own path for that. And if that path need to be the same for all user every user can do the same. I have mine own path to a more accessible folder. It's simple and better also when you migrate the IDE.

In Delphi 11, when I changed some $IFDEF a lot of time the source code not changed. But the compile (full compile, not RUN hoping that IDE compile the right code) always does the correct work. In Delphi12, by now, changing $IFDEF always change the source code too. I use some $DEFINE and I never notice malfunctions.

May be, now is working, like the example in the Embarcadero unit .... but there are some facets to evaluate. program Project2; {$APPTYPE CONSOLE} {$R *.res} uses System.SysUtils; type IFoo = interface ['{5DEC09C5-FADC-46A5-814F-9ED91259A37F}'] function GetEmptyName: string; function GetFooName: string; end; IBar = interface(IFoo) ['{5DEC09C5-FADC-46A5-814F-9ED91259A37F}'] function GetBarName: string; end; //TFooBar = class(TInterfacedObject, IBar) //This is working too TFooBar = class(TInterfacedObject, IFoo, IBar) function GetEmptyName: string; function GetFooName: string; function GetBarName: string; end; function TFooBar.GetEmptyName: string; begin Result := 'Empty'; end; function TFooBar.GetFooName: string; begin Result := 'Foo'; end; function TFooBar.GetBarName: string; begin Result := 'Bar'; end; var i: IInterface; begin try { TODO -oUser -cConsole Main : Insert code here } i := TFooBar.Create; Writeln((i as IFoo).GetEmptyName); Writeln((i as IFoo).GetFooName); Writeln((i as IBar).GetBarName); except on E: Exception do Writeln(E.ClassName, ': ', E.Message); end; readln; end.