dummzeuch

Hm, that's the median salary not the arithmetic average. Not sure what the effect of that would be. Usually I tend to see the median to be the better figure for comparison. Edit: Salaries also vary greatly depending on the country and the tax/benefits. E.g. a salary of 60000 Euros in Germany means that on top of that the employer mandatorily pays half of several social security contributions (that's health insurance, pension, unemployment insurance, care insurance) which amounts to roughly 10% extra (60000 Euros -> become about 66000) so when you compare that to say 60000 US$ you not only have to consider the current exchange rate but also these factors. In the US most "benefits" are not mandatory, no idea if they are part of the salary somebody will fill into such a questionnaire.

Wow, learned something new today. Sure, but I don't see the problem; Don't use them if you don't like them. I am not talking about interfaces that I design, but those I have to use (e.g. in the ToolsAPI or 3rd party libraries). Not much choice there. My own interfaces don't get properties. They usually have a getter that's called like the property would be (so MyValue rather than GetMyValue) and a setter with the standard name (SetMyValue).

For interfaces properties are purely syntactic sugar so you really don't have to use them if you prefer not to. You can just call the getters or setters directly. How is that a pain? Because once these properties exist in an interface, every class that implements the interface must also declare them. For a class at least properties are usually public/published while their getter/setter methods are private/protected, so one could argue that using a property reduces clutter. For an interface both the property and the getter/setter methods are public, so that argument doesn't apply.

TSomeClass private FFoo: string; public // with props property Foo: string read FFoo; // without props function Foo: string; ... function Foo: string; begin Result := FFoo; end; OK, I should have explicitly said "readonly properties with a getter method", because that's what I meant.

... unless they are published and used via RTTI, e.g. in the Object Inspector or in some serialization code. Apart from that I partly agree. Especially the value of readonly properties is nearly zero and for interfaces they are a pain in the lower back.

So, what is your question? Do you want to know how to provide such a window list in your own application?

You can't. But you can compile your own GExperts DLL and replace the one in your installation.

If it occurs often enough, you might be lucky to catch it by running the IDE itself in the debugger and looking at the call stack. But beware: There are also quite a few exceptions during startup that are normal.

The problem here is, that in Delphi "blocking" means that the UI freezes, unless he calls Application.ProcessMessages, which has its own drawbacks (e.g. other events can be fired, some of which may not be desired).

