Mike Torrettinni

Great! It works: TPanel = class(Vcl.ExtCtrls.TPanel) protected procedure Paint; override; public var OnCustomPaint: TNotifyEvent; procedure CustomPaint(Sender: TObject); // Custom Paint end; procedure TPanel.Paint; begin if Assigned(OnCustomPaint) then OnCustomPaint(Self) else inherited; end; procedure TPanel.CustomPaint(Sender: TObject); var vRect: TRect; vPanel: TPanel; begin vRect := GetClientRect; // Frame panel Canvas.Brush.Color := clSilver; Canvas.FrameRect(vRect); end; procedure TfrmMainForm.Initialize; begin Panel1.OnCustomPaint := Panel1.CustomPaint; Panel2.OnCustomPaint := Panel2.CustomPaint; end;

Aha, I see now. I kind am trying to avoid creating components, I would really like to not do that, if possible.

This looks good, the boolean flag. But this applies to all panels on the form, right? Do you always do that, or you have a way to limit to which panel this applies to?

How do you do that, how do you limit which controls the interposer applies to? Like I did, with a list of controls or similar?

Oh, no, it crashed on first refresh to show a change in repository. Shame.

No, I guess I missed it. I like the checklist at the beginning and what is missing!

I'm a single developer, so the stress test I put on the tool is minimal. I read a lot of bad reviews on it, but for me it works flawlessly. I do remember it looks completely different than what I saw a couple of years ago at the client's site. I use latest version, not sure what that version was.

Thank you all for recommendations! I installed git and tested a few tools - with private github repositories: - TortoiseGit - first one to use, so I was still learning everything, but it was annoying to use with right-click from explorer - Fork - next one I tried, and of course I was impressed by it, compared to TortoiseGit, fast UI, easy to use - SourceTree - feels like copy of Fork, but free - GitKraken - you need to register account with them - skipping - SmartGit - doesn't have an option to recognize repository hosting, others have this option - skipping - Tower - similar to Sourcetree and Fork, but little sluggish, crammed UI For now staying with SourceTree - it's like like Fork, but free.

Thank you, good approach.

Thanks, I don't use it very much, yet. Good to know for the future.

Thanks, I didn't realize it.

Ok, no worries, will try to avoid temporary coupling, as suggested.

Eh, last night I decided to go with 'use fields by default, unless there is a reason for parameters'. I was happy with this, I had a plan. Now, I see different suggestions. 🙂 I only have this implemented in a class that has 100+ methods and I was testing if here is any difference between method using aClassMainData as parameter of fClassMainData field. But I kind of like class methods, for the 'perceived' tidier implementation. Good point. In this case I would definitely rethink what needs to be used. Well, this is getting a little too much, I'm not ready for Interfaces, yet. Classes first. But, isn't solution for temporal coupling just simple checking if class was initialized, if needed data is present? b := TEndpointAddressBuilder.Create; e := b.ToEndpointAddress(); function TEndpointAddressBuilder.ToEndpointAddress: string; begin Result := ''; if fURI <> '' then Result := ConvertURIToEndpointAddress; end; in this case assigning e will not fail in runtime. Right, or am I missing the point of temporal coupling?

That's a good point! I assume a recursion is probably meant here. Not using many of them, but I will be careful.

aha... exception stops the flow and next/upper try...finally/except handles it - outside the current method. OK. I do always use try.. finally, but I thought we are safeguarding the usage of class in case variable is nil, if create fails. Never questioned it, until today 🙂 Now I understand. Thanks!

OK, I understand, make sense. One last thing I'm still struggling with: can Create not actually create class and 'return/ or leave' variable as nil, but it also doesn't raise exception? this is probably not possible, right?

I don't want to imagine anybody sick, weird and diabolic working on Delphi 🙂

As probably many of you, I have some extended or modified/patched 3rd party source code, or RTL. And it differs from project to project, depending on the needs. So, when component is updated I compile project by project to see what needs to be 'patched' or if developers of those components implemented the same features, as my code 'adds/fixes'. I was thinking to copy all extended and overloaded sources, from all projects, to single new project and just compile this project every time I update any of the 3rd party source. Is there better approach? I would like to have a 1 common approach/action to this, so when I update one (or any) of the components, I can verify all the changes that are needed for all the projects, with 1 action. The fact that I have extended, overloaded different parts of the same component for different projects, whatever is needed in that project - is this wrong approach? How do you deal with this?

No, no class helpers of my own.

Aha, I keep mixing class and record helpers. I know how to extend class, not the record. Same for replying to David's comment, I thought he was referring to record helpers.

I don't know if this worked for you in the past, but it never did for me. Same as for TPageControl, you have to create a new page/card, and copy/move all controls from old page/card to new one. I actually use 10.2.3 not 10.4.

Thanks. Whenever I think about these I remember 'you can only have 1 active record helper at a time...' and I stop as I have no idea if that means it will stop other helpers working.

Well, no matter how I extend, patch the source code, I need to verify if all works as it should on every source update. I only 'trust' Delphi's source to be backwards compatible, so no need to check if extended controls work. But, if I need (or want) something changed, I see no reason not to. The benefit of customization outweighs the maintenance. You can't always extend some things, right? Records are one of them... for example: I used to have xml library that had XMLNode.GetAttributeAsInteger, the new (better) xml library doesn't. So, since .ToInteger fails on empty strings, and I prefer using StrToIntDef as little as possible, I just added the new method to the library source. When I update the xml library it will fail on compile of the project that uses new method and I will copy/merge missing method to new source. Or Virtualtreeview - for years I had my own AutoFitColumnWidthIncludingCaption, which was implemented I think in one of the latest updates (this or last year) -so I guess I will not need this patch anymore. I think a blank project, probably named 3rdPartySourceCodeMiantenance, that will reference all changes to all changed sources should be good solution. And every time I update any of the libraries, I will compile this project first and patch as needed - of course verify that the patches are needed. Perhaps I need to rethink my approach to the component developers, perhaps I should be more involved.

I have a project that sometimes I need to control which features, menus are released (enabled) for some customers. For example I have a 'control' section in Project source, like this: // control Main Menus EnableVisioMenu := false; // Customer A EnableDrawingMenu := false; // Customer B // control PopupMenu options EnableCntxt_ImportFromVision := false; // ??? ... So, when I need a special version, I just set the relevant to True and build version for that specific Customer. But the problem is, that once it's build, I don't know exactly which version it is... the project.exe file doesn't have this info. So, unless I run it, I don't know which version it is. How do others control different, customized releases? Any advice how to improve this? I use Delphi 10.2, and I build from IDE.

I'm not used to contacting component developers, except in rare occasions when there is 'interest' on the other side to get to know how I use their source, or some other reason for a contact. Otherwise you get generic response 'will look into it', And it's annoying when they don't want to implement something I suggest 🙂 so I don't bother. But I never considered not using the component, if they don't want to implement something just for me.