Anders Melander

Without access to the compiler source it's hard to tell, but I'll bet there are some. For one, as far as I can tell, it would require forward declaration of the record and I know there are good reasons why that isn't possible. How would you envision forward declaration of a record method would look?

Agree. But your wise words are missing the point that the value of GetLastError is irrelevant in the context. Being curious about the value is pointless. Those that are curious about it regardless could just examine the source, and when that turns up no clue, trace though CreateThread in a kernel debugger, but in the end it will amount to nothing because the value [drum roll] doesn't matter.

You are wasting both your own and our time but as usual here the discussion continues ad nauseam even though the question has been resolved in the very first answer to the original post. I'm not sure how to explain it in a way that we haven't already tried. The value is meaningless, undocumented, random, forget about it ffs! If you really want an answer to this question, I suggest you ask it on stackexchange. I'm sure it will get the answers it deserves... Add a link back to this discussion for bonus points.

I think you did. Since the value of GetLastError is meaningless the way you used it: It doesn't matter and It doesn't matter

AFAIK it isn't and there's no reason for you to do it yourself because the value is irrelevant unless you're testing the result of an API function that has indicated that GetLastError should be used to get information about a failure. Here's another example of the exact same mistake: CreateThread() // GetLastError() returns 87 You don't need to "clear LastError" unless your function is using GetLastError as it's own status reporting mechanism and that would be very rare.

Probably not. The interpretation would depend on the API function that set the status value (notice I'm not calling it an error code). For example it could mean that a supplied parameter value didn't apply to the current context. As long as the caller handles the condition somehow then everything is fine.

I agree. The test case is invalid. Nope. There's no API contract that promises you that GetLastError will or should be zero at the point where you are testing it. If it's important to you that it is zero then sure, go ahead and set it to zero but it would be better to not misuse GetLastError that way. You should test GetLastError right after you have made an Win API call because at that point it will have been set to a relevant value.

Um... you're responding to a post which is over a year old, written by a person who's no longer alive...

Give it a rest, will you?

This is not related to your problem, but you should PostQuitMessage if you remove a WM_QUIT from the message queue.

Tools > Options > Environment Options > Environment Variables

No.

There are a lot of things that can cause this. Probably something you have running on your system. Might even be the debugger. https://devblogs.microsoft.com/oldnewthing/20160616-00/?p=93685 https://devblogs.microsoft.com/oldnewthing/20031001-00/?p=42343

or "more wrong" 🙂

I use DevExpress and I'm semi-satisfied with it. Besides the occasional update for new ribbon styles they rarely add new skins and some skins can be a real challenge to use. Many skins have problems with white text on white background with certain parent/child control combinations (or grey text on black background for the dark skins).

It seems you have just reverted the two sections of code to the way they where in Delphi 10.2, but do we know why they were changed in the first place. Your fix might be reintroducing another bug. I've not analyzed the internals of the thread pool but your change, and the rationale behind it, "feels" more correct than the original code.

const MSG_CLOSE = WM_USER; type TMyForm = class(TForm) private procedure MsgClose(var Msg: TMessage); message MSG_CLOSE; public procedure DoIt; end; procedure TMyForm.MsgClose(var Msg: TMessage); begin Close; end; procedure TMyForm.DoIt; var NextForm: TMyNextForm; begin NextForm := TMyNextForm.Create(Application); // Close deferred PostMessage(Handle, MSG_CLOSE, 0, 0); // Open next form NextForm.Show; // or ShowModal end; If your form is destroyed when it is closed then you can just use TForm.Release instead.

Okay. I've never used VCL styles so I have no other suggestions.

Assuming you've not already done the obvious and googled "delphi tframe styles", have you made sure that ParentBackground=True on the frame?

Don't create dependencies between unrelated forms (or even related ones but that's another matter). It's hard to advise you when I don't know the architecture of your application but let's assume that it's a small application with a main form and the three forms you mentioned. Decide on where the controller role should lie. In a small application this can just be the main form. Make sure the controller knows the state of the different forms it controls. Only open and close forms via the controller. Now it should be a simple job of closing the two other forms if the third is opened. You may need to use postponed close with messages or TForm.Release depending on how the lifetime of your forms are managed.

You don't need any components. Just use the COM interface: https://docs.microsoft.com/windows/win32/adsi/active-directory-service-interfaces-adsi I haven't worked with AD but my guess is that you just need to import the relevant type library and work from there (Component > Import Component...): but start by reading the documentation.

In my work there's rarely a difference. I have a lot of clients where the job boils down to "our code sucks - fix it". The problem is often the complete lack of a framework - or a badly designed one. Yes! In my work process I usually refactor and redesign iteratively, continuously changing stuff toward a distant goal while making sure the new code still works. In the beginning the size of the code and the complexity grows as the solution now contains both the old mess and the new solution. Then at some point it's as if the junk suddenly evaporates and I'm left with amazingly little code. Always a good feeling.

Unless you expect the unexpected 🙂 No but seriously, my experience is that if your hardware and the drivers are good, then Windows is pretty stable. Bad drivers can really mess Windows up but I guess that's expected. I'm also fairly conservative about what software I allow on the system. No cloud storage (iTunes, GDrive, etc), Chrome or Logitech drivers. The Up Time on my main development workstation is currently 163 days...

I think it's pretty clear: You need a license per developer, not per end user:

Read the StackOverflow post David linked to.