Anders Melander

Y-key broken?

I agree. In my own code I assume "unknown version" = Last known version+1. That way new versions doesn't break the code and I very rarely need to update the include file.

I've just committed updated packages for Delphi 11 and added Delphi 11 to GR32_Compiler.inc (and cleaned it up a bit).

I would think that it's just a matter of adjusting the dependencies of the existing packages with the corresponding D11 dependencies and recompile, but I'll look into it.

There's only one L in ProDelInterface27.

How is more clear than ?

Yes, it probably could be done, but should it? It's not a bad idea, but without low level compiler support (on E: IMyError do ... ) I wouldn't do it. Personally I want my error handling to be as simple and robust as possible so it doesn't potentially make a bad situation worse.

Upgrade from Windows 2000 🙂

I'm not questioning the usefulness of it. I would absolutely love that feature. I'm questioning why Embarcadero would want to invite the inevitable complaints when the feature, inevitably, failed to work 100% of the time - or even just not as good as VC/VC++. AFAIK, what UE does is just reloading dynamic DLLs if you recompile them. Not really comparable I think.

Makes sense. Thanks.

I know you're just venting, but I can't see how they could achieve it even if the debugger was better... or why they should.

Why was their original decision "the wrong thing"? Wasn't it simply a business decision that a (maybe large) group of people was dissatisfied with?

I don't think I've ever had a situation where that didn't just mess everything up. I think it just adjusts the EP so the other registers will not contain the values that corresponds to the new EP.

Start here: Floating point numbers — Sand or dirt What Every Programmer Should Know About Floating-Point Arithmetic What Every Computer Scientist Should Know About Floating-Point Arithmetic

Thanks. I'm not using it that much myself at the moment because it takes VTune about an hour (no kidding!) to resolve the symbols of the application I'm working on 😕

Hmm. Normally I would say that maybe it could be explained by a change in the window frame width due to Win11, but given the size of the change (-317 pixels) it must be something else. Unfortunately I don't have a Win11 system with D11 on it yet so I can't try to reproduce. If you edit the DFM file in notepad and remove everything but the form properties, does the problem (i.e. open in the IDE, save file, size changes on save) still occur? If yes, can you attach the edited DFM here?

So revert to a version that does exhibit the problem and try again. You are using version control, right?

Well, save the file and compare the DFM before/after. What changed?

Well now that I think about it the setting doesn't have to be enabled. When you have a form opened in the IDE then the IDE will use the opened copy of the form (and the source) when compiling instead of using the original on disk. So let's say that loading the form somehow alters the state of the TCustomForm object. When compiling the problect this form is "saved" (i.e. the DFM is streamed in binary format) to the internal buffer and then linked into the executable as a DFM resource. If you open the form in the IDE and (view it in form designer ) and then immediately close the unit, are you prompted to save the unti?

My guess is that the values are modified on save and that you have Save on compile checked. There could be something wrong with the writers defined in TCustomForm.DefineProperties.

Need a hug? 🙂

I think even back then people were complaining that Delphi exes were too big. It's not that I can't see the beauty of small executables (I envy the size of an exe produced by a C program using only the standard libraries), the size just hasn't been a priority in what I used Delphi for for a few decades.

That doesn't really say anything. Most of Windows is written in C and asm, so are more fair comparison would be against Turbo Pascal...

Yup. Found the following comment in the Drag and Drop Component Suite source code:

No, not always. There was a time when Windows didn't handle it properly or at all. The details eludes me though so it was probably pre-Vista. You can't lay all the fault on Delphi. There have been many versions of Windows that didn't handle images in menus properly. For example I know I've had to resort to ownerdrawing menu items in Explorer context menu extensions because some combinations of menu item attributes caused the images not to be drawn or drawn incorrectly.