I think I said this before: The main reason for this was, that I forget about this problem until yet another Windows update breaks my Delphi installation again. Every time I had to remember the solution (that's why I blogged about it, so I could look it up) and then search for these bloody files. One time I have had enough... If it also helps others, that's great. To be fair: It's not Microsoft's fault but Borland's/Codegear's: These files do not belong into a system directory, but since we are stuck with this it's still annoying.

I fixed a bug in the dxgettext executable which made it add wrong ressource string names to the po files which in turn made the msgmergePOT tool select wrong translations. You will have to compile your own executable to get this bugfix. The source code is in the project’s svn repository on SourceForge. Also I added scripts to generate partial German and French translations for Delphi 10, 10.1, 10.2, 10.3 and 10.4 and even added those partial translations for Delphi 10, 10.1, 10.2 and 10.4 (note that 10.3 is missing) to the repository. Warning: These translations may still be faulty.

Committed.

All functions for copying / moving the contents of memory from one buffer to another seem to end up calling System.Move. (e.g. Windows.CopyMemory and Windows.MoveMemory). Is that really the fastest way to copy large amounts of data? Edit: This is about the 32 bit compiler for Windows. In my case these are Mono8 bitmaps with a resolution up to 5120x5120 = about 26 MB or BGR8 bitmaps with HD resolution (1920x1080 * 3 bytes = about 6 MB (or even BayerRG16 or Mono16 Bitmaps with up to 5120x5120 * 2 bytes = about 52 MB). These come in a buffer delivered from a camera API which must be returned as fast as possible, so I need to copy these pictures to another buffer for further processing and do it fast. The buffers don't overlap in that case which is something that Move takes into consideration, so there is some small amount of optimization possible. I think it might be possible to make it faster using some MMX/SSE instructions, but I am not familiar with that. I tried to google for this, but Google kept showing showing results for the C function CopyMem, as usual ignoring the "Delphi" part of my query (even when put in quotes).

I understood that. I just tried it anyway just because that was easy to do and doesn't hurt. The pictures are huge: 5120 by 2000 with Mono8 pixels, so about 10 MB each. Sometimes they get even bigger: Up to 5120x5120 with RGP8 pixels. But that's very rare so far, so I don't care about performance for these at the moment. But I'm sure, since we have got this camera now, it will be used in more projects. I have already done that, as far as possible: As said before: This time it's a different program but the same basically applies: I try to avoid moving this data if possible at all. Hm, maybe using smaller buffers for only parts of the picture, as you suggested above, could help here. I'll have to think about that one.

No, not that part. I have simply replaced some part that I thought might contribute a bit to the overall performance and was easy to replace. I timed the result and found that it didn't make any difference. Took me about 30 minutes so not much wasted effort. Through other means (improved algorithm and multithreading) I have already reduced the overall time for one work unit of the program to 1/3 compared to the original code. The program which I now used for the test is not the one I mentioned in the original question. That one has already gone into "production" about a month ago and the performance is "good enough".

I finally came around to trying it with a 32 bit application and found no measurable improvement. Maybe I am doing something wrong, as there are several IFDEFS in the code which I don't understand what they are doing. Or maybe the move operation is simply not that important in the overall performance of the program. I did not do any specific timing for the move operation itself as I think it's pointless if it doesn't improve the performance of the program noticeably.

I just wanted to have a quick look, but you seem to have changed the formatting in many places. This makes it much more difficult to spot any real changes. So this will have to wait until I find some more time.

Yes, that's another option. The most likely outcome will be fragmentation though. Instead of one mostly dead project, there will be several, most of them dead ends, and any prospective users or contributors will wonder which one to use. Moving the project anywhere else won't solve that, though. There are many dead projects on e.g. github too. Unless of course somebody takes up the burden of maintaining the project, which I think is rather unlikely.

There are two options: Contact Lars Dybdahl, the official maintainer Send these patches my way and I'll have a look and possibly commit them to sourceforge (as far as I know I am the only one left who has write access there, but I have no admin access). By now even the official dxgettext website dxgettext.po.dk no longer works (at least my browser gets redirected to delphi.dk which then only shows an error), it looks as if the project is even more dead than it used to be. Also, I haven't heard from Lars for a long time. So sending them to me is probably the option with the best prospects of success.

Hm, interesting. I didn't even know this is possible. At a first glance Delphi 2007 doesn't look too bad on a 4K monitor with scaling set to 125% or even 150%. (GExperts has has some problems though). Unfortunately this seems to be a global setting for the executable rather than a setting for a shortcut only which makes it a lot less useful.

It will probably work much better for this use case than for the IDE, because you can simply fix the source code rather than trying to patch the executable at runtime. I guess you are aware that instead of setting the Windows compatibility options for an executable you can simply add a manifest to your executable that tells Windows it is HighDPI aware?

It was fun playing around with this, but the result is a bit disappointing once you get over the first "wow, it works". Just in case anybody else wants to have a go, here is the result of the last two days of "work". Note that the source checks whether Application.ExeName is 'hbds.exe' to decide whether to install the wizard or not. To get this to work, you will either have to remove that check or copy the bds.* files in the Delphi 2007 bin directory to hbds.* and of course set the Windows compatibility options for that hbds.exe rather than for bds.exe . It will add a new menu "High DPI" to the IDE's main menu with two entries "patch" and "un-patch" which should be self explanatory. Have fun, but remember: I will not fix your computer if you break it. 😉 @Attila Kovacs thanks for that idea which was quite fun to play around with. Take whatever you can use from the attached sources. Delphi2007HighDpi.zip

Yes, this seems to work, even when reading it and setting it to the same value. It also makes the OnMeasureItem event redundant. (edit: No that event is still necessary.) That solves the problem for the tree view, but unfortunately not for the TVirtualTreeViews used in grid mode (e.g. the message window or the breakpoint list). There even setting the font size does not make any difference.

If you have got more than one monitor with different DPI settings, it makes all lot of sense to change the IDE scaling on the fly. Just imagine moving a window from a 4K monitor with 150% scaling to a HD monitor with 100%. (And guess who has got such a setup...)

uses TypInfo; function TAdvancedObject_SetIntProperty(_Instance: TObject; const _Name: string; _Value: Integer): Boolean; var PropInfo: PPropInfo; begin PropInfo := GetPropInfo(_Instance.ClassInfo, _Name); Result := Assigned(PropInfo) and (PropInfo.PropType^.Kind = tkInteger); if Result then TypInfo.SetOrdProp(_Instance, PropInfo, _Value); end; // called as TAdvancedObject_SetIntProperty(AComponent, 'DefaultNodeHeight', FVtNodeHeight);