Remy Lebeau

Are you the one putting the data on the clipboard to begin with? If so, then why not store the required file size explicitly? If you can't put it in the MIME data itself, you can store it as a second format alongside the MIME data. The clipboard can hold more than one data item at a time.

In case anyone is not already aware of this https://quality.embarcadero.com is now in a permanent read-only mode. A new system is being implemented, but has not been opened to the public yet. So, if you do have a legit bug/feature to report, feel free to post it in a public forum, or write to Embarcadero directly, and someone who has internal access to the new system can open tickets for you until the new system is ready for public use.

No. Using a share path only works on the local LAN network, and only if the file is exposed by the server to the LAN via a UNC share to begin with. If you want to copy a file over the Internet, you need to setup a suitable TCP server for that, such as an HTTP or FTP server.

That is a completely different issue. I don't see how that applies here.

That is not correct. Technically, the path component is allowed to be empty in any url, per RFC 3986 sections 3 and 3.3: URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ] hier-part = "//" authority path-abempty / path-absolute / path-rootless / path-empty path-abempty = *( "/" segment ) path-absolute = "/" [ segment-nz *( "/" segment ) ] path-noscheme = segment-nz-nc *( "/" segment ) path-rootless = segment-nz *( "/" segment ) path-empty = 0<pchar> RFC 2616 section 3.2.2 tried to restrict an HTTP url to require a non-empty absolute path if the query component is present: http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]] But, RFC 2616 section 5.1.2 does allow the path in an HTTP url to be empty: RFC 7230 sections 2.7.1 and 2.7.2 loosen the restriction to allow the path in HTTP and HTTPS urls to be empty: http-URI = "http:" "//" authority path-abempty [ "?" query ] [ "#" fragment ] https-URI = "https:" "//" authority path-abempty [ "?" query ] [ "#" fragment ] Why would you an inefficient "Pos" check instead of using something like StartsText() instead? Or simply: "if (FPath = '') or (FPath[1] <> '/')" ?

Not without more information about what a "dauha attendance machine" is, and what its HTTP API actually looks like.

Clearly a nil pointer is being accessed, but there is not enough information to diagnose where exactly. Is it happening in your own code (the most obviously candidate is the ALVideoPlayerSurface1.VideoPlayer property being nil), or is it happening inside the Alcinoe library?

Sorry, that is not how HDPI works.

I meant exactly what I said. You can turn on Debug DCUs in the project options, and then step through the RTL source code at runtime using the IDE's debugger. No. Yes. There is only one place it fails - in the TThread.Create constructor. But at least you will be able to see the actual error code before the exception is raised (provided you can reproduce the problem at will), eg: constructor TThread.Create(CreateSuspended: Boolean; ReservedStackSize: NativeUInt); begin ... if FHandle = 0 then raise EThread.CreateResFmt(@SThreadCreateError, [SysErrorMessage(GetLastError)]); // <-- WHAT VALUE DOES GETLASTERROR RETURN HERE??? ... end;

Yes - use TIdHTTP.Head() instead of TIdHTTP.Get(). A HEAD request is identical to a GET request except that no body data is sent, but the response headers will be the same. A HEAD response will include the 'Content-Length' header, so yes, you can determine the file's size without actually downloading the file. However, if you are going to download the file anyway then there is really no point in checking for its existence beforehand, just download the file and handle whatever error may arise, such as HTTP 404 when the file does not exist.

What's wrong with using a standard message dialog?

Those properties have existed in TDateTimePicker since at least Delphi 5.

It sounds like you disabled/uninstalled the Indy packages from the IDE. Under the "Component" menu, choose "Install Packages", and make sure the 2 design-time packages dclIndyCore and dclIndyProtocols are installed and enabled. If they are, then make sure your project's search paths are configured correctly.

