Mike Torrettinni

Oh, I didn't think this could be a Windows thing.. I have Windows 10. I tried and now I get 2 taskbar buttons and no icons:

I use Delphi 10.2 update 3. Does this apply to my version?

Good to know, thanks!

I guess in this case this is exactly what I'm doing, trying to fit this into a class but probably I don't need to. But all the suggestions above gave me some value of what to do, what not to do and when I create next class, how to structure it. Much better than those Car classes in tutorials.

Hm, not sure what you are asking here, but I looked into some of my utility methods, that get called lot... very few checking, mostly to do with when 0 means no-value or 0 is valid value. I do not use Assert, I do know that could be a flaw, but nothing really too much in a sense of verifying if proper parameters are being passed. And when index to another array is passed, I check the validity (>=0 and <=High(array)).

I think I'm so reluctant to use classes, because I don't really have the typical need for them... all tutorials trying to explain the usage with basic examples of inheritance of TCar class and it's details... I just can't relate to anything I use. Except for encapsulation, but I already do this as shown in my 2nd example above, where everything is in record and it's unit. Not perfect, but the way I understand and know how to use it. So, I'm not going to ask for good book or tutorial on classes, because they all contain such basic examples that I get lost in trying to relate to what I need... like everybody is either making control components or doing some kind of Car related projects. @David Schwartz said it best: " I mean, you're going through a lot of gyrations simply to avoid using classes. " I guess I'm stuck in my world 🙂

In previous thread David said: " Don't use a global variable for each form. Remove them. Use a local variable and destroy it when ShowModal returns. " So, good practice is to create Forms as needed and destroy after closing. But are there any cases where this practice doesn't apply? I have numerous forms, some are just custom dialog boxes, with a few controls, some are settings forms, where up to 50+ settings can be set (label + edit + tabs). Especially for these Settings related screens, the logic says: create once, use for the life of application and all the values that developer set once, will be there until closing. So, why would I need to recreate every time someone looks at settings, and go through the whole procedure of filling up the settings on the screen, translating the screen local language (if needed)... and so on. So, I thought maybe it's the memory consumption. With my quick test of around 60 forms, here is the memory consumption: Creating all forms at start: Creating only Main form at start: At least for my case, the difference in memory consumption is negligible. I'm just trying to understand a bit more, before I start changing everything for the sake of 'good practice'.

Yes, it takes longest, about 6s to open a project and main form to appear and is ready. Other projects are much faster, but 6s opening project is not something I'm concerned about. It's more a concern that it takes FormCreate 0.5s, which is a bit too long, but still not a real concern, at this moment. Imagine... could it take only 1h-2h to split each tab into a Form.., then test and fix little issues... around 4h per tab? x50 = 200h... I don't see how I can squeeze 200h into current timeline, at this moment. Unless you have a suggestion how to do it 1 day or 2?

I'm just trying to organize all my mess of 100s of globals into units, records... even if they are still global records, at least they are organized, in 1 place, and hopefully better for Error insight and Code completion. My current project(s) are slowly going from 'full RAD on steroids' stage (most of the code was in control events) to refactored, better organized, easier maintainable... projects. I have a few simple classes, but nothing like this one in this topic, so any help for 'pre-OOP' developer, is most helpful 🙂 So, thank you for pointing out the constructor point, I do understand a bit better, now. I can't be the only one who dislikes creating, freeing classes...

Thanks @Uwe Raabe! I will need some time to process this.

To speed up the opening of my project, I want to only create forms when needed. So, I commented out all CreateForm in Project source, except for Main form. And now when I need to open a form, I use: if Form2 = nil then Application.CreateForm(TForm2, Form2); Form2.ShowModal; this works good.. but, now I have this code all over the Main form unit. Is it possible to have a common method like AccessForm(Form2, True); that would do this code in a method, for all forms: procedure AccessForm(aForm: TForm; aModal: boolean); begin if aForm = nil then Application.CreateForm(aForm, ??? TForm... ??? ); // <-- how to determine what type aForm is? if aModal then aForm.ShowModal else aForm.Show; end; // open Form AccessForm(Form2, True); Is something like this possible? If yes, how I can find out what class a Form is, even before is created?

I'm probably not the best to judge quality coding practices, so I'm not... but! if Embarcadero was a one developer company, yes, understandable IDE would be screaming... but, this is 2019 and Embarcadero is not one man company. IDE should let us know what is it's problem so we can address it by changing the structure of code if needed, 'screaming' is the worst.

Of course, all manually. Except for obscure cases, I haven't had the need to create controls on the fly - IMHO this goes against Delphi RAD... of course, each feature/report on it's own Tab control and over the years it grew to 50+ tabs (features/reports). Do you create Forms, controls on the fly? For what benefit, what is real life scenario?

