Leaderboard

Unfortunately not even good and reliable descriptions on how to reproduce the bug and even suggestions on how to fix them don't always get it fixed. I sometimes wonder whether they use some random number algorithm to select the bugs to be fixed.

You SHOULD already be able to have per-project packages, in all versions of Delphi. The trick is to install the packages but NOT ENABLE them globally. With no project loaded, install the packages as needed, and then disable them so they don't appear in the Palettes when no project is loaded. Then, load a project, enable only the installed packages it actually needs, and close the project. Repeat as needed for other projects. Then, from now on, the IDE should load and unload packages on a per-project basis. At least, this is how it used to work years ago, I haven't tried it in recent years. Hopefully it still works.

Strictly speaking assuming a specific order in a for-in loop is wrong to begin with.

@jbg thank you for the confirmation. I less and less understand Emb. This "new" IDE is so slow, flicker everywhere... Did they use their software? They should focus on quality rather than getting us such half backed solutions...

New LMD 2019.3 installers are available now! The complete VCL package includes more than 750 VCL components including popular packages like LMD DockingPack and LMD DialogPack (Delphi/C++Builder 6 and better). Main changes of this service release are further Rio 10.3 IDE support, extensive BarPack improvements and high dpi bugfixes for DockingPack. Review changes of this release on history page:http://wiki.lmd.de/index.php/LMD_2019_-_History Find summary of all changes in LMD 2019 on What's New Page:http://wiki.lmd.de/index.php/LMD_VCL_2019_-_NewsCheck the new trials and compiled Exe-Demos athttps://www.lmd.de/downloads For example the LMD DockingPack demo:http://files.lmd.de/downloads/lmd2017vcl/DockingPack_Demo.zipTo learn more about other LMD products visit the General Product Page:https://www.lmd.de/products/vcl/lmdvclAll products are based on LMD 2019 platform. For more info about LMD 2019 platform checkhttp://wiki.lmd.de/index.php/LMD_VCL_-_DescriptionFeature Matrix of all LMD VCL products:https://www.lmd.de/feature-matrixIf you are interested in purchasing check out the Order Page:http://www.lmd.de/shopping If any questions are left, please contact us at mail@lmdsupport.com!

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.

That is actually the best way to get the problem ignored...ignoring it on the user side. I wonder which demi gods promoted their bug reports because there seems to be quite some fixing done. Keep in mind, that concise instructions to reproduce an issue may work wonders. They are our peers and great minds think alike. Good bug reports yield fixes. Yada yada yada...

I showed this during EKON last year. Unfortunately I couldn't find the time working on it again. It heavily lacks documentation, but perhaps it can serve as a start. https://bitbucket.org/uweraabe/codecoveragemagician

I have a certificate issued by Comodo and let Inno Setup take care of it. As also covered in the blog post linked above, if you obtain a timestamp from a trusted party (special server) when signing, the signature will remain valid. For me the most useful resource was this: https://www.zabkat.com/blog/code-signing-sha1-armageddon.htm.

If we just had some easy to use and nicely integrated into the IDE way to measure code coverage ...

I know I go on about this but it's really important, in my view, to stress that the testing framework doesn't discover the bugs. It's the developer that writes good tests that discover the bugs. You need a testing framework to help manage the test code. But the strength of the test is always the quality of the test code rather than the framework. There are plenty of libraries that ostensibly have test suites but are full of bugs because the test suites are incomplete.

Among a few minor things it allows for a more declarative approach of writing tests by using attributes to provide the test data. In a classic DUnit test if you have to test an algorithm with 20 different value combinations you need to write 20 tests (either as different methods or by putting them into one test). However DUnit can be pimped to allow the same so you don't need to migrate (*) - since DUnit is kinda abandoned development wise Vincent decided to roll his own library instead of modifying and possibly cleaning up the code from DUnit which dates way back. (*) I did that way back even before DUnitX existed: https://stackoverflow.com/a/9006662/587106 and later also put that into a unit of Spring4D. As you can see in the screenshot you have multiple tests shown although there is only one method declared the extension takes care of producing them so you can run them individually (if for example certain data produces a failure) while you are fixing it. Another thing (which personally never bothered me much) is that with DUnitX you can write testcase classes without inheriting from a base class (this can also be done with an extension for DUnit - did it but never put it anywhere because it was not useful for me). The last thing that I remember is the fact that DUnitX can do is have fixture setup/teardown - they only run once even if there are multiple tests in the class - classic DUnit runs Setup/TearDown methods before and after every single test - guess what? You can also plug that onto DUnit. My personal opinion: do automated unit tests but it does not matter what framework you are using. I use DUnit with the before mentioned extensions and we do so at work because its powerful and compact. And regardless which one you are using - use them with TestInsight and make them part of your CI. 😉

