dummzeuch

If I want to get the topmost element of a stack (System.Generics.Collections.TStack<T>), without removing it, I use TStack<T>.Peek. Is there any way to get the second to topmost element? I looked at the sources and found none, so the only way I could come up with is: TopElement := MyStack.Pop; SecondElement := MyStack.Peek; // <== I want this one MyStack.Push(TopElement); if SecondElement = SearchedForElement then begin // ... end; Alternatively I would settle for a way to check whether the stack contains a given element: if MyStack.Contains(SearchedForElement) then begin // ... end; But there doesn't seem to be such a method either. Is there maybe a different container for that?

I was about to answer, but have decided that it is pointless to keep this thread alive.

Please let's agree to disagree. My solution works for my specific problem and is easy to understand. It's also fast enough for me and since there is no multithreading involved temporarily changing the stack doesn't matter. Quality does indeed matter, but only as far as it makes any difference to the problem at hand. This is basically a throw away program which I hope I will never have to use again (yeah, right, dream on).

I do that all the time. When you start another IDE instance, you should get a warning dialog, telling you about that. That dialog can be turned off. I don't know how stable this is with Delphi 11.2 thought, as I don't really use that version. Your best bet is to compile your own DLL and try if that solves your problem.

Yeah, that's me. Ok, the problem seems to be that I'm unable to ask the question so people understand it. Sorry for that, maybe I should stick with the German forum. What I wanted to know is if there is an easier way to get to the second topmost item than the one I described in my original post. The answer to that seems to be "No", as far as I understand it. So I've put those 3 lines of code into a function and live with it.

So basically, the answer is "No".

Yeah. I've been there: "It's simple, I'll write my own". [writes his own, overlooks a corner case and then takes 5 hours to find that bloody bug] No. As I wrote: (emphasis mine)

I don't want random access to the complete stack, just to the second to topmost entry. And for that I have got a solution that works but is clunky. Since I have only recently begun to use the generics that come with the RTL (Yes, I'm late to the party), I was hoping I might have overlooked something like TStack<T>.Peek(_IndexFromTop: integer): T. Apparently there isn't.

That's one option, yes, but then I would have to implement the stack functionality myself.

TStack<T> does not have a List property (at least in Delphi 10.2)

I can declare a method parameter of some interface type and pass any class to it that implements the methods that interface defines, independently of any inheritance. If I use an abstract class as type for that parameter, I can only pass classes that descend from that abstract class.

No, that's not the same. To use an abstract class, your implementing class must inherit from it. A pure interface does not require that.

brc32 (part of Delphi) should be able to do that. There are probably quite a few other tools. On the other hand: Why do you need to do that after the exe has finished building? If your files already exist at that point, why not simply add them using the {$R filename.res} directive in the source code?

My problem with interfaces and their implementation in a class is that you have to type everything twice (copy, of course). I wish there was some hybrid kind of class that simply adds reference counting on top of normal class functionality. Basically the compiler could autogenerate an interface declaration for the public methods of a class and modify the constructors to return that interface instead of the class. Hm, didn't we have reference counted classes in the ARC compiler?

If you happen to use dxgettext, there is the assemble tool for that. But given the topic you're posting under, you probably don't use it.

No, but that's in Europe, so you can't compare salaries easily to US salaries, even if you convert EUR to US$. Looks a bit on the low side to me too though, especially for Rome, but I am not that familiar with salaries and cost of living in Italy either.

Which will make it more difficult for us Delphi developers as there will be even more false positives with virus scanners.

And just to be sure: Always close the current project before opening a new one. That should remove the package and then reload it when the new project is opened.

Of course there are several reasons why one would prefer to use ShowMessage: It's a standard dialog form so the user will recognise it immediately and know how to use it If the user skins his Windows installation, the dialog will automatically be skinned too If the way Windows shows these dialogs changes, your own dialog will automatically change too Changing the standard ShowMessage dialog in any way (different font etc.) will negate these advantages. The same applies to building a custom form. Having said that: I too have created a dialog that replaces ShowMessage. The main reason was that I wanted to center that dialog on the parent form (or at least the main form) rather than the current monitor. (If anybody is interested: It's in w_dzDialog, which is part of my dzlib.)

Now close the window and save the desktop again.

Actually that might be due to the IDE rereading the desktop when you open a new project. Did you save the desktop after you placed the Grep Result window? (It works fine for me in Delphi 2007, XE2 and 10.2. I don't use Delphi 11.)

It would also be nice if you posted feature requests and bug reports to SourceForge.

Sounds like a use case for GExperts Grep for the current file. Not quite as convenient as the functionality you describe, but certainly workable.

Hm, while I agree in principle that features requests should be posted to the right place, I think you did not realize this is the GExperts sub forum, because SourceForge does not have a voting functionality. (And I totally missed this topic until you and Lars commented on it which kind of enforces your point.)

There is a limit to how many parameters can be passed in registers (faster) vs. on the stack. But that limit also depends on the parameter type and apart from really time critical code you should simply ignore this possible issue, because other considerations are far more important.