Jump to content

Der schöne Günther

Members
 View Profile  See their activity

  • Content Count

    741

  • Joined

  • Last visited

  • Days Won

    12

Posts posted by Der schöne Günther

  1. Posted

    Adding a ipv6 binding causes Indy to call socket like this: 

    socket(AF_INET6, SOCK_STREAM, 0 {no protocol specified})

    which is apparently fine with Windows as it returns a valid socket descriptor, although ipv6 is disabled. Maybe this is just a problem when UDP is used?

     

    For me, everything seems fine. It doesn't seem I need to handle the "ipv6 was manually disabled" case. 😎

  4. Posted

    1 hour ago, Angus Robertson said:

    using localhost will try both IPv6 and IPv4, so best to have your server listening on both 127.0.0.1 and ::1

    That did the trick, thank you!

      

    Time taken for http://127.0.0.1: 28 ms
Time taken for http://localhost/: 6 ms
Time taken for http://localhost/: 5 ms

    I hope I did that binding stuff correctly:

      

    constructor TServerClientTest.Create();
var
	binding: TIdSocketHandle;
begin
	inherited Create();

	server := TIdHTTPServer.Create(nil);
	binding := server.Bindings.Add();
	binding.Port := 80;
	binding.IPVersion := TIdIpVersion.Id_IPv4;
	binding.IP := '127.0.0.1';

	binding := server.Bindings.Add();
	binding.Port := 80;
	binding.IPVersion := TIdIPVersion.Id_IPv6;
	binding.IP := '::1';

	server.OnCommandGet := handleServer;

	client := THTTPClient.Create();
end;

     

    • Like 2

  6. Posted

    I am running a http server locally. I am connecting to it from the very same process.

    I am very puzzled by the time it takes. To me, it seems that resolving the name "localhost" takes 2 seconds before it times out and defaults to "127.0.0.1":

      

    Time taken for http://127.0.0.1: 42 ms
Time taken for http://localhost/: 2008 ms
Time taken for http://localhost/: 3 ms

    This is the full source code:

      

    program Project1;

{$APPTYPE CONSOLE}
{$R *.res}

uses
	System.SysUtils,
	System.Net.HttpClient,
	System.Diagnostics,

	IdContext,
	IdHTTPServer,
	IdCustomHTTPServer;

type
	TServerClientTest = class
		private var
			client: THTTPClient;
			server: TIdHttpServer;
		private
			procedure handleServer(
				AContext: TIdContext;
				ARequestInfo: TIdHTTPRequestInfo;
				AResponseInfo: TIdHTTPResponseInfo
			);
		public
			constructor Create();
			destructor Destroy(); override;
			procedure Test(const url: String);
	end;


constructor TServerClientTest.Create();
begin
	inherited Create();

	server := TIdHTTPServer.Create(nil);
	server.Bindings.Add().Port := 80;
	server.OnCommandGet := handleServer;

	client := THTTPClient.Create();
end;

destructor TServerClientTest.Destroy;
begin
	server.Free();
	client.Free();
	inherited;
end;

procedure TServerClientTest.handleServer(
	AContext: TIdContext;
	ARequestInfo: TIdHTTPRequestInfo;
	AResponseInfo: TIdHTTPResponseInfo
);
begin
	AResponseInfo.ContentText := '<html><body><h1>Hello World</h1></body></html>';

	AResponseInfo.WriteHeader();
	AResponseInfo.WriteContent();
end;

procedure TServerClientTest.Test(const url: String);
var
	stopWatch: TStopwatch;
begin
	stopWatch := TStopwatch.StartNew();
	try
		server.Active := True;
		client.Get(url);
	finally
		stopWatch.Stop();
	end;

	WriteLn( String.Format('Time taken for %s: %.0f ms', [url, stopWatch.Elapsed.TotalMilliseconds]));
end;

var
	serverClientTest: TServerClientTest;
begin
	serverClientTest := TServerClientTest.Create();
	try
		serverClientTest.Test('http://127.0.0.1');
		serverClientTest.Test('http://localhost/');
		serverClientTest.Test('http://localhost/');
	finally
		serverClientTest.Destroy();
	end;
	ReadLn;
