Mike Torrettinni

Thanks, but devexpress has long learning curve, not suitable for my patience. But, I assume this was a suggestion to go with single form. no matter how controls are organized, either with devexpress control or tab control, right? Finally someone in my corner 🙂

I agree! And that is why I'm annoyed every time I need to maintain those Search forms... and I know I will be dealing with them for years to come. That's why idea of a single pas and dfm file is very intriguing, in this case.

Maybe I'm struck with beginner's 'enthusiasm' on refactoring... and I look for something to refactor at every step. 🙂

You have a point there, but I'm a sole developer on this project, so I don't have this problem.

Yes, I agree, it's hard to imagine without detailed description. I hope screenshots give more information. I actually have one search form with a few more controls. I'm not looking for Yes/No suggestions, but more like advice (concrete or general) how to deal with this.

Here is example of 3 Search forms (I have 10 very similar), each searches (and locates lines) on different data (TArray) right on the main screen Virtual Treeview control. So, this is 3 (10) different pas and dfm files. Even if I have BaseSearch with Title and Search, Close buttons, I still need to derive each of these 3 forms as 3 different pas and dfm files. What if I have 1 Common Search form that has PageControl with Tabs for each search type, and OnShow I show Tab that is needed. My assumptions: - 1 pas and 1 dfm file - easier to maintain - OnCreate will take a bit longer, but opening a Search form doesn't need to be instnat, so 50ms vs 200ms should not be a big deal for first time opening a form - design time is there - so no blindly creating controls with code 🙂 - I will need to setup some properties to control which Tab is opened, something like: CommonSearchForm.SetSearchType(stActions); before calling .Show (which will control how form appears and behaves) I appreciate the suggestions, but TTaskDialog is not suitable for such cases. What do you think of this CommonSearch form idea?

I'm not too fond of Vista dialogs, they seem very rigid, not flexible enough to fit in the software design. Sounds good, but does it lower the number of individual Forms? All you do is inherit common design, but you still need to design each individual form, right? For example I have 10 different searches for 10 different data types. And some searches are just on text, which can be combined into same Form, then some searches need 1-5 checkbox to indicate search areas/date ranges and such... and then some searches lookup combo boxes to select search areas. So, all very similar things, but slight difference. Would I need to have 1 Base Search form and then 10 inherited forms for each search type? Seems like overkill... compared to 1 form with 10 Tabs (or less, is possible), for each search type. No?

