Attila Kovacs

@dummzeuch <joke> It's pretty fine to use Delphi's built in Round in a banking application. </joke>

*phew* 🙂

@Uwe Raabe Phuhhh, this is just mapping numbers into an enum. Your helper actually is like the following code, with obfuscated names. I don't think I want to debug such code. It even works on negative values in the list. TEnum = (five, nine, fourteen, thousand) enum.AsInteger := five.AsInteger + nine.AsInteger; if enum = fourteen then begin Writeln('Hooray!'); end There must be a special use-case to do this, I suppose.

try something with dot pitch >= 0.3mm ( <~83DPI ), or a 4K with similar pixel-group size in 200% scaling

I was always pissed because of the property editor and its incapability to helping the work, so I made this extra filter-box. It has a little discomfort as the Property Editor steals the focus on the first click, I'll check what can I do if I find some time. Also, adding/deleting/storing the predefined filters are unimplemented yet. If someone feels the power to get it done, don't hesitate to apply.

@dummzeuch Sorry, I forgot them. As everybody every time... Btw. I just found out that it's not working if the selection is in a popup window like columns of a grid etc... I had no time yet to figure out what the problem is. Maybe you will have more ideas as me..

That's what I was referring to in your previous post https://stackoverflow.com/questions/4950129/delphi-for-in-loop-set-enumeration-order and https://stackoverflow.com/questions/1600575/iterate-through-items-in-an-enumeration-in-delphi

@Tommi Prami Sorry, I'm not touching the property editor at all, so no coloring or any drawing possible. It has a filter interface where I can decide what should be in the list and what not. However, one could easily filter those properties which are declared only in the component class, or in the last 2 classes (TCustomXXX, but I think there are no published properties), or build a tree and select which ones you want to see. So could you have a clear overview of the components own properties. Edit: I made a little test and It's not that useful as I thought: (%'s represent the class depth (parents))

@David Millington Latest version of the API (required units and demos) – no longer available; Bookmarks acquired by Embarcadero. Read more here. What does it mean? I have a plugin which I might want to publish based on these files. What now?

Allegedly nobody has time at EMBT. But what do they do?

I remember having seen a similar screenshot back in g+ but I can't recall what was the problem, perhaps the font. Nope, there is no solution in the post

Is there a way to figure out that the IDE is going to shut down? Possibly before TOTAFileNotification fires.

@dummzeuch The idea is good, but I'm afraid it's too late. Plugins go first. Have to check.

@Rudy Velthuis Yup.

@David Hoyle I was thinking about the same, but, this is a plugin dll for Parnassus Bookmark and I'm not sure that I want to hook it from there... I didn't even look how could I access the main form.

@David Hoyle Thx, I was looking everywhere for this notifier! For now I've switched to TOTAFileNotification, and I'm silent between ofnProjectDesktopSave/ofnActiveProjectChanged and the ofnFileClosing with the filename ending with '.dproj'. Yeah, ugly botching, but I have no other choice at the moment...

@Stéphane Wierzbicki In Berlin everything ok, except I had to use Right-Clicks (the other left :) insted of Left-Clicks 🙂

@Alexander Sviridenkov Cool. I did the same last year with my report generator, html+html report generator in the normal report generator. It's freakin' awesome.

@David Hoyle I'm also getting this event every time I'm closing a file with ctrl-F4. Berlin U2.

@Dave Nottage I want to suppress some editor related dialogs in my plugon on closing the IDE, but I think I've found a way: TOTAFileNotification yields "projectname.$$$" file is going to be closed at first. Not sure what it is, temp file or what, but it seems always to be the first file to close. It's the .groupproj file instead. Also fine I think.

TRttiContext.Free does already something. It kills the RTTI cache which I'm trying to avoid. But go ahead and create/free it every single time if you wish.

I'm still wondering why the plugin API became so lean. Add/Delete/Some events and a readonly Items. To rename a bookmark I have to delete and add a new one which is triggering a bunch of events, mostly arriving too late for being able to flag the internal processing. I suppose this will never change. You had no time and this won't change with the acquire. Too bad.

Like me. It's "created" once at startup to generate the rtti cache and stored in a global variable and never "created" again or "free"'d. Single threaded app.

On the other side, I'm really happy that I had to download the sources to see what he has, and so I have seen a really great trick and the thread became not just a 42424th variable/value capturing rant. However one thing is still not clear for me Lars, if your actual code takes care of freeing the TFoo and TBar instances, how comes that you instantiate them into a local variable in a loop?

I don't want to hijack this thread but this is such a cool example, there is something I can't understand. I have completed it with the corresponding destructors and free's, and it still leaks. Is this an expected leak? Are TFoo and TBar instances stucked? Edit: Okay, this could be also a deficit of the SCCE. Maybe he is managing them in his actual code. Anyway, the trick using an abstract class to passing its method as an anon proc is really great.