Mike Torrettinni

OK, I must say that I started using Pred() more and more and I must say I like it, more and more. I re-read the comments above, but I have to say it really looks like High for arrays. I don't see it exotic anymore. This makes sense: for i := 0 to High(aArray) do for i := Low(aArray) to High(aArray) do for i := 0 to Pred(aList.Count) do Reading some comments again was interesting, so if using Pred() means I will never go beyond Delphi beginner level, so be it 🙂

Not me, but it would be nice to hear from anybody who is affected by this change - but you can already see different interpretations of Marco's comment in just a few posts here. I don't see any big change for v7 licensees, they just might be more frequently targeted by email to upgrade, or even charged for download. Expecting any service to work the same (unchanged) after 20 years is a bit over the top, no?

I have a feature that spans across a few frames and few units. And I have CommonProjectDefinitions.pas where all types and common methods are defined. One of the common types is main data type: TProjectDataType = (dtItems, dtInvoices, dtUsers, dtDocuments, ...); Now I have a MainForm that ads a few Frames as Project data views and each has it's own TProjectDataType. If I want for MainForm to know what datatype each Frame is, I need to use CommonProjectDefinitions.pas in MainForm, Because only the TProjectDataType is used by MainForm (and eventually probably some other units), is this way OK (to expose the whole common unit) or it makes more sense to have CommonProjectDefinitions_Public.pas where all common types that are also used by other forms are defined - so I end up with CommonProjectDefinitions_Public.pas and CommonProjectDefinitions_Internal.pas (which contains everything that doesn't need to be Public). The main concern is to have neatly enclosed units and not everything exposed. Any suggestions or experience what to do in such case?

Thanks guys! This was great exercise, a lot of pen and paper to draw out how it should all come together. I have 14 frames, a few Callback functions between them, MainForm is cleaner and doesn't know about frames, so less units exposed. Worked out very well! I even figured how to 'detect' which frame has been refreshed, to focus on correct Tab in PageControl, simple boolean return. This was one of the hardest things, to design classes that are independent, but still have connected hierarchy. I will probably need a few more exercise like this to fully use all the power of classes. I think that is what I have, I just didn't follow those tutorials about Factories, because reading those examples is like reading about Interfaces... all alien to me, at this moment 🙂

Thanks, will have a look!

OK, this makes sense. Let me try. thanks!

for example: If MainForm has 2 frames, Project list and User list - same class/frame, different TProjectDataType... and different actions refresh different frame, something like this: if aAction = actRefreshProjects then for i := 1 to n do if fFrames[i].ProjectDatatype = dtProjList then fFrames[i].Refresh; if aAction = actRefreshUsers then for i := 1 to n do if fFrames[i].ProjectDatatype = dtUsers then fFrames[i].Refresh; In this case MainForm needs to know about TProjectDataType - so it has to use a unit where it is defined. How can I hide TProjectDataType from MainForm?

I noticed this function in gnugettext: function _(const szMsgId: MsgIdString): TranslatedUnicodeString; It seems you can name the methods with just underscore, or even multiple of them: procedure _; procedure ______; Is there any situation when this might trigger some unexpected issues? Wow, Delphi world 🙂

So my first attempt with classes structuring in separate units was very successful. Very good separation of logic and presentation details, classes, inheritance, some poly-thingy probably and other... in multiple units. Nice and good. Happy. Now, 2 weeks later, I started a new feature and I said OK, let me review and see how I did it then, to start similar concept: Open main Form -> that feature is added as a Frame -> open Frame... aha, no code coupled with Controls, so I have no idea what is shown anywhere -> I want to see how I present data in one of the Virtual Treeviews -> I remember I used name something like 'presentation layer', where all data is 'pushed' to controls, so lets look for it -> Frame only uses main data class, in data unit, ok go there -> open main data unit -> search for 'presentation'.. found TPresentationLayer -> open presentation unit -> browse through TPresentationLayer class in presentation layer unit -> find OnGetText for Virtual Treeview, not the right one... browse through the next 2 OnGetText methods... aha: finally found the Array and what is presented in selected Virtual Treeview. I don't get it. At the time of implementing the feature it looked great, everything structured, nice, but I knew where everything was because I was working on the feature. 2 weeks later and it's like it's been 10 years, I'm looking where data is defined, where enums are used and how, where is Array filled, processed and the displayed. Luckily Ctrl+Click works very well so I can jump back and forth through units, if this wasn't working... I can't imagine. What am I doing wrong, did I do 'too much' separation of logic and UI? Do I have bad memory that I can't remember details of 6 small units for a feature, after 2 weeks? How do you deal with this, how do you find out later on what is where and all the details? Any advice appreciated, even though you can't see my code.

Great! Everyday something new 🙂

With each iteration I learn something new and which way is appropriate for which implementation. It's fun 🙂

I'm gaining experience, with the mistakes and failures on the way. Rome wasn't built in a day. It shouldn't, but it gives me a little comfort knowing not everybody is perfect and I'm not the only one having odd 'relationship' with the documentation.

When I started with that feature, I had an idea that it would be really easy to plug'n'play other features (I guess like a little framework), but eventually it ended up so customized for specific feature, otherwise I could still be working on it and refactor minor details. I can't wait to get there 🙂 So, I guess you guys are saying documentation and comments and refactoring, there is nothing else that could help with understanding the code at later date.

I would say I'm Delphi rookie, so this "heavy multi-threading apps on machines with many CPUs as the memory manager does much less block or serializes the worker threads. E.g. using TParallel"is like sci-fi to me, but if the demos are going to be available for single cpu machines, and no need for in-depth analysis of results to understand them, I would be happy to run a few and be impressed.

I tried it in my project, single threaded project, high memory consumption. Tried all optimization options, no improvements over FastMM4. FastMM was a huge improvement over Delphi's memory manager in D2006, for my project, so I'm happy @Pierre le Riche made it available!

What do you mean?

I'm looking at this simple example to scroll 2 Scroll boxes at the same time: hhttps://stackoverflow.com/a/17788516/5198394 If I click just 1x on scrollbar button to scroll down on Scrollbox1 , why is message WM_VSCROLL 'executed' twice? If I debug the method: procedure TScrollBox.WMVScroll(var Message: TWMVScroll); begin inherited; if Assigned(FOnScrollVert) then FOnScrollVert(Self); end; the Self is Scrollbox1 in both calls: Each Scrollbox has 2 oversized panels so that scrollbars are visible from the start: Any ideas why is VMVScroll method called twice? How to prevent it? Shouldn't 1 click on scrollbar button send 1 WM_VSCROLL or WM_HSCROLL message?

Thank you, tried, but it doesn't improve the flicker, jittering effect of moving controls when scrolling fast. Learned something new today! 🙂

Thanks, will look into it.

I have up to 4 scroll boxes with a few controls in each scroll box and a few controls outside scroll boxes that are aligned, and need to reposition on each scroll. So, on each scroll message, a lot of calculations and repainting is done.

Yes, I solved it by checking if scroll has actually occurred and not assuming that if FOnScrollVert is executed it automatically means the scrollbar has moved. Not a problem, just annoying that OnScroll is execute also when no-scroll 🙂

Yes, I think you missed my final solution where I use it.

Sorry, thank you trying.

Thanks @Attila Kovacs, but your example doesn't prevent executing 2x the line: Form8.ScrollBox2.Dispatch(msg)

The problem is that method assigned to FOnScrollVert is called 2x. So, the code in the method had to be wrapped with IF's that determine if scroll has occurred - to limit the flicker. The method was originally not designed to be executed 2x for 1 scrolled line.