I just wanted to share that after 15+years of Delphi, today I used repeat until for the first time! 🙂 I scanned my code and in all 100Ks of lines of code not once I used it on my own (I did find it in some methods that I'm not original writer). Actually feels good, as I never found the real use for it, always just For or While. And the reason I used it is because I had a simple loop for which I wasn't sure when it will end, so I didn't think about all conditions - which would be the case to use While loop and pre-setting all conditions at the beginning. So, here is my first real use case for repeat until: // Add Parents in reversed order repeat Result := [aNode.ParentNode] + Result; aNode := aNode.Parent; until (aNode.ParentNode = nil) or (aNode.ParentNode.NodeType = ntDocument) or (aNode.ParentNode.NodeLevel = 0); Here I was allowed to add conditions at the end, since I didn't know all of them at the beginning. And it became this beauty of 4 lines 🙂 Happy day! 🙂

Great job at CrossVCL! Is that some Facebook tracking in your links? the second link goes to: ... l.facebook.com/l.php?u=https%3A%2F%2Fwww.ksdev.com%2F%3Ffbclid%3DIwAR2BG3Ox1005Z64KJjp4vHGcg5aISwaADsx4QltGkU8Ahvnkx5KDsEsmpRo&h=AT06YbrsLwHA6cUGJMRaR7YAgrfvdOGCKQg_2cqbJspYjh5JnZka4ktqKpHmnceLIPQvAlwfUJSzAXo7dtAcutGRKGkaAloSCGdt_OLpAg-Zxn5oOj6xAktkVmM5D3mDD-xQM4eL0ah3p89RNQW784JhHsaR0F0imKWuuFhN3--8yIBIiclPHBxz-8Sz2eIEM4FnqA4kLc_DQ0yWjtYqjEr6aA62XtTlMndfLYDliAQ5JdYFh3_u1RrT71pCsRSaj0C-Dv8KaQOdV0aX76fzaBeSMXsN96BZX9jUfUHfIO_Xdyjs7i5Cg-dgWTbmYJrewME_VTpPvhWzFhAqv0o1mn8bfHrN0NW3_7hVJBKUuR0JfrJAJIyXsWFFJJ8Goqc1DPidaTtk4HMFmOwT0ha4KwSt_e2WD7e1mf9pjIQln0uB6cV-WFxB3LYmT7PCMW06dl1zhqPQFtpxxZhJJJMVyCOy58CVNYy0us8lpVWtGY4_ZJUYRnkBYAp29ACC2DtIZ2CNbBk_xdzxaeVmfSefc88f6ZGMNuPZF9bsqocK1y0EKZsPaQKk1vT177rgzsustIvXCJDayJKKZwfFEZYBxLvZr1SS50v5GHytqq6oHRw-ybC0fgAEcP9-cFsWdPDj6RsW6Iq1wQRqE0jWPd6H I don't get it... what's the benefit?

Thank you guys, some good advises and comments that made me think! Not sure what I will do, but good to know some other options. Never considered options like load file, close and then parse. or keeping file open for all operations.. checking, identifying, parsing... new stuff 🙂 Not sure if usable for my current case, but interesting idea. Will remember. The simple way - that's how I'm doing now, except I was having all those If FileExists checks at every step. I think it was more because I wasn't sure or thought of the whole process, but refactoring large methods and then ended up with unnecessary checks. I did start noticing some over-refactoring... 🙂

That is definitely different that what I would... I try to open and close files as fast as possible, but maybe this is not such a bad idea. So, i lock the file and use it until I don't need it anymore. Which could actually work, because files are in 99% local files.

This makes sense, I guess. Not what I'm used to.

Well, all my methods have checks for invalid parameter values, nil pointers or integer<0 or empty strings... so, I'm kind of used to not relying on callers to pass always proper parameters. In this case to rely that file exists (as caller checked), goes against my experience... but maybe it's time this changes.

Valid point!

Even though this project is Windows based only, you never know. Didn't think about this... constant file checking could prove a bit over to the top when accessing network files, potentially slow.

Did anybody encounter a very slow PgUp from the bottom to the top of the TVirtualStringTree? I have 200K+ lines and PgDn from the top scrolls fast. But then I go to the bottom and try PgUp and is really slow... if it's all virtual, why is it slow? I recorded a video on Demo example that comes with Virtual Treeview installation - to make sure it's not my code, and it has the same problem. If anybody is interested, the video is less than 1 min and you will see the difference from PgDn scrolling from the top and PgUp scrolling from the bottom. Well, it's screencast, so it looses some frames, but the difference is noticeable. In this demo I just changed RootNodeCount to 100000. Is there something I can do to improve this? https://drive.google.com/open?id=1DtFHXLrux0Gnap7DMchlqg0ez8mxoU5k Delphi 10.2 VTVersion = '7.0.0';

I tried using ProDelphi to see which method uses most time in VirtualTrees.pas and the ones that do are related to Cache... so you are right, definitely something to do with memory access. Still doesn't make sense, but I guess it's one of those 'accept it and let it go' features/behaviors.☹️

Thanks! You think it's Virtual treeveiw's fault, since it scrolls OK from top to bottom, and not from bottom to up?

Thanks, I'm glad I'm not going crazy! 🙂 or that I need new PC... Did you notice this issue only when running code in FormCreate and not in Button1 click?

If anybody would be so kind to take 2 minutes to see if the behavior is replicated, I would appreciate any feedback! I attached a simle project with this behavior. 1. See commented lines in FormCreate, so no array created: - run and scroll down with PgDn... see it goes fast, now jump to the end (cltr+end) and scroll up with PgUp... also fast. OK! 2. Now uncomment code in FormCreate and do the same.. you will see PgUp from the bottom is not fast as PgDn from the top, anymore! 3. Comment the code in FormCreate, run project and now click Button1 to execute same code as in FormCreate... you will see PgUp is again fast as PgDn! Delphi 10.2 Virtualtree View 7.2.1 PgUp scrolling.zip

Thanks, but things are getting even stranger... I restarted my computer and demo project got better. Then I created a new project and reproduced behavior and then I started commenting out and now I have this very odd situation: If I use this code in FormCreate - it slows down the PgUp scrolling... and if I use it in Button click, it doesn't! SetLength(TestArray, 1000000); for i := Low(TestArray) to High(TestArray) do begin TestArray[i].Text := 'Text ' + inttostr(i); TestArray[i].Text2 := 'Text2 ' + inttostr(i); end; And I don't use this TestArray at all, I just fill up the data and nothing else. The Virtual Treeview is not connected to this array at all. The definition: TTestRec = record Text: string; Text2: string; end; var TestArray: TArray<TTestRec>; It could be my system memory is corrupt or dying, because this makes absolutely no sense and I wasted the whole day on this... very frustrating. It feels like I'm going crazy.... If anybody has any idea, I would appreciate any advice! Thanks!

Thanks for suggestion, but the results are the same. Strange, annoying. Maybe it needs descending index defined, as we had to do decades ago on some databases for scrolling descending to work 🙂

I don't set NodeHeight, so just fixed DefaultNodeHeight = 19.

Yes... but this time it was a small function so all checks for valid values were already done and just quick loop was needed. I don't even know why I chose Repeat, but it worked out really well. I just hope I will not get too excited and try to force it instead of While 🙂

I do the same, use Exit a lot of times to exit quickly with result, no matter what type, boolean, string and integer.