Jump to content

dummzeuch

Members
  • Content Count

    1924
  • Joined

  • Last visited

  • Days Won

    67

dummzeuch last won the day on May 22

dummzeuch had the most liked content!

Community Reputation

1102 Excellent

Technical Information

  • Delphi-Version
    Delphi 2007

Recent Profile Visitors

5760 profile views
  1. dummzeuch

    GExperts Toolbar Dark Mode

    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.
  2. 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!
  3. 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.
  4. So does the check for <>nil in .Free
  5. I agree that it is a bug, but exactly because of this the issue can not be ignored.
  6. 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.
  7. 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.
  8. 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).
  9. 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 ...
  10. You are aware that you are talking about 10th of a percent, aren't you? I doubt that that is even statistically relevant.
  11. 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.
  12. dummzeuch

    Left side cannot be assigned to

    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).
  13. dummzeuch

    Left side cannot be assigned to

    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.
  14. dummzeuch

    Left side cannot be assigned to

    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.
  15. dummzeuch

    Left side cannot be assigned to

    ... 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.
×