Mike Torrettinni

I have a simple splash screen and I kind of think it should have an icon in taskbar, before Main form is shown. Right? I just tested a simple example with new project and new form, and icon is not displayed - as you can see the splash screen form does open in taskbar, but without an icon. When main form is shown, the icon is there: So, fresh new project with empty Form1 and empty Form 5. I can add source, but really only Project.dpr is changed, all the rest are empty forms. Here is project source: program Project1; uses Vcl.Forms, System.SysUtils, Unit1 in 'Unit1.pas' {Form1}, Unit5 in 'Unit5.pas' {Form5}; {$R *.res} begin Form5 := TForm5.Create(nil); Form5.Show; Application.Initialize; Application.CreateForm(TForm1, Form1); sleep(5000); Form5.Free; Application.Run; end. Is that normal for splash form to not show icon in taskbar? Any suggestions to fix this?

Great, thanks! Will re-check in Delphi 10.4.

Thank you, but I should have been more clear with the details: I use Delphi 10.2.3 and I thought only inline variables needed changing. Perhaps there are other incompatibilities, even if it compiles OK. I will try again, when I upgrade Delphi (probably 10.4). And yes, /strings="String A, StringB,StringC, String D and E"' should get a single parameter value. I chose your parser to try based on simple cmd switch definition: CmdSwitch: TSysCharSet = ['-', '+', '/']; Others have this in code. Will it work with '--'? Like: --strings="String A, StringB,StringC, String D and E"

I would appreciate any suggestions on how to improve or make this easier: I have quite complicated (nested) data structure to find references. For example: // this is just example type TSubSubSubItem = record ID: integer; Name: string; Disabled: boolean; Amount: integer; OrdersNo: string; end; TSubSubItem = record ID: integer; Name: string; SubSubSubItems: TList<TSubSubSubItem>; end; TSubItem = record ID: integer; Name: string; SubSubItems: TList<TSubSubItem>; end; TMainData = record ID: integer; SubItemsA, SubItemsB: TList<TSubItem>; end; var MainData: TList<TMainData>; And if I want to find all Disabled SubSubSubItems, this is how I would do it: procedure FindAllDisabled(var aDisabledItems: TList<...>); var i, j, k, l: Integer; begin for i := 0 to MainData.Count - 1 do if MainData[i].SubItemsA <> nil then for j := 0 to MainData[i].SubItemsA.Count - 1 do if MainData[i].SubItemsA[j].SubSubItems <> nil then for k := 0 to MainData[i].SubItemsA[j].SubSubItems.Count - 1 do if MainData[i].SubItemsA[j].SubSubItems[k].SubSubSubItems <> nil then for l := 0 to MainData[i].SubItemsA[j].SubSubItems[k].SubSubSubItems.Count - 1 do if MainData[i].SubItemsA[j].SubSubItems[k].SubSubSubItems[l].Disabled then // save record and all parents to disabled record end; This method will return all Disabled SubSubSubItems. If I then need all SubSubSubItems with Amount > 0, I would set new method or use the same and combine last IF with parameter to eother search Disabled or Amount > 0. This is very simple example, I have a real life cases where Disabled property can be at any nested level from 2-6. This is becoming very complex and unreadable and repeated similar For loops. Any suggestions how I can simplify search of values in nested record? The problem is that for each found item, I need full 'parent tree', so I can report to users where in details this item is found.

No, any recommendations? I don't have time to read now, but I can put in on my ToRead list, or at least Amazon Wish list. I follow this rule for another example, but that is a lot less complicated and is more for presentation layer. For complex structure, I can't see that far, yet.

What do you mean, the tree like structure (nested records) or my last example?

OK, I think I got it now! New concept to me. Just wanted to show you how I have solved similar concept in the past: I would have no nested record, but I would have (similar to DB) a separate Array for each record, so the TSubSubSubItem would be: TSubSubSubItem = record // key or location info MainDataID: integer; SubItemID: integer; SubSubItemID: integer; SubSubSubItemID: integer; // SubSubSub item details Disabled: boolean; Amount: integer; OrdersNo: string; end; var AllSubSubSubItems : TArray<TSubSubSubItem>; And in this case I just find all Disabled items and get all references by Key details. Easy, but the list is separated and Key has to be maintained. While 'nested' or tree like structure, is strict. And with data in separate arrays I can access directly any item - I can't do that in tree structure.

OK, this is for when you have Parent and Child list, and Result = Disabled Child list, for a Parent (like Andreas class). How would that work if it is like my example, where I need to to know for each Disabled Item, all the Parents and Parent.Parent and Parent.Parent.Parent?

Aha, thanks, I think now I better understand his suggestion.

Maybe 'nesting' is not the right word, but the structure of records than can only be accessed by through Parent records... or can I just access directly SubSubSubItems of MainData.ID = 1 and SubItemsA.ID = 12 and SubSubItems.Id=2? Is there another word for this, instead of nested records?

I think database is another layer that I don't need at this point. And as far as I know you can't nest records, right? They would be separate tables with keys - this defeats the nested records benefits.

