Anders Melander

Good thing we can invent new problems when we run out of actual ones to solve.

29 minutes ago, Angus Robertson said:

One common API to avoid for Windows 7 is GetTickCount64 which was added with Vista and Windows 2008, don't think Delphi uses it internally.

It does but the Win32 API is declared delay-load and the RTL resolves it dynamically with fallback to GetTickCount if it isn't available.

I also believe Indy uses it but with a similar dynamic fallback.

Winapi.Windows.pas

function GetTickCount64; external kernel32 name 'GetTickCount64' delayed; // 6.0

System.Classes.pas

function InitGetTickCount64: UInt64; stdcall;
begin
  if TOSVersion.Major >=  6 then
  begin
    var kernelLib: THandle := LoadLibrary(kernel32);
    GetTickCount64Func := GetProcAddress(kernelLib, 'GetTickCount64');
    FreeLibrary(kernelLib);
  end
  else
    GetTickCount64Func := @Winapi.Windows.GetTickCount;
  Result := GetTickCount64Func;
end;

16 minutes ago, Peter J said:

I was thinking that the page was talking about minimum Windows version for the generated applications, not the OS required for the IDE. I've been assuming it was related to the Windows API calls that the VCL etc depended upon.

The required Windows version really depends on the the VCL features you use. If you're using something that is only available in Windows 10 then naturally your application will use Windows 10 specific APIs. Otherwise it will not.

1 hour ago, Peter J said:

I'm trying to find out which are the oldest versions of Windows that different versions of Delphi could target, going back to Delphi 2009.

You seem to be confusing "target" and "run on".

In theory, all 32-bit compilers can target any 32-bit version of Windows and all 64-bit compilers can target any 64-bit version of Windows.

1 hour ago, Peter J said:

Embarcadero have documented as far back as Delphi XE4, which required Windows XP SP2 (32-bit only) or Windows Server 2008 as a minimum.

That page just document the IDE requirements and it doesn't really reflect the reality; Before I upgraded to Windows 10 I had been running Delphi 10, 11 and 12 on Windows 7 with no issues. The installer complains but it ran just fine.

1 hour ago, A.M. Hoornweg said:

That's not what I read

No, I can't see it from the sigmycode site either.

I'm positive that I read somewhere on the digicert site that you had to use 2-factor-authentication using a USB token but I could very well have misunderstood the context.

1 hour ago, Kas Ob. said:

this means any singing developer can have a glance of what have being signed last 5-10 singing procedures, with time, dates, authorization and the binary name.

TMI; People tend to ignore walls of text.

Log operations on the server instead so they can be examined by those who care.

8 hours ago, Vincent Parrett said:

Preview of the server web interface - product name may or may not change - naming is hard!

Looks good - and I like the name. Sufficiently distinct to be googleable.

Just now, Vincent Parrett said:

we calculate the digest on the client and send that to the server to be signed. 

Oh, nice. I didn't know you could do that.

It's a real PITA that we have to jump through all these hoops with the physical tokens and the fact that a solution like yours, which is basically a work around, is even possible proves that it was all in vain. But I guess somebody made a lot of money selling the tokens.

1 hour ago, Vincent Parrett said:

We're working on a code signing server that supports tokens/pfx etc - allows you to do remote code signing very easily. All you need is network access to the server from a remote location (ideally over a vpn) and the client (a command line tool, which FinalBuilder will support).

Let me guess: The client transmits the file to be signed to the server, and the server (which has the physical token) then signs the file and transmits it back to the client.

33 minutes ago, A.M. Hoornweg said:

...and users can access it remotely.

...once they have signed in with an USB token.

I don't think you can get around the requirement for the signer to have some kind of physical identification device.

Hmm. Okay.

I obviously don't know how your build server setup was, or what build system you used, but it should have been possible to completely isolate the different projects.

Independent projects, with different developers, tools, etc. on the same build server is nothing out of the ordinary.

Anyway, if you are working on different projects, and don't want a centralized solution, then why not just use different certificates?

2 hours ago, A.M. Hoornweg said:

Each team member uses Finalbuilder and Signtool to automate the process of compiling, code signing and generating setups.

There's your problem.

You should use a single central build server instead of delegating the build task to individual developers. If you don't have a central server which can function as a build server, at least designate one of the developers as the "build master".

Thanks. I just meant this:

procedure TReptTextEditor.FormKeyDown(Sender: TObject; var Key: Word; Shift: TShiftState);
begin
  case Key of
    VK_F1:  if Shift=[] then Application.HelpCommand(HELP_CONTEXT,HelpContext);
    VK_F10: if (ssAlt in Shift) then PopupMenu1.Popup(Left+100,Top+100);
  end;
end;

...and that looks okay.

1. Use TJPEGImage.LoadFromStream to load from the stream
2. Copy the TJPEGImage to a TBitmap using TBitmap.Assign
3. Add the TBitmap to the TImageList using the usual methods

1 minute ago, FaFaFooey said:

not really since my program was always fine until it hit the default working set because of the work load needed at that moment..

Full working set does not mean out of memory; We have virtual memory.

Can you explain why increasing the working set solved your problem?

7 minutes ago, FaFaFooey said:

microsoft has those apis for a reason.

https://aviationhumor.net/russians-we-paid-whole-runway-we-use-whole-runway/

31 minutes ago, FaFaFooey said:

So I found some code about setting the working set size and my program never crashed again

<Also known as throwing sh*t at a wall>

59 minutes ago, FreeDelphiPascal said:

Rudy Velthuis said on SO that "Class constructors are not executed on unit "initialization" but when the class is referenced"

He was wrong.

I think Cristian is on 11.3

If someone else, other than me (where it works), could check with 12.2 it would be great.

4 minutes ago, Cristian Peța said:

D 11.3, 150% dpi and it work only if I click the right half of the arrow. The red zone will open the dialog.

Strange. Works for me. Also with 150%

What I am seeing though (with 11.3 only), is that if I drop the list by clicking on the left half of the dropdown arrow, and then close the list with another click, then the open dialog is invoked. Dropping the list with a click on the right half works as expected.

17 minutes ago, David Heffernan said:

Well, good, they fixed that one!

I just tried with 11.3 and it works exactly the same.

Maybe I'm just not understanding what problem your are experiencing.

I'm on Windows 10, BTW.

14 minutes ago, ThomasRiedelDk said:

Sleep does nothing, and that is intended..

I'm curious; What's the purpose then?

13 minutes ago, David Heffernan said:

FWIW this is what I see with Delphi 11.3, and toolbar drop downs. I'm actually at 175% dpi, and running Delphi DPI aware.

Works for me with Delphi 12.1 at 175%

No comments on why it shrinks but I don't think your Sleep(100) does what you think they do.

Your main thread isn't doing anything while the Sleep executes so if the purpose was to let it process the messages generated by mouse_event then you will have to do that some other way. Application.ProcessMessages *shudder* comes to mind.

1 hour ago, darnocian said:

Again, sorry for the cross post:

Why apologize when you are doing it on purpose?

Is your form modal? If not, do you have a TAction on the mainform with the shortcut [Del] ?

KeyPreview is a property on the form. Unless you are intercepting keystrokes on the form there is no reason to have KeyPreview=True.

If you need KeyPreview=True then the problem might be that your event handler eats the [Del] key. Show us your code.