Mike Torrettinni

Yes, I guess this is how scroll messaging works, when pressing on scroll button: 1. Scroll line down (button pressed) 2. End scroll (button released) Which is probably fine for most applications, but I synchronize 3 or 4 scroll boxes at the same time and it was executing custom scroll 2x. So, annoying for anything that is customized, but I guess it is the right way. So, now I have: procedure TScrollBox.WMVScroll(var Message: TWMVScroll); begin inherited; if Message.ScrollCode <> SB_ENDSCROLL then if Assigned(FOnScrollVert) then FOnScrollVert(Self); end; Until better solution comes along 🙂

I can make it not execute MyScrollVert twice, with a check if VertScrollBar.Position has changed after inherited: procedure TScrollBox.WMVScroll(var Message: TWMVScroll); begin fScrollPrevPos := Self.VertScrollBar.Position; inherited; if fScrollPrevPos <> Self.VertScrollBar.Position then if Assigned(FOnScrollVert) then FOnScrollVert(Self); end; but this is just a fix on something I don't know how to prevent in first place.

I have my own very simple licensing system, web activation, offline activation via browser. License determines full or eval (time limited) mode of software. Very basic, has been working good for many years. If I had to do it again, I would try and save time with one of ready-made solution, if they fit the needs.

I believe that my first projects accounted for 10% of world-wide AVs 🙂 Though, none of them corrupted any systems, disks, crashes... and no lawyers involved. I would not choose your security measures, but it is interesting approach.

This is interesting... If my software doesn't find correct license info (for whatever reason), I just revert to limited (evaluation) mode. Did you try something like that and you realized it is not good enough? I'm just trying to figure out if my solution is actually not good enough and I just don't know it...

Captcha or similar options could avoid the need for developers requesting and you managing passwords. Maybe save you some time and developers don't need to wait for access. But if you need controlled access, then captcha is out.

Doesn't captcha or similar options prevent this?

True, interesting it wasn't caught in code review before release.

If you are referring to: http://docwiki.embarcadero.com/Libraries/Tokyo/en/System.Concat then yes, I know it, but I prefer string1+string2, when needed concatenation. Why?

I did a quick look at some of the big component sources and you can actually find Pred() usage quite often. You can see some pas files use both options, Pred() and Count - 1. which I assume is due to different developers being involved. But this one is interesting: if Idx > pred(FItems.Count - 1) then and no comments. Since the same method already uses Pred(), I assume someone didn't like Count-1 and they changed it half way. 🙂

Yes, of course, make sense. Unless you use 'open in new window' option for each resource you want monitored live data. I tested similar option, too. With good results. Thanks, I have to put this on hold for a little while, so when I get back to it, I will see what implementation will be suitable.

I need to make it on top of the form that calls it - so it 'blocks' the original form from user access, until message form is closed. Would you suggestion work like this?

Well, idea was to have modal window over the non-modal form that needs attention from user (either to refresh the info, close or do something else that needs user attention/intervention). So, what would modal custom form be different than modal message window? It would still block all other forms, right?

You mean this, right? : for num := 0 to Pred(list.Count) do list[num]:=list[num] + '123'; 🙂

I only rarely use for-in, perhaps I should try using it more often. I only use it for enums, I never thought you can use it for TList, even though it makes sense. Good thread @John Kouraklis , good ideas coming out of this! 🙂

I use High with Arrays, Pred I saw in example with List.Count example. I see High used with Arrays very often, but not every body is using it, of course. Years ago I had a custom checker that would check for Length(Array) that is missing -1... lot's of fun, before I started using High 🙂

I've been thinking about this a lot lately: when you achieve 'expert' level and all your code is using classes, UI and logic is split, utility units are nice and organized, no or very little global variables... so, a 'perfect' code, when do you have a need to refactor your code? In last few years I've been refactoring my code, getting rid of global variables, started using classes, organizing units with methods by common purpose, trying to split logic and UI, optimized for performance, and so on. Often I think about if I would learn this from the beginning, would I ever need to do any refactoring at all? I would like to understand examples of how Delphi experts improve their code, what else can you do or learn that is beyond 'the right way to program'.

Well, I have different experience. For a long time i didn't know about High(Array) and dealing with a lot of arrays, i had occasions forgetting -1 in Length(Array) -1, so High(Array) is, for me, excellent replacement.

You don't use Pred(List.Count), you don't think is useful?

I just saw noticed this (or recognized what it is) in sample code, for the first time! Pretty cool, can replace StringList.Count - 1, like High(Array) replaces Length(Array) - 1. @John Kouraklis let's see what else I can figure out a 1.5 years later than you 🙂

I have customized INI file, so need my own record structure. So I have: TINIRec = record Section, Key, Value: string; IsSectionHeader: boolean; ... end; And I have ComparedData array that contains pointer to TINIRec: TComparedData = record PointerRecType: TRecType; // this identifies RecPointer as TINIRec RecPointer: Pointer; // Pointer to TINIRec ... end; ComparedData = TArray<TComparedData> So, when ComparedData is filled with correct data from INI file, I access the content like this: if ComparedData[x].RecPointer <> nil then IsINILineAHeaderLine := TINIRec(ComparedData[x].RecPointer^).IsSectionHeader; Of course the check for nil pointer has to be everywhere... So, if I set a record function like this I can avoid checking for nil record: TComparedData = record PointerRecType: TRecType; // this identifies RecPointer as TINIRec RecPointer: Pointer; // Pointer to TINIRec ... function IsSectionHeaderLine: boolean; end; function TComparedData.IsSectionHeaderLine: boolean; begin Result := false; if RecPointer <> nil then Result := TINIRec(RecPointer^).IsSectionHeader; end; and the call without checking for nil pointer: IsINILineAHeaderLine := ComparedData[x].IsSectionHeader; Is this a bad way to deal with pointers? Can this case issues later on, unexpected?

@dummzeuch I'm not sure what you are thinking here... classes instead of records? How can I use defined different classes that Pointer will point to?

Thank you, I think you very clearly explained that I need experience. I'm on my first steps with classes, the more I use them the more experience I will have, the more I will know what to do - I'm not even close to your CLEARLY. I can read 100s of articles on Inheritance over composition, still practice is something else. For now, I'm in a phase of making mistakes 🙂

It's on a horizon... still a little to go 🙂

Thank you for detailed explanation, I guess I'm trying to fit something into a class hierarchy, that is not designed for it. The class inheritance looked pretty good, because I'm dealing with a few different file types, very close to INI, but customized. I was thinking to create a base class and then sub classes for each file type, but they are so different in content, purpose and visual presentation - then there is comparison representation, that is unique to each of them. So, ti was annoying I needed to override 90% of the methods of the base class - it doesn't make sense to have base class at all, then.