It doesn't matter what you put in the 'except' handler, the information you are looking for has already been lost before the code gets that far. If the error text is not already present in the raised Exception then there is no text to be retrieved. What you should be focusing on is why the error text is not present in the Exception to begin with. That would imply a bug in SysErrorMessage(), which the RTL calls when raising an EThread exception. If the thread failed to create than GetLastError() should not be returning an error code that has no error text associated with it (however, after an exception is raised, GetLastError() is not guaranteed to be meaningful anymore). So, I would suggest debugging the RTL source code when the thread failure happens and see what is really going on behind the scenes. You should not be getting a blank error message.

See Subclassing Controls on MSDN, and Safer subclassing on Raymond Chen's blog. For example: uses Winapi.CommCtrl; function CalendarSubclassProc(hWnd: HWND; uMsg: UINT; wParam: WPARAM; lParam: LPARAM; uIdSubclass: UINT_PTR; dwRefData: DWORD_PTR): LRESULT; stdcall; begin case uMsg of WM_LBUTTONDOWN: begin TDateTimePicker(dwRefData).Format := ''; end; WM_NCDESTROY: begin RemoveWindowSubclass(hWnd, @CalendarSubclassProc, uIdSubclass); end; end; Result := DefSubclassProc(hWnd, uMsg, wParam, lParam); end; procedure TForm1.DateTimePicker1DropDown(Sender: TObject); var cal: HWND; begin cal := DateTime_GetMonthCal(DateTimePicker1.Handle); SetWindowSubclass(cal, @CalendarSubclassProc, 1, DWORD_PTR(DateTimePicker1)); end;

Then you are just going to have to do what Peter suggested. Just assume today's Date is the default unless the user selects a different date, or else use another UI element to specify when the default Date should be ignored.

And yet, that is the way Microsoft wants you to use it. If you really want to detect a mouse click, you will likely have to subclass the window for the TDateTimePicker's drop down calendar to handle WM_LBUTTON(DOWN|UP) messages directly.

Or, use the TDateTimePicker.ShowCheckBox and TDateTimePicker.Checked properties instead.

Close() doesn't free the Form unless you explicitly ask for that behavior in its OnClose event (and even that, that logic uses Release() internally). In 20+ years using Delphi, I've never run into an AV from closing a Form. If you are getting an AV when closing a Form then you are likely mismanaging your code that uses the Form.

Release() destroys the Form that it is called on. Whereas Close() merely closes (hides) the Form, allowing it to be reopened (shown) again at a later time if desired.

I would opt to simply eliminate J altogether: function IndexOfFirstNotOf(const s: string; Ch: Char): Integer; begin for Result := 1 to Length(s) do begin if s[Result] <> Ch then Exit; end; Result := 0; end; function RemoveZeroLeft(const s : String) : string; var i : integer; begin i = IndexOfFirstNotOf(s, '0'); if i > 1 then Result := Copy(s, 1, MaxInt) else if i = 1 then Result := s else Result := ''; // or '0' if needed end;

You can't manually implement the interface of an anonymous method. It is a compiler-generated type that you can't refer to. And it doesn't have a Guid assigned to it, so you can't query for it at runtime, either. All you can do is hold a reference to it. The compiler generates the necessary code to call its Invoke() when it sees user code trying to call the anonymous method. It is possible to manually call Invoke() directly (by declaring the interface manually, and then casting the anonymous method), but there is no good reason to ever do that. They could, and that shouldn't change anything at all, because user code shouldn't ever be calling Invoke() directly to begin with. Nobody is "manually implementing" the interface of an anonymous method.

In modern versions, IDE updates are released on GetIt. Simply check there if any updates are available for download.

Unfortunately no. Empty groups are not displayed, that is simply how Microsoft implemented it. So, the only option would be to add a blank item to the group just to keep it visible, and then remove that item later when it is no longer needed.

Depends on the context. The compiler thinks you are using J's value before you have actually assigned any value to J. Sometimes the compile makes a mistake on this, sometimes not, so it may or may not be a false positive. How are you actually using J exactly? Can you show that code?