David Heffernan

It would have been trivial to solve if only you'd used the debugger. Make it your next mission to learn how to use the debugger. 

It's simple. Why write 

if SomeBool = True then 

when you can write 

If SomeBool then

It simply adds nothing. 

1 hour ago, Ole Ekerhovd said:

aUser.Administrator=false

Why is it so hard to reach the conclusion that aUser.Administrator is false? 

Instead of being helpless here, you can get help from us by providing a minimal reproduction. Easier still would be simply to debug your program. Have you done that? 

Never compare to False or True. Instead write 

if someBool then

Or 

if not someBool then

That's not your problem though. Your problem is quite simple. It's the most obvious explanation. You are mistaken, in fact aUser.Administrator is false. It's that simple. 

Yeah, modal dialogs and popup are deeply invasive. Find a different way to let the user know. 

31 minutes ago, A.M. Hoornweg said:

The default calling convention in Delphi is "register" (the compiler tries to pass parameters in registers if possible to speed things up). 

 

The "Stdcall" convention is used throughout by the 32-bit Windows API (which consists of DLL's).  So, for consistency's sake, it makes sense to adopt that calling convention for your own 32-bit DLL's as well. "Stdcall" tells the compiler that the caller of the function will pass all parameters on the stack in a right-to-left sequence and that the function itself is responsible for cleaning up the stack before returning.

 

As Remy Lebeau pointed out, in 64-bit Windows there's only one calling convention. So you could do something like this:

 

//in the DLL:

Procedure MyProc; {$ifdef win32} Stdcall;{$endif} Export;

begin

..

end;

... exports 'MyProc';

 

 

//In the exe:

Procedure MyProc; {$ifdef win32} Stdcall;{$endif} external 'mydll.dll';

 

 

 

 

 

 

 

As discussed above the conditional code simply adds clutter for no benefit. The compiler has already handled the issue for you. Remove the conditional, and let the compiler ignore stdcall in x64.

A second point is the use of the export directive. It is also always ignored (a hangover from 16 bit days). Again it should be removed.  Therefore the best practise would be to write:

procedure MyProc; stdcall;

And that's it.  Obviously you still need the exports list somewhere.

It depends on the window ownership (aka popup parent) relationships between your forms. What is that in your case? 

The ifdef is pointless and wasteless. On x64 stdcall is, like all calling conventions, ignored. So remove the ifdef and leave stdcall there for the platform that it has meaning. 

This class can't be used without the compare type being specified. 

1 hour ago, David Schwartz said:

Delphi doesn't have that ability, so you need to inject the really core initial parameters in the Create call, and then add others AFTER the object has been initialized via property injection.

This seems bogus. Define "really core" please. 

6 hours ago, Lars Fosdal said:

How is it worse?

You are advocating defining new classes in order to set a single field in the base class. If you can't see what is wrong with that I am surprised. 

6 hours ago, Lars Fosdal said:

How would you solve it? 

I already said. 

59 minutes ago, Mike Torrettinni said:

Thanks, so each type of comparer would be its own class, derived from main class. OK, not something I considered.

OMG, take a poor idea, and make it much worse

1 minute ago, Lars Fosdal said:

Having arguments to the constructor is something I try to avoid.

Also a false goal. 

49 minutes ago, Mike Torrettinni said:

So, the whole point was use as little units as possible.

That's a false goal. Remove that goal from your life. Following it will be making your code worse. 

It works. But better to have one constructor that accepts an argument. Think of the time you need to decide at runtime which path to take. Then your way is hopeless. 

Ugh, the code you write shouldn't need those ifdefs. That the entire point of you using the libraries provided by others, like Emba. They present a common interface to you. That's the entire point of cross platform coding. 

1 hour ago, David Schwartz said:

As if that has never happened with anything Microsoft ever published ...

Spend some time looking at the development process and quality over in C# and .net land, and then see if you honestly can regard Emba's process and quality even remotely in the same ball park. 

1 hour ago, Georgge Bakh said:

David, if I got you right, your advice is to use the technique with virtual methods because it works. It's a good advice thank you.

But I wanted to use generics as it's a powerful technique which I successfully use in other languages and it seems it should work for my case. And a broad range of other cases which can be identified as parametrization by code.

If it can't be done in Delphi it's sad but I'd want to know why. Is it a bug?

Let's get on with it:

I have TTest<TTest2> specialization of the above generic class TTest. May I expect that field FTest will have static type TTest2? If no why?

It's not a choice between either generics, or polymorphism. You can use both.

7 minutes ago, Georgge Bakh said:

Why?

Because that's the only way to make this work.

Your expectations seem unrealistic.  As I see it you face two choices:

1. Code it the way I said, and thus have your code work the way you want.

2. Code it your way, and have your code not work the way you want.

I don't understand why you want to take option 2.

constructor constraint isn't going to be much use here, you can get rid of it. What you need is a virtual constructor on the base class, and virtual methods. And then obviously to override those methods on subclasses. 

We don't really know what your main goal is. Hard to give useful advice. 

Define "best" please. 

Also, the try/finally seems a little pointless. 

49 minutes ago, aehimself said:

Could this "leak"?

no

46 minutes ago, Sherlock said:

I'm looking forward to a ton of bug fixes and performance improvements, for the IDE, the compiler(s) and the resulting executables.

The eternal optimist

Strange suggestions given that all symptoms point to memory leak in your code.