Mike Torrettinni

Thanks, don't remember last time I saw this.

GPF?

I agree! Not really blaming... I just wanted to show to anybody else who is struggling with TList<T> or any other part of Delphi language, that they aren't alone and is perfectly fine to use the tools that we are used to... not everybody can be an expert in everything. Some things we conquer faster, some slower 🙂

Eh, I just got some unexplained nil pointers and exceptions... and debugger kept hiding value of TList variables, never had so much hassle with TArray. So I converted all code from TList<T> back to TArray<T>, I will keep TList<T> for just simple cases. Well, I tried.

Exactly! I'm sticking with TArray for VST data 🙂 But I do use TList<T> for some other parts of data processing, so not all is lost with my learning time with TList<T>.

OK, so any kind of assignment can't be done directly to TList<T>, always through the temporary variable? Now all the benefits of TList vs TArray (like simple .Add without SetLength) don't seem worth the hassle... To work with VSTs, I need to manipulate data, either correctly set Level for hierarchy, or prepare text for OnGetText (for speed)... or attach some other values to works with VSTs.. I guess TArray will work for me for now. Thanks @Remy Lebeau!

Is there an option to find out if another process is running 'as admin', with elevated rights? My project doesn't run as admin by default, so WM_COPYDATA doesn't work when the other application (which I have no control over) runs as admin. So I would like to check and if it does, to show message "Other application running with elevated rights, close your project and check 'Run as Administrator' and run again"... I was sure this is quite common task, but search didn't provide anything useful, except for plenty of suggestions on how to find if my own process runs with elevated rights. But I need to know for the other process, application. Delphi 10.2.

I have a situation where a parsing component (non visual) is not available for Delphi 10.3, and I don't have access to the sources - I have dcu files. If I want to move the project to 10.3, I see these options: - replace parsing component (couldn't find any comparable component that is up to date) - wrap parsing functionality into DLL and use in the 10.3 project - write my own replacement - probably 3 weeks of dev time (would span across several months as is not a priority) - this means delayed moving to 10.3 I like the DLL option, but the client is not too happy about it as they don't want to have additional external files for deployment. Are there any other options?

Thank you @David Heffernan, I managed to put the check together... but while testing, it became obvious that there are many more things involved with elevated privileges (multiple levels, the current user, the process owner/user...). So, since in 99% cases the cause for my issue will be that the other process is running with higher privileges than mine, I will just assume this is the cause when error occurs and let user run my project as admin. I'm OK with this, for now.

I think they are realizing the dll option is not that bad.

This is interesting... quick search on this topic gives show some challenges with antivirus and anti malware software. I assume with right approach, this should be a non-issue, right?

I'm getting only very limited information about the situation with this component, but seems like the sources were like 10x of the component price, which at the time of purchasing was not approved, or something similar.

Yes, similar thing, it would be a lot of trial and error to replicate the parsing engine, so I thought DLL would be just fin for now. Was there any significant performance penalty or not noticeable?

Oh, yes, sorry. The full project is in Delphi 7, they have prototypes ready in 10.2 (where the parsing components is available), but want to move all to 10.3 now. If they move to newer version, they want to move to newest Delphi version. I was only tasked for this component and it is only small part of the whole project... so not enough to stop the whole move.

I saw a phrase 'implementation detail' and I'm not sure what is meant, and why is it better then the 'other' (non-implementation) option... in this question: https://stackoverflow.com/questions/52015619/how-to-change-tvirtualstringtree-node-icon-when-that-node-is-expanded the comments say that checking if Node is expanded is better checked as: Sender.Expanded[Node] and not vsExpanded in Node.States First one is supposed to be 'implementation details', which is 'preferred' over the other option. I don't understand the meaning and the purpose, the main class can be defined in both, implementation and/or interface section of unit. I would appreciate if someone can make some sense of this, for non-expert Delphi developers. Thanks!

That's not true, and not helpful. The function can return anyrhing it likes. No reason where there has to be a field anywhere whose value is returned. @David Heffernan and @David Schwartz: are you both talking about the same thing, just different verbiage and details?

Yes, that's how I understand it should be. Thanks for clarification, it is new world for me, and every little step is like new world is opening... some parts are easier to understand than others.

Thanks, yes that is my understanding now. I hope my conclusions, in a post above yours, are correct, or at least going in right direction. Accessing implementation details, methods instead of class fields directly, also allows overriding/extending methods into my own Expanded method - while overriding/extending States field you can't.

Thanks, I think I got it. So to prevent leaking implementation: - all class fields should be accessed through property read/write or methods, so make all fields Private - " What matters is how many steps the client code must take in order to make the class do something useful for the client. If it's more than 1, it's a smell, and might be a sign of an implementation detail leaking out. " - I probably need more experience with classes to have this down to single method/property call And in the example above, the second example accesses States field directly, which is leaking implementation details. Of course, I have 'vsSelected/vsExpanded in Node.States' everywhere in my project :) Oh, I had no idea that implementation detail is a real technical term, so didn't even think about searching for it. Thanks!

I wasn't sure how to give better title... I didn't know about array[TInfoType] of construct, until this morning. So, this is how I usually use enum types and assign string names: type TInfoType = (itProject, itContacts, itWorker, itWorkers); const cProjectNodeName: string = 'project'; cContactsNodeName: string = 'contacts_info'; cWorkerNodeName: string = 'WRK'; cWorkersNodeName: string = 'WRKS'; ... function GetInfoTypeNodeName(const aInfoType: TInfoType): string; begin case aInfoType of itProject: Result := cProjectNodeName; itContacts: Result := cContactsNodeName ; itWorker: Result := cWorkerNodeName; itWorkers: Result := cWorkersNodeName; end; end; And I just noticed I can actually use const array[TInfoType] like this: type TInfoType = (itProject, itContacts, itWorker, itWorkers); const cInfoTypeNodeNames: array[TInfoType] of string = ('project', 'contacts_info', 'WRK', 'WRKS'); ... function GetInfoTypeNodeName2(const aInfoType: TInfoType): string; begin Result := cInfoTypeNodeNames[aInfoType]; end; And this looks so much better, and the compiler complains when strings don't match the number of items in TInfoType. Great! But I can't find documentation of array[type] of construct and I'm worried that I'm getting too excited and will find out of limitation just when I change everything to this new const type. I know it's hard for anybody to guess how this will be used in my code, but in general are there any major limitations of array[type] of construct that I should be aware of? Anybody has any gotchas to point out? Thanks!

Thanks, I understand now! Good to know.

Interesting, all new to me.

Thanks! Yes, I never assign values to enums - well, at least I didn't have the need, yet, so all good. Well, this all started when I wanted to have enum type connected with string value... I wanted simple solution, even though I saw some complicated class and record implementations... I need something I understand and can use right away. And this combination of type and const array[type] is awesome, because I can keep the definitions together in the code, and it also handles a bit of checking - it complains when enum items number and string numbers are not the same, so I can't forget to define one.

Hm, probably we are not referring to the same thing... this is what I meant and it compiles OK: cInfoTypeNodeNames2: array[0..3] of string = ('project', 'contacts_info', 'WRK', 'WRKS'); What are you referring to?

Thanks, I know about array [1..100] of type but didn't connect this two together. So, in my case where I have 4 items in type TInfoType: cInfoTypeNodeNames: array[TInfoType] of string = ('project', 'contacts_info', 'WRK', 'WRKS'); actually means/translates into: cInfoTypeNodeNames: array[0..3] of string = ('project', 'contacts_info', 'WRK', 'WRKS'); Correct?