I just couldn't make it work with var parameter, it kept giving me : E2033 Types of actual and formal var parameters must be identical So, I changed into a function: function AccessForm2(aForm: TForm; aClass: TFormClass; aModal: Boolean = True): TForm; begin if not Assigned(aForm) then Result := aClass.Create(Application) else Result := aForm; Assert(Assigned(Result)); // just in case :-) if aModal then Result.ShowModal else Result.Show; end; and I call it with: Form2 := AccessForm2(Form2, TForm2, True) as TForm2; Seems a bit complicated... am I doing something wrong?

Yes, but it has(had) it's benefits for my case, I could set all default values directly on the forms, which was great.. until now, when I had to separate UI and logic. So, the form creation always needs to read these settings and set the controls, every time the form is created. This is where I still have dilema between constanlty generating form, or maybe find the most common used ones and have these as globals, and the rest as local create, use, destroy Form type.

No... it's actually very simple (looks wise) reporting tool, but organized into 50+ separate tabs (features) on page control(s). So, not cluttered, but all on Main form... I only use Frames for 1 feature. I like to have all in 1 place, I guess.

This makes sense! I do have a lot of of controls in my whole application. And now some of the issues, odd errors pointing at controls code which I was never able to replicate and fix... could makes some sense. If ComponentCount shows count of Main form controls, then I have 3000+ controls(components) on Main form... on various page controls. Not sure if this is a lot or not.

Well, this whole thing started with moving settings into their own container. Then I started looking into startup time. For some reason my startup time was 8s, after a couple of days of blaming creating all Forms on start, I figured out it was exception handling tool, removing it saved me 5s - the different one doesn't add any time to startup. So, while all these big changes, I needed a quick solution to delay creating Forms, which was actually not the cause of delayed startup. But now I'm here, so can't go back and need to find a middle ground of what I used to do, what I know now, what will eventually be and the most important what I can do now in short time for best results and not breaking anything 🙂

Thanks. I never used that option, always changing this in project source.

How do I open a form with this approach?

Nice, this is better. Is it possible to do this somehow without Form class? I assume not, since we can't get Form's class, if it's nil (not created yet), right?

I'm looking for general suggestion on how to deal with this problem: I have array of Project: TProject = record ID: integer; Name, Description: string; Active, HasSubProject: boolean; WorkHours: integer; ... end; Projects: TArray<TProject>; It has 50+ fields. Now I need a lot of different information about projects, based on criteria on fields. For example count all Active project, or Count all Projects with WorkHours >= 200, or list all Projects with HasSubProjects... So, basically a lot of For loops in different methods, used in different units. The problem I always face is that when adding new Field, like International: boolean flag which affects all my For loops, how to make sure I don't forget to use it in one of my existing For loops. I always search where Projects are used and modify all For loops as needed, but I noticed I can miss some For loops, especially when IDE doesn't always find the usage in all units. And then I have For loop that is not current anymore. So, one of the idea is to have ONLY 1 For loop for Projects and add all criteria needed with If statements, so I will have 1 For loop to maintain - it will be a lot of IFs, but at only 1 place. Is this good design? Any other suggestions how you deal with this?

Yes, that is part of my years long project refactoring. And now Projects array is what I'm working on, so I noticed a lot of methods (non duplicated) that return information (counts, lists, exist/not exist,,,) based on different criteria. So a lot of For loops on the same array.

Thank you, interesting suggestions. Never heard of Specification Patterns, seems like something I can do for next big data container. Probably doesn't make sense for current Projects as it completely changes everything. @Attila Kovacs: are you referring to the same thing, Specification patterns? @PeterBelow Yes, this could be next step, to organize all methods related to Projects into single unit, I guess into a class, like your example. This will keep all my For loops in one place. And when change is needed, I can quickly browse through methods and see For loops. @Dmitriy M I think this is overkill, using any kind of SQL engine for my needs. I don't really see benefit of writing sql statements over For loops - at the end it is a method you call. Right? @David Heffernan Yes, I have numerous methods like CountActiveProjects(), IsProjectActive(), ListActiveProjects... well, each only one, but they are all over the project, as I need different information on different screens, in different units.

Hi this is very basic question, but it does bother me sometimes since it is how I commonly use this, but I see others don't: I commonly use the assignment of local variables in methods with parameters like this - assuming all values are simple data types: if ParamaterValue <> None then localVar := ParameterValue else localVar := DefaultValue; but I see often usage like this: localVar := DefaultValue; if ParamaterValue <> None then localVar := ParameterValue; Is this just a personal preference or is there anything I can't see in 2nd example that is 'better' over my example?