DelphiUdIT

20 minutes ago, Gordon Kenyon said:

They may have been working when you posted - just as they were not working when I posted. 

 

And right now? 

https://my.embarcadero.com/ is not currently working

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

5 hours ago, Gordon Kenyon said:

embarcadero.com is just a shell front page at the minute - none of the important links work like my downloads, my customer portal  etc. and docwiki.embarcadero.com returns a 504 Gateway Time-out

For me all the sites are working, except getit ...

4 hours ago, Gordon Kenyon said:

This forum and support https://idera.my.salesforce-sites.com/CG/ seem to be the only sites that are currently functioning.

I don't think is a good idea to insert your credentials here, until they are official announced like partners of Idera.

2 hours ago, FearDC said:

Anyway @DelphiUdIT, could you please tell more about problems that Indy upgrade caused to your D11?

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.

4 hours ago, FearDC said:

I'm sorry but I don't understand how to do this properly. I did clone https://github.com/IndySockets/Indy/pull/299 into local directory, added it to library path. I have Delphi 12 and up-to-date IdCTypes.pas and IdGlobal.pas. So what is next? 😛

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.

1 hour ago, Tsagoth said:

The SDK fails because some IsWow64 call fails, not fund in Kernel32.DLL

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"

2 hours ago, PavelOu said:

I probably cannot use DXE, as in the Install folder there is no DXEInstall, there is only DXE2Install, so the DXE from package folder is impossible to open ??

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

53 minutes ago, Brandon Staggs said:

Please provide a source or analysis of this. This seems unlikely in the extreme. 

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.

9 hours ago, aehimself said:

Because Win7 is the upgrade of XP on kiosks and built-in devices. If even say ATMs.

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.

2 hours ago, mel2024 said:

is like the new version of Notepad to Run only in windows 10 and windows 11.
There are still people who like the job to be done and they dont like "laguages" and "IDEs" like Photoshop.
and yea i still can do anything i like with D7 and D5 which has no Themes.
 

"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).

47 minutes ago, mel2024 said:

an IDE with themes which you cannot remove them
an IDE that doesnt installs on Windows 7, windows server 2008 R2 
is Just Dead.
The only delphi you can work is Delphi 5, Delphi 7

They try to find great names like "Athens" i bet the next verison will be Zeus or Apollon or who knows what BS

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:

1 hour ago, Lars Fosdal said:

 

Someone made a bad decision on "hardcoding" the location of the CatalogRepository to a user-owned location for an IDE that is installed for all users.

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.

4 hours ago, Stefan Glienke said:

RTTI does have nothing to do with it but TObject.GetInterfaceEntry - try the following code:

......

....

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.

Uhmmm for me it's not working, but maybe I'm missing something...
I'm almost certain that the "as" and "is" don't work if the GUIs are identical...

9 minutes ago, David Heffernan said:

I think the asker knows what GUIDs are used for. However the question is whether the use of the same GUID for two distinct interfaces is a bug or not. 

I agree with you, I just wanted to point out some sources on where to possibly look for further useful information on the topic.

I've already seen double GUIDs in interfaces in COM environments, and they worked correctly (or at least I never detected problems), but I never looked into them further.

You must use GUIDs when there is a need to use RTTI "as" and "is". Like you told, each interface should have a unique GUID, but I have already see that.

Start from here: https://docwiki.embarcadero.com/RADStudio/Alexandria/en/Object_Interfaces_(Delphi)

(may be the link is wrong ... wiki is down at the time of writing)

P.S.: You can read also these books (with examples)

- Hodges Nick - Coding in Delphi (year 2013)

- Hodges Nick - More Coding in Delphi  (year 2015)

I don't know if there are something that can help you ...

Yes since Friday evening.

1 hour ago, dormky said:

Except that I'm putting the timer in a thread for a reason. If it's on the main thread, it runs the risk of getting delay by other work (namely, heavy drawing). If the timer is delayed, the event is delayed too.

If the system is overloaded all activities and processes including threads, events, etc ... will inevitably be delayed.
To mitigate this you can just "play" with the thread priority.
Using sleep in a thread at a higher priority than normal is usually a satisfactory solution.
However, if the timer needs to be triggered (i.e. it is not always active), then you should use sleep in combination with a WaitFor.
As @Dalija Prasnikar says, it is not possible to provide you with further solutions if you do not present code or delve deeper into the topic.