If you can still reproduce it, you should dispute the resolution with detailed steps to reproduce.

Declared: TEnum = (plough, foo, bar, wtf) Test order: [wtf, plough, bar, foo] Looping an Enum Set 1 wtf 5 plough 9 foo 14 bar Looping an Enum Array 1 wtf 5 plough 14 bar 9 foo Press Enter: You are right, @Stefan Glienke -I am so logging off now 😄

AFAIK you cannot inline declare an array in a for in loop so having some elements in between square brackets will always be a set. You can see it in your very own code on your blog article where you had to put them into an array variable first to then process them in the loop. The point I agree with though is that the fact that sets and arrays share its syntax might be confusing sometimes.

No I would not because its not a list but a set which are implemented as bitmask and thus have a fixed order.

It is my experience that issues with the installation are usually targeted quickly. I know what you mean, but if we stop filing bug reports to notify them about existing stuff not working they will have more time to add unwanted features. Even if the chances for a filed bug to be fixed are pretty low, they are still higher than those for a bug not filed at all. After all 10.3.1 fixes more than 150 reported bugs, which were probably still not fixed if they weren't be reported in the first place.

The DLL's documentation includes VB declarations. VB doesn't support cdecl at all, only stdcall. Also, I just found this, which clearly shows the DLL functions using CALLBACK for the calling convention. That is a preprocessor macro that maps to __stdcall.

Perhaps people tend to prefer talking about things that don't work.

IDE no longer flickers when you compile/build 😃 Probably the most important fixes and improvements are in iOS platform - including fix for compiling/linking 3rd party libraries against iOS 12 SDK. And then there is a bunch of bug fixes in other areas. So plenty of improvements, just not big ones. Or depends how you look at it, if your code was affected, then even single small fix can be great improvement.

You show decimal representation while version components correspond to nibbles of hex representation 11264dec = $2C00, so your version number is 2.12.0.0 (2.$C.0.0)

I'm here!

We've been using SVN for many years now, no complaints. We're however planning to migrate to Git at some point, and are already using it in parallel with SVN in several ways. It is perhaps worth it to note that from a size efficiency perspective Git is much more efficient than SVN. The total size of a git repo + working copy files (which remember, includes all the branches and the entire history of the project locally) is typically quite a bit smaller than an SVN checkout (which only contains the working copy and a copy of the pristine files of a single branch with no history.) So any history investigation or switching between branches requires a connection to the remote SVN server, whereas Git does not require this and allows complete freedom to switch branches, create new ones and interrogate the histories offline. This is extremely useful when you want to do some types of work where a connection to your central version control system is not available. To also note: It is entirely possible to use both version control systems sort of independently at the same time, by making each ignore the other's folders. This has benefits as it starts making the notion of "I have a local repository that I can work against" apart from "the remote" clearer. E.g. commit whatever you like, in as small baby steps as you like against your own development git repo, and once ready commit to your "mainline" SVN repo. Meanwhile when upstream updates happen you get practice in merging and learning how to do this properly using git. Eventually this sets you up to simply swap the step that commits to SVN to pushing to a remote Git repo instead. It is also possible to keep a git repo as part of your SVN repo, if needed/wanted/useful. For example, we use and keep third party sources in a dedicated third party SVN repository, and in several cases for ease of updating to ("pulling in") the latest version of the open source project and to have access to the history of these projects, the path of least resistance was to actually commit the git repo into our Subversion repo. To update then is simply a case of pulling from the repo on github, checking if the update breaks anything and then commiting both the source changes and the changes to the git repo to subversion. (One more addition: Another department actually also use Bazaar, it works well but I'd not recommend it as it's essentially dead in terms of development, and the plan is to eventually migrate that to git too. For clients we use the Tortoise* tools.)

On a totally unrelated matter I would like to direct your attention to a completely underrated feature of Delphi: LiveBlame - in the IDE! This however works with hg,git and Subversion. But I just love this! I love to put blame on others, and then find out it was my fault after all! 😄

So that it is also ignored as all the other high voted bug reports, that will probably never be fixed? It seems to be more important to add unwanted features than to get the existing stuff working.