end.

    Does anybody have an idea why this is?

  7. Posted

    1 hour ago, FPiette said:

    You may have a thread still running.

    Not necessarily a thread (the application will close anyway), but a task:

      

    procedure TForm1.Button1Click(Sender: TObject);
begin
	TThread.CreateAnonymousThread(
		procedure()
		begin
			while true do;
		end
	).Start();
end;

procedure TForm1.Button2Click(Sender: TObject);
begin
	TTask.Run(
		procedure()
		begin
			while true do;
		end
	);
end;

    The application will close fine after Button1 has been clicked. The executable, however, will never terminate after closing the main form if Button2 was pressed.

  9. Posted · Edited by Der schöne Günther

    The "express edition" of Documentation Insight was only bundled with RAD Studio until XE5.

    After that, it was removed.

     

    Source:

    DevJet Software » Documentation Insight Express has been released with RAD Studio XE2

     

    As far as I can remember, you should be able to copy some files from your XE5 installation over to a new RAD studio version and the mouseover will still display as it did in previous versions.

     

     

     

  10. Posted

    Quote

    I'm told that a workaround was proposed by EMB but that the workaround would take an enormous amount of time to implemented by us.

    Can you link us where that was proposed? I don't see a workaround suggestion.

     

    Looking at the three required conditions for memory to leak:

    Quote

    The 3 ingredients required to expose the problems are:

    1. Have an inline variable
    2. Have a function returning an instance that must also be managed
      1. The returned instance must not be used
    3. Have an Exit statement

    Can't parsers like FixInsight help here? I think (2) should be a rare enough occasion and still easy to find.

  12. Posted · Edited by Der schöne Günther

    I don't have a full solution for you. The "Embarcadero.DesktopToasts." plus some hash value at the end is hardcoded into System.Win.Notification.pas

     

    You need to take a look at the constructor above and probably

    class function TNotificationCenterWinRT.CreateShortcut(): Boolean;

     

    I would assume (not tested) that you can either

    1. Create your own subclass of TNotificationCenterWinRT that does not have this weird behaviour
    2. Modify System.Win.Notification.pas

     

    Also, you might want to post this at quality.embarcadero.com

     

    Altough the last time it was brought up (2016), it was closed as "Cannot reproduce"

    https://quality.embarcadero.com/browse/RSP-14776

    • Like 1

  13. Posted

    Which Delphi version are you using? When I check in 10.0 Seattle, the following code from System.Win.Notification makes it pretty obvious:

      

    constructor TNotificationCenterWinRT.Create;
var
  LWSAppID: TWindowsString;
begin
  inherited;
  FNotifications := TDictionary<string, IToastNotification>.Create;
  LWSAppID := TWindowsString.Create(AppId + THashBobJenkins.GetHashString(ParamStr(0)));
  FToastNotifier := TToastNotificationManager.Statics.CreateToastNotifier(LWSAppID);
end;
      private const
    AppId = 'Embarcadero.DesktopToasts.';

    I would not expect it is still like this in current Delphi versions.

  16. Posted

    On 12/3/2020 at 5:38 PM, Damon said:

    Also, Does anyone have the new TEdgeBrowser working?

    For months. It works flawlessly. Keep in mind that you don't get anything from installing Edge on the target computer. You must either install the runtime, ship the needed binaries or install a beta/dev version. Explained here:

    https://docs.microsoft.com/en-us/microsoft-edge/webview2/concepts/distribution

  18. Posted · Edited by Der schöne Günther

    After we had migrated a project from 10.0 Seattle to 10.4 without any issues and it was working great, we have now migrated the next (bigger) project by 95 %. However, we are constantly having trouble with code completion in 10.4.1, it often stops working completely.

     

    As code completion appears to be a separate process, we have three "DelphiLSP.exe" living besides the good old "bds.exe". When code completion stops working, I thought terminating these processes would trigger the IDE to restart them. But this doesn't happen.

     

    Do I have another option besides completely shutting down the IDE, opening it again, loading the project and navigating to where I just left off?

  21. Posted · Edited by Der schöne Günther

    This doesn't answer your question, but ...

     

    ... this screams for unit tests like "Ensure requests are still properly going out after the previous server disconnected right in the middle of the transfer, sent garbage or timed out". Not only would you not have to constantly re-recreate clients, you can also sleep easier, knowing (instead of hoping) it works.

×