David Heffernan

1 hour ago, Fr0sT.Brutal said:

It strongly depends on list size, number of items to delete and, of course, the <T> itself. If <T> is not a simple type, f.ex., a big record with lots of managed fields, assigning could take ages. However, on pretty large lists this could be the only acceptable option as internal array realloc would exhaust available memory.

You don't understand. Moving an item to the end leads to all items between that point and the end being moved down.

It's perfectly possible to implement this without a realloc and without the dire performance traits of your chosen method. And if your array is huge and push the boundaries of available memory as you suggest, then your algorithm is unspeakably dire. 

23 minutes ago, Fr0sT.Brutal said:

If the list is not sorted, probably the fastest option is to move items to be deleted to the end of the list by exchanging and then trim the list. This way only one memory reallocation happens. Depending on list length and available memory size, maybe creating a new list and copying only needed items to it would be quicker. Anyway, you really should benchmark this action first

No, that is not fastest. It can be done with at most N item moves where N is the final coun of the list. 

7 hours ago, PeterPanettone said:

Did you get this from a book or is this your own idea?

I doub you'll find a single book written in the past 25 years that would advocate nesting over early return.

All the most respected experts agree on this and have done for years. 

Which books are you reading? 

We are all given a finite time here. Why would we spend it optimising something that wasn't a bottleneck. 

Imagine measuring, identifying the bottleneck, optimising, and the observing real discernible performance benefits? How great does that feel? 

Conversely, imagine expending time on work that yields no benefit. And worse, you likely end up with code that is harder to read and maintain. Usually this just results in bugs. Think of it, you spend valuable time making your program worse. You may as well just go to the pub and leave the code alone. You have a good time, and your program is better. Win win. 

What evidence do you have that this task is a bottleneck? 

On 12/13/2019 at 11:27 PM, timfrost said:

Without managing the global library path, a package manager would not work for me.  I cannot think of any library we use that is not used by multiple Delphi projects; in some cases dozens.  So no project search path is ever used or needed.  Are you targeting just the type of development shop which builds only one or two huge applications?  But don't pay too much attention to this comment, because as I have said before I am very happy using a Finalbuilder project as a DPM.

In my world I need to build against multiple different versions of the same library. This is not an obscure requirement. It happens pretty much anytime you maintain development and release branches. When you maintain legacy versions. This is a mainstream scenario in any professional programming setup. 

Global settings are simply incompatible with that.

Actually, I think that might be right, there is a section in the map file that lists the units in the order they are initialized. 

Also, there are tons of questions on this topic on SO. 

2 hours ago, Mike Torrettinni said:

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

I do, sometimes, use overloaded methods.

You are simply not going to learn anything by asking people to tell you how the decisions to make when they don't have the necessary information to make them. You need to understand concepts but you just seem to ask us to tell you what to do in a specific case. 

I don't think an answer to that question will help you. 

Parsing the detailed map file is probably the easiest way to do this is a large project.

If you know you have dependencies on initialization order, I'd solve the problem by removing those dependencies. 

It's not an effective way to learn. A really good book is what you need. In my opinion. 

10 hours ago, Mike Torrettinni said:

Which is kind of moving the logic from the called method into the callers... right?

No. The caller has to tell the callee what to do. The callee needs to get the information from somewhere.

I wonder, do you have any good books on software design? I really don't think this sort of question has proved fruitful. 

Window text is simple an attribute owned by the window. Programs can do what they want with it. Top level windows typically display it in the caption. Edit controls display it as the text to be edited. 

It not the caption. Its the window text. By default the system uses that text as the caption, but it is possible to have windows with no caption, that do have window text. 

Read the documentation. It's the text of the window. Documentation is always the first port of call. Don't guess. 

You talk about the name of the application. Well, an application name isn't something well defined in programing terms. There may be conventions that the executable file has a name that matches what you think of the application name. But nothing enforces that. You need to decide on the right way to identify your process.

If you try to kill windows with the class name TMainForm then there will be collateral damage. You'll kill my program's main window! 

So, try to work out how to robustly identify your process. 

If the methods perform the same task, use overloads. What you have here looks like it should definitely use overloads. 

This would suggest that there is no to level window whose text is MyTestApp

9 hours ago, aehimself said:

This is actually a really good idea. Call the .EXE's and dock their window into your application, like a new tabsheet. And until the clients are happy, you can work on the refactoring 🙂

Actually it's a really bad idea. Cross process window parenting relationships just don't work out. Don't even think about it. 

The error message tells you that you are supplying more arguments to a function call than expected. 

Look at the declaration of the function in question. Look at the list of parameters. Look at the arguments you pass. Where is the mismatch? 

10 hours ago, Remy Lebeau said:

Nor could it anyway, because the Owner may not be a TWinControl at all.

Well, it easily could if it would use runtime type testing, the is operator. My framework does it this way. 

It's a shame you don't have enough time to do this. 

The version without the owner leaks. 

Potentially there could be issues with popup parent also. Which form do you want to be the popup parent? Although I could be wrong on that one. I'm not sure that the framework looks at the component owner to determine the popup parent in auto mode. 

3 hours ago, Mark Williams said:

I don't have any experience with Office plugins. I thought about it at the time and it looked difficult and I seem to remember there were certain things I thought I would be unable to do using a plugin. I considered having a look at Add-in Express, but I'm keen to avoid reliance on third party tools as far as possible. I think I'll have a look at it and see if it can do what I want.

 

AddIn express is superb

I wouldn't feel very confident about my chances of making this design work. Personally I'd be looking for a different solution. 

18 minutes ago, dummzeuch said:

Am I missing something?

No.