Do you often use Overloaded methods or you try to avoid them? I keep getting into this dilemma, especially because I want to use Overload instead of unique method names, but eventually overloaded methods become too complex. For example: Let's say we have TaskScheduler class and it needs methods to add tasks, and here how it started: TTaskAction = (taNa, taExecuteNow, taExecuteDelayed, taQueueTaskOnly...); procedure AddTask(aAction: TTaskAction; aTask: TTask); overload; // Execute aTask immeditaly procedure AddTask(aAction: TTaskAction; aTask: TTask; aExecDateTime: TDateTime; aAllowImmediateExec: boolean); overload; // Execute aTask at set date time procedure AddTask(aAction: TTaskAction; aTask: TTask; aQueueOnly: boolean); overload; // Put aTask to Queue and wait for execution this looks good, but as soon as you start adding more info for each TTaskAction, it become a mess because some parameters get passed empty, depending on which TTaskAction is being used for. This is easy solved if I use AddImmediateTask, AddDelayedTask and AddTaskToQueue methods. Then no mess. Any recommendations how to approach this or should I just use overloaded methods for very simple cases?

The comment was more about the value of this site, of course very subjective. Your experience can be different. (maybe that's the reason for difference of level of our expertise 🙂 )

That's why I love this site, where open ended questions are allowed and I always get some more value than just simple answer or solution. There is no book that will give me that much value with different answers, different real solutions and comments, suggestions.

I had a debate with another self-employed Delphi developer on how to prioritize feature requests. Of course the major factors are: customer (revenue from them), critical issue/bug, how many developers it might affect... so it is very easy to select important, high priority tickets, requests. But the interesting was part about non-critical, suggestions, wishes... do you still put a few of them on list for every release, or you keep putting them at the end of the priority list and they never get implemented. The debate started when he sent me that one of his feature requests for the 'Tool' was to display tool version - the tool doesn't have it displayed on the screen, but you can see it in the file version. So, non-critical, not high priority ticket. He requested it in July 2016,and he just got an email it was implemented in Dec, 2019. 3+ years for Tool version? (In the case of this Tool, if you look at the circumstances it's kind of understandable and expected - it's Delphi solution that got acquired, so I guess original developer was squeezed out) I always try to implement even a few such low priority tickets, of course not all - and I only have some very customized feature requests that are years old. My opinion is that you need to put effort also on low priority requests. The lowest on the list are the very customized features that would take a lot of effort to implement, for 1 customer. if anyone wants to add heir view or experience, please do.

@Lars Fosdal I tried your FDC.CommandLine but I'm not getting correct results for this example: parameter: -strings="String A, StringB,StringC, String D and E" I only get value before first space: 'String' when using this: vCMDNew := TCommandLine.Create; vStrings1 := vCMDNew.AsString('strings'); More:

In my case (self-employed) this is actually wanted/needed as it means the customer is engaged and more chance it will be a long time customer.

Now thinking about it, I can admin I treat low priority changes also based on relationship with the customer. More personal relationship can swing the vote. While bigger teams could be flooded with requests (bigger team usually means more customers, more requests), so less personal relationship to affect the vote.

I only have 1 really good usage of overloaded methods example in my projects, and that is IfThen, with a lot of different types of parameters. But these only come with 3 parameters, like: function IfThen(const AValue: boolean; const ATrue: TVirtualStringTree; const AFalse: TVirtualStringTree = nil): TVirtualStringTree; overload; inline; This works great! And then I have example such as: function LogMissingItem( const aProject: integer; const aProjectSection: TProjectSection; const aProjectType: TProjectType; const aItemIdx, aItemDataIdx, aItemXMLID, aItemSubID: integer; const aItemReferencedID, aReferencedXMLID: integer; const aCategoryID: integer = 0; const aSubCategoryID: integer = 0; const aProjParameters: boolean = false; const aProjID: integer = 0; const aItemProp: string = ''; const aItemSubProp: integer = 0; const aProjSubID: integer = 0): boolean; And LogMissingItem is called for 10+ cases of data, and a lot of parameters are 0s on empty strings, because not every parameter is applicable to every Project Item Log entry. So, I can now create numerous overloaded LogMissingItem methods, but I think in this cases I will actually implement @Der schöne Günther example, with record as parameter. Much better use case,

If with ITask you are suggestion similar as @Der schöne Günther , then the TTaskAction (taQueueTaskOnly) is part/property of ITask. Then it could be even simpler AddTask(ITask), right?

Yes, I was trying to decide if I should use overloaded methods no matter how complicated parameters are, or just use unique names.

OK, I assume you don't use overloaded methods. Which is good answer for me.

@David Heffernan In your experience, even if the methods do perform same tasks, is there a limit when you don't overload them? Like too many different parameters, like in my case? Or maybe you decide on other criteria...

Aha, yes, correct! In one of my cases I have to prep some data from other arrays to define record to pass as parameter. Which is not really a logic, so I was thinking of this. It probably doesn't seem useful to you as it is to a developer of my level... every feedback is usually a lot more valuable than direct answer to a problem. I can see how other developers do it, suggestions how I might do it in the future, or sometimes I just combine from different developers.

This is interesting approach, it could work on some methods where I have 10+ parameters and then half of the calls pas string and integer values, while the pother half passes '' or 0. This just means I need to create/prepare record before the call. Which is kind of moving the logic from the called method into the callers... right?