dummzeuch

Nobody is looking at the issue tracker any more, I wouldn't be surprised if it turned out the admin sccount for it has been lost. But on the Github page things seem to be not quite so dead.

I have got to handle huge files which store floating point numbers between 30 and 200 with a precision of 3 decimal places. Currently the file format uses the floating point type Single for these numbers. Each requiring 4 bytes. Is there any way to reduce that memory requirement without sacrificing (or even improving) precision? My first idea was to: subtract 30, giving me numbers between 0 and 170 squash that into 2 bytes using the largest possible 10 based divisor Unfortunately that gives me only two decimal places with a divisor of 100 because 17000 < 65535 < 170000 Alternatively I could use a divisor of 200 which would fit into 2 bytes as 34000 but I would still lose some precision. I could use 3 bytes rather than 2 which would give me the required precision 170000 < 16777215 but would be awkward to handle. I could even reduce that to 18 bits with even more awkward handling involved. Any alternative ideas? Background: These files store the data of macro texture laser measurements in road condition surveys. There are 2x200 values for every 25 cm surveyed, giving me 2x200x4 values per metre plus some additional info for each dataset. While that isn't much when compared to the videos, this data will frequently be transferred via mobile internet (which in Germany means bl***y slower than in the average 3rd world country), while videos won't. I see two options here: Make the file format use less space without sacrificing precision Always compress and uncompress the files with some standard algorithm I'm not quite sure which way to go yet.

Yes. I never even thought about using tabs because they usually are a pain in the lower back everywhere.

These values are used for measuring the "macro texture". In the end they are combined into two numbers, the Mean Profile Depth (MPD) and based on that the Estimated Texture Depth (ETD). There is an ISO standard for the measurement and the (rather complex) calculation. Those numbers describe a part of what constitutes skid resistance of a road. And that's about structures that are nearly too small to see. The way to measure it requires 200 values measured in a line, no more than 1 mm and no less than 0.5 mm apart. For the calculation I need the full resolution of the laser, so any lossy compression is out. (One could argue that the algorithm loses most of that resolution anyway and that there is already a lot of noise in the data, but I have to adhere to the ISO standard.) The linked Wikipedia article describes quite a lot of what we do in road condition survey, just in case anybody is curious. We survey all autobahns and federal roads in Germany every 4 years, about 1/4 each year. On top of that there are the state roads and lesser roads, that should be surveyed once every 5 years. There are only a hand full of companies that offer this service. We are the market leader in Germany, but we are also active in Switzerland, Austria and France.

The code for the toolbar itself is in the aptly named unit GX_Toolbar, which can be found in the subdirectory EditorToolbar of the source directory. Since that is so obvious, I thought you were asking for more details, in particular since your question mentioned the icons.

I just had to look it up myself, so here is what I found: The code for registering the GExperts actions with the IDE is TGXActionBroker.RegisterActionWithIde in GX_ActionBroker. This method is called from .RegisterAction and .RegisterMenuAction which in turn are called from various places within GExperts. The bitmap to use as an icon is passed as a parameter to that method. so if you grep for RegisterAction and RegisterMenuAction you should be able to find where these bitmaps come from. Most of those bitmaps probably come from a call to GxLoadBitmapFromResource in GX_Utils, which loads these bitmpas from the resource file GXIcons.res (located in the images folder of the GExperts sources which is linked into the DLL. That resource file in turn is generated from the bmp files in the same directory. So I guess it would be possible to somehow manipulate these bitmaps when they are being loaded or load different bitmaps for dark mode. Not sure whether that covers all bitmaps though.

I just for the first time ever came across the warning "[DCC Warning]: W1013 Constant 0 converted to NIL". I got it for the following piece of code: var SomeList: TList; //... SomeObj := SomeList.Extract(0); // <== here WTF? I would have expected a compile error, not a warning because TList.Extract is declared as: function Extract(Item: Pointer): Pointer; inline; without any overload. I overlooked that warning a first, expecting an overload with an integer parameter (the index into the list like with Delete), which would make a lot of sense. (This is with Delphi XE2.) So apparently the compiler automatically converts the integer 0 to a nil pointer. Who (tf) considered this a feature? This is Pascal, after all, not C and is supposed to be type safe!

Hm, wasn't the point of the first post in this thread that FreeAndNil isn't big enough of a subject to make a whole video about? Two pages of discussion say otherwise.

So does the check for <>nil in .Free

I agree that it is a bug, but exactly because of this the issue can not be ignored.

Actually, obj.Free already checks for NIL, so the if statement is unnecessary. FreeAndNil also does something different than the name implies: procedure FreeAndNil(var Obj); var temp: TObject; begin temp := TObject(Obj); TObject(Obj) := nil; Temp.Free; end; (That's the old, non-typesafe version, if I remember correctly) So it should actually be called NilAndFree because it first sets the Object reference to nil and only then calls its Free method. That has some implications if there is code in the destructor / called from the destructor that references the object instance via the same pointer (which shouldn't be done but I have seen it been done.

The 13th (or even 14th in banks) monthly salary in Germany is no bonus, It is part of the regular salary and cannot be withheld if business is slow. It is usually paid with the November salary. It is kind of a tradition here. Personally I think that is kind of stupid. There isn't really any advantage in getting paid the yearly salary in 13 parts rather than 12, but apparently many people don't understand that and insist on it. Of course there are also contracts which specifically specify as a bonus (sometimes on top of the 13 monthly salaries), which in that case isn't considered a "13th monthly salary" but (guess what?) a bonus.

Taking it to work and having it lying around on your desk for a while might actually help when the time comes to renegotiate your salary. On the other hand, I have had some first hand experience with COBOL and I am sure that 15000 (US$?) is not worth the pain. My memory of COBOL is even worse than Visual Basic (the original one, not VB.NET, I don't know the latter).

One of my former coworkers started to call herself the Little Indian (she was of Indian descend and really tiny) after she heard one of the developers talking about little endian vs. big endian format. Somehow it didn't get old, we had a laugh every time she said that (the reason possibly was that we were drunk most of the time, playing Total Annihilation after office hours) Those were the days ...

You are aware that you are talking about 10th of a percent, aren't you? I doubt that that is even statistically relevant.

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.