Uwe Raabe

See my comment to Atanas: https://community.idera.com/developer-tools/b/blog/posts/from-the-gm-new-updates-and-changes-to-the-registration-bumps-policy?CommentId=7816b564-c240-4ad1-ad95-a79bdacd479c

I checked the German license and there is no such thing that would a) mention any registration limit in the first place or b) state that increasing that limit is actually part of the support.

I am not sure they would get away with that - at least here in Germany. As long as the customer actually paid for the perpetual license (this excludes the CE), the ability to use it legally cannot be prohibited just because there is no current support contract. At least a reasonable fee for the registration bump would perhaps be acceptable, but definitely not denying it completely.

I have made good experiences with Kassl: OPC FOR DELPHI The latest version also supports OPC UA, although I for myself had only used the older OPC DA components using DCOM up to now.

That was exactly what wanted to suggest, but missed to mention clearly. Thanks for jumping in. Yep, that is exactly what I do here. And be it just for clearness.

That only changes the perception of the problem, not its existence.

I have to disagree with that conclusion. Whenever I encounter a form with a tab control I consider breaking it up into the form with only the tab control (and the common controls around it) and have the different tab sheets extracted to individual frames. IMHO that is much easier to maintain than 1 form alone. Just imagine a group of developers each one working on one tab content. Given that breaking complex forms up into smaller parts reduces dependencies and is way better to maintain, I would never go and glue different forms together into one.

Currently there is no way to disable themes on a per control basis that I know of.

Result := ASource.Replace('\n', #10).Replace('\t', #9); Perhaps not the fastest approach, but pretty simple:.

We actually have Off-Topic here: https://en.delphipraxis.net/forum/17-offtopic/

When you hover the mouse over the users avatar you get a popup containing an option to ignore that user.

@Attila Kovacs Lucky guy! All those things you rate valuable to pay for you now get for free. Much better than getting some gimmick for free that you never asked for and probably has no value for your either.

If you are not actually interested in the key itself, but only in the fact that the editor content has changed, you might get away with EditorViewModified.

An event is always declared as procedure(...) of object, which carry an invisible self parameter. This allows object methods, but excludes global procedure(...) and reference to procedure(...) declarations as well as anonymous methods, because they all lack that self parameter.

Especially as one cannot override virtual methods in a class helper.

Well, I don't see that flicker, but there definitely is a significant delay before the dialog opens. The flickering can be related to the actual form content that has to be loaded, so it might differ between projects.

Perhaps Add to Repository needs to open all pas and dfm files of the project first. That is backed by the observation that closing that project after that needs significantly more time than usual.

Indeed - and DelphiStyles has shown to be a competent and reliable partner for that. Highly recommended!

Why don't you just try the evaluation version?

Ini files lack proper structure support and MMX settings rely heavily on structure. For the purpose of your main question XML files would do pretty well - and not easy to edit is seen more as a feature here.

I actually think the same! Unfortunately it cannot be changed that easy. There are several places with registry access which have to be taken care of. Even the splitting in MMX and Shared, which have their roots in the common code between ModelMaker and ModelMaker Code Explorer, are a bit clumsy. Also it will not going to be an INI file because of the hierarchical structure of the settings tree. I will probably choose XML. Don't expect that soon, though.

For the adventurous of you there is a new download for a MMX Beta version: MMX Beta Setup (current build is 2287) You won't find many new features. The main work was removing unneeded stuff, making use of things not available in older Delphi versions and reorganizing the code. So be prepared to find areas where I accidentally broke something. I would appreciate if you send bugs as email to support@mmx-delphi.de - that way they are automatically added to the bugtracker and are less likely to be forgotten. Feel free to also discuss them here, but even then send that email, so I don't have to duplicate it by hand. Currently there is only one new feature: The MMX Project Options settings have a new check box "Auto Format". If this is checked MMX will execute a format uses clause command every time it adds a new unit to the uses clause. Obviously this only works when the Group and sort uses option is enabled in the Sorting section. Unless something prohibits me to do so, I will announce new builds in this thread.

Funny thing is that those toolbars are originally meant for beginners. Long time users usually prefer working with keyboard shortcuts. Also f.i. filtering members by kind and visibility with the filter buttons is probably easier and faster than using the context menu. It may be pretty hard to find a balance between scaring some new user with too much possibilities and boring them with too little. I am not sure whether I prefer to answer the question "How can I hide that?" or perhaps never being asked "Can it do this or that?". There are quite a number of people saying they cannot work without MMX (me included) after working with it for a while. I know there are others who never get beyond this point. They either will miss something or MMX is not the right tool for them. You cannot please everyone.

Noted!

Well, that can be taken care of. When the amount is reached and the icons are ready I can ask the designer to split the bill into a commercial and a private part. For the commercial part my commercial ego can provide invoices to the companies requesting one. Thus the cost will balance out the revenue on my side. Of course this also holds true for single person shops (I just figured out that the term One-Man-Shop is probably not gender neutral). My initial idea was to find a single sponsor to take care of the complete cost and thus can be billed directly, but the number of icons and thus the total amount turned out to be a bit more than I expected.