David Heffernan

3 hours ago, Remy Lebeau said:

TNT isn't even around anymore.  Not to mention it is largely unnecessarily anyway, as the core Delphi classes are now Unicode capable since 2009.

It's as necessary as it always was if you are using a pre Unicode Delphi. And yeah it's still around. Code doesn't vanish. Why would anyone develop it for compilers that aren't developed?? 

Most of the tnt components map cleanly to standard vcl components iirc

My take on this is that you want to start making changes in your Delphi 7 code base that don't change the meaning of the program there, but mean that it will compile and work as expected in both ANSI and Unicode Delphi. In an ideal world you'd be able to do all that work preparing for the switch and reach a point where you can compile with both ANSI and Unicode Delphi, and the program works the same.

Then you can cut the chord to Delphi 7 and commit to Unicode Delphi. Then you do the second piece of work which is to get the code working on 64 bit.

That blows my mind!!

3 hours ago, alank2 said:

That is the whole problem I am describing here.  They do not. 

Sounds a little implausible 

Obviously Microsoft's header files handle struct alignment correctly

Signing would help

6 hours ago, dummzeuch said:

So, why is that a problem? Is the code wrong? Or is it just not the way you would have written it?

I've never in my life seen it written like that. Sure it works. But when you read it, it's not familiar and so it makes you think about it. Impedence. Patterns matter. 

What's especially awesome about the VCL code is that it writes the for loop in a really weird way as 

for var I: Integer := 0 to -1 + Items.Count do

with the -1 before the count, and that seems to have taken from Setting the drop down width of a Combobox in Delphi – twm's blog (dummzeuch.de) which in turn is taken from Sizing the ComboBox Drop Down Width (thoughtco.com)

1 hour ago, Remy Lebeau said:

The code shown will not work, because of the way anonymous procedures capture variables not values:

I think the asker knows this. The question though is how many variables are there for an inline var inside a loop. Is there one variable? Or is the N variables where N is the number of times the loop body executes? 

That's the question being asked as I understand it. 

The answer is that there is one variable. 

Seems like this is the opposite behaviour from C#

https://stackoverflow.com/q/271440/505088

Personally I feel like Delphi has a poor design choice here. I'd expect a local variable that is defined inside a scope, to have a lifetime that was that scope. 

With the C# design you can achieve both possible behaviours by defining the variable inside or outside the loop body. In Delphi you have to resort to putting the body in a separate procedure. 

The we have C++ which allow capture by value or variable as specified by the programmer in code. That would also give the same flexibility but without requiring extraction to separate procedure. 

Or am I wrong? I'm basing this on reading and not practical experience so I may have misunderstood. 

Use the 32 bit debugger 

If you can distribute one file you can distribute more than one. This always feels like a pointless discussion. Solving a problem that doesn't exist. 

On 9/28/2023 at 2:59 PM, dummzeuch said:

Underwhelming featurewise might just mean they focused on fixing bugs.

Usually each release comes with a bunch of bugs fixed, and a new set of bugs released into the wild. I do think the product is slowly getting better though. 

3 hours ago, FreeDelphiPascal said:

they ask me where Delphi is situated in Tiobe

Do they treat you differently when you answer? 

21 hours ago, FreeDelphiPascal said:

But it is important for us (Delphi guys) because of the publicity. Everybody knows how poor Tiobe is, still everybody is quoting it.

Who cares about TIOBE? It's just irrelevant. 

On 9/25/2023 at 4:36 PM, luciano_f said:

We urgently need more robust IDE

It's strange that if this is what you want that you ask for something else. Classic XY problem. 

19 minutes ago, Anders Melander said:

If you are running out of memory at 2.5GB then the IDE is trying to make an allocation of 0.5 GB or more. This seems unlikely so there could be something else going on. You might wait to check the size of "hardware reserved memory" on your system.

Address space fragmentation and sub allocation fragmentation. 

Love the engagement here from the poster 

Yes, but what is reporting the memory leak? There are lots of leak detection tools. If you use full fastmm then you can get allocation stack traces. 

It doesn't sound like you've really understood the issue. Normally Text would just map directly to GetText. But we still have no idea what Value is. 

This thread displays a deeper problem. That you think we can tell you what is happening with such incomplete details highlights the fact that you are also trying to solve the problem without those details. 

We can't guess what the code is. We still don't know how you are detecting. 

We've no idea what Value is. How are you detecting that there's a leak. 

14 minutes ago, Sherlock said:

Lazarus on the other hand is dogfooding at its best

Is the debugging experience still terrible though? 

How are you detecting that the memory has been leaked? 

"Material is not a valid floating point value" 

Ask yourself why you are trying to convert the text Material to a numeric value. Do you know why yet?? 

7 hours ago, Vincent Parrett said:

I certianly hope they do not migrate the IDE to 64bit anytime soon - the 64bit compiler is no where near as good as the 32bit compiler (speed, code generation) - and switching to 32bit would switch around the debugging experience

 

32bit IDE
   32 bit debugging - not great
   64 bit debugging - awful

 

64bit IDE
   32 bit debugging - awful
   64 bit debugging - not great

Careful what you wish for.

This seems extremely optimistic