Jump to content

Leaderboard


Popular Content

Showing content with the highest reputation since 01/22/19 in Posts

  1. 11 points
    Fixed download links: IDEFixPackD103RegDev.7z fastdccD103vDev.7z
  2. 6 points
    We made some changes to the low-level method call ABI in 10.3, which affects both Delphi and C++. This is likely to be invisible to you unless you do something very low-level. It's more visible to you if you use C++, because now an entire class of bugs has been fixed in one go. IMO, whether you use C++ or not, it's very interesting! Info here: https://community.idera.com/developer-tools/b/blog/posts/abi-changes-in-rad-studio-10-3
  3. 6 points
    The attached IDEFixPack development snapshot fixes this TCustomListBox IDEFixPack bug. IDEFixPackD103Reg64.7z
  4. 5 points
    It is never a good idea to increment the size by one. See this blog post: Extending arrays But otherwise: yes, you are being too pedantic. If this is in a tight loop, you might think of profiling which is faster, otherwise, it doesn't really matter. FWIW, I would do it like this (after Delphi XE7, IIRC): NewRecord.SomeField := SomeValue; // etc... MyArray := MyArray + [NewRecord]; No need for SetLength, Len or High
  5. 5 points
    When you eat something, you need to prepare it (maybe cook it, or order it, or unwrap it), then you need to clean up afterwards. When you get in your car to go somewhere, you need to start it up; when you arrive at your destination, you need to shut it off. When you walk into a room, you may need to open the door and perhaps turn on a light; when you leave, you may need to shut the light off and close the door. Most things in life require some kind of setup, then you do something, then you clean up after yourself. Tell me it really bothers you having to deal with this constantly in your life ... or if you're like most people, you don't ever give any of it a second thought. Objects work the same way. The fallacy in your logic (and people who claim to dislike creating and freeing things) is that just because there's nothing named "constructor" or "destructor" that you're not initializing things first and cleaning up afterwards. Variables often need to be initialized and cleaned-up, regardless of their scope. By default, the compiler clears out globals automatically for you by setting them to zero, but it's risky to depend on default behaviours like that from your environment. Constructors are simply methods used for INITIALIZING an object's state. They're usually just a bunch of assignment statements. They may also create other objects required inside of the object. Simple objects that don't inherit from a parent class with a constructor that needs to be called don't need constructors. Destructors are for cleaning up when you're finished using the object. For simple classes, they're often not necessary. But if you allocate anything from the heap within the class, then they're required if you want to avoid memory leaks. However, it's a good practice to always have constructors and destructors defined, even if they're empty. And if they ARE empty, the compiler optimizes them out. The nice thing about them is they're called automatically, unlike your existing code that needs to be called explicitly. So don't tell me you dislike creating things! Classes with constructors and destructors require less code than what you're doing now ... guaranteed. Even if you're working with a bunch global variables, any nontrivial application has code that initializes groups of related variables, and breaks them down when you're finished. One of the biggest hurdles functional programmers need to overcome when learning OOP is that all of those global variables need to be collected into closely-related groups, and those groups are called "classes". Then you move the code that's already there that's used to initialize those variables into the class' constructor, and any code that's already there for cleaning up into the class' destructor. Then you want to hide the variables themselves ("encapsulation") by defining properties so if the underlying implementations change, you don't have to change every single place they're referenced. Trust me ... after you've been using OOP principles correctly for a while, it becomes second-nature, and you'll wonder how you managed to keep your sanity dealing with everything splattered all over the place with no organization whatsoever.
  6. 5 points
    A generic list that doesn't use any heap memory? We show you a couple of ways to create one in our latest blog post! https://blog.grijjy.com/2019/01/25/allocation-free-collections/
  7. 5 points
    For these cases I prefer moving the settings to a separate settings class independent from the settings form. Then I can create and initialize an instance of this settings class at startup, load the settings from some storage and adjust with some command line parameters. Then the settings are available all over the application without having to rely on the settings form creation. I often have the case where I need access to the settings long before the main form is created. This would be hard to achieve using the settings form as the central storage for the settings.
  8. 4 points
    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.
  9. 4 points
    I moved from JEDI VCS (don't laugh) to Git about a year ago and I don't regret it one bit. Git provides me with functionality that's invaluable especially if used with Git Flow. I use SourceTree as recommended above for most of the work (dark theming coming soon to Windows) but it cannot do all the full Git Flow so I've created some Custom Actions for the missing bits or just drop to the command line. If you want to learn more there is a PDF called Git Pro (https://git-scm.com/book/en/v2) which is definitely worth a read.
  10. 4 points
    A new development snapshot of IDEFixPack is available. This fixes the usage of a SSE 4.1 CPU instruction ("ptest") in a code block that only checked for SSE 2. This bug caused older CPUs to throw 0xC000001D "illegal instruction" exception. IDEFixPackD103RegDev.7z fastdccD103vDev.7z
  11. 4 points
    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! 😄
  12. 4 points
    I've let my enterprise subscription expire yesterday. It breaks my heart after two decades of working with Delphi but as many others I just lost all confidence in emba/idera. IMHO complaining but at the same time keep paying ridiculously high subscription fee (compared to other development environments) sends them the wrong message. I'll gladly resubscribe if things turn around or when Delphi eventually gets auctioned off to a better care-taker.
  13. 4 points
    You don't do that - you build the core feature early enough and have it in a state to not have it failing when everything else is based upon it.
  14. 4 points
    What some people call beta is not but rather alpha - a proper beta in my book is software that is feature complete but not completely tested. Now if you call an alpha beta and time it closely to release that just asks for disaster.
  15. 4 points
    I can tell you, if our application was creating all of its gui at startup, hell would freeze over. And your systemresources, too. The ugly thing is, Memory is not what will kill your application. The handle limit will! There is a GDI-handle limit(in addition to others) you'll run into.
  16. 4 points
    It's not about the memory. It's about removing global variables that allow form instances to poke at each other's internals. It's analogous to making fields private rather than public.  Those form variables only exist because in Delphi 1 the designers were trying to ape functionality of VB.
  17. 4 points
    From my experience many don't ... could be that's those that are not directly employees of Embarcadero so then you would be correct again. Those that have enough knowledge are only a few left and they have probably other tasks to do than to review code all day (which is heavily needed given the quality of some of the code written in recent years). And I believe the quality of the code that we don't see (IDE, compiler) is not much better. Open sourcing code alone of course does not solve anything - there are other steps required. Of course not everything is golden with Microsoft but if you look at the quality of .NET core for example you can see how much refactoring goes into that and how things are discussed in public - something that is completely lacking at Embarcadero because the developers don't even openly communicate mostly (which is partially fault of the community which has been very offensive towards them in the past).
  18. 4 points
    Right, I'm looking mostly towardy cross-platform. My main concern is, beside all this ARC yes/no, Inline vars yes/no, Managed records, etc.: ! DONT BREAK MY RUNNING APPS AGAIN ! I know that EMBT makes a great job there integration 5 platforms, but please keep it all consistent. The worst case for me would be that all these nice code experiments causes a lot of extra work for me to build in/out, test, debug such features that I never wanted or needed. I can accept some degree of experimental and improvements, and I'm willing to follow that burden from time to time, but in the last versions had left some kind of chaos behind, and I'm not willing to see completely non-functional apps or app-store rejected apps all the time. Maybe a solution would be to offer beta-versions more often, but on the other hand I don't want to be a permanent beta tester. A good description of the changes and best practices how to handle possible issues would be great before moving to the next version. At least a first place would be to give all the new, alien error messages some really good explanation, especially for the mobile failures. All the exra time I had spent with finding workarounds for some buggy stuff I better don't count, and this even if I use only 10% of the available features on purpose .
  19. 4 points
    There are at least three large components: compiler(s), RTL / component libs and IDE. Having very limited resources (as I guess) one has to concentrate on something to achieve at least visible progress in one of the components. A large group of Delphi users obviously desperately waits for compiler (language/codegen) improvements and additional platforms support. Instead we see tweaking the IDE introducing a lot of glitches/bugs/name it yourself which are obvious even after ten minutes of active usage. Was there any reason to rebuild the Options dialog probably from scratch paying no attention to bottom alignment? Or SDK manager where I could not do anything until I resized the window and saw that there are indeed buttons, invisible at first look? Component toolbar options page has fixed height - why? Every other Delphi version had it adapt to the window height. In previous versions dialogs were carefully aligned, with necessary anchors set. Now it seems that somebody had just quickly thrown a bunch of controls on the form giving no attention to how it would look in reality, and more - nobody bothered to check the result. Toolbars sometimes start to jump around by themselves - I never saw this in any other Delphi version. And so on... I do not doubt that a lot of efforts was put in development, but it looks like they were mostly wasted reinventing the wheel (i.e. modifying IDE breaking it functionality) instead of focusing on, say, compiler. This is a question of targeting the right aim. Or we are starting to see the result of outsourcing the development (when was the core Delphi R&D team fired? A year or two ago?)
  20. 4 points
    You can write it as If ((b and $01) > 0) or ((b and $08) > 0) or ((b and $80) > 0) then ... Or you can create an enumeration and use meaningful names for each bit. type TMyEnum = (mb0, mb1, mb2, mb3, mb4, mb5, mb6, mb7); TMyBits = set of TMyEnum; // = Byte in size function Test: Byte; var mbs: TMyBits; begin mbs := [mb0, mb3, mb7]; Byte(mbs) := $89; // It's equivalent of mbs := [mb0, mb3, mb7]; if mbs * [mb0, mb3, mb7] <> [] then // If one of bit is set ;//... if mbs * [mb0, mb3, mb7] = [mb0, mb3, mb7] then // If all 3 bits are set ;//... if mbs - [mb0, mb3, mb7] = [] then // If no other bits are set ;//... Include(mbs, mb1); // Set 2nd bit mbs := mbs - [mb3, mb7]; // Unset 4th and 8th bit //etc... Result := Byte(mbs); end; It's always better to deal with clearly named typed variables and constants.
  21. 3 points
    @Incus J Using Application.ProcessMessages is not the correct way to test if the GUI is updated in a lengthy process. Put your lengthy operation in a separate thread and add a possibility to cancel it if the GUI detects such a request. Application.ProcessMessages can lead to many hard to find anomalies and program failures.
  22. 3 points
    People have actually asked for blame as a feature, that's why I included it back then in delphisvn (before it became Version Insight). I find it useful myself to see who committed which lines and also when. This piece of metadata can be useful when trying to understand a code base and its evolution.
  23. 3 points
    Using classes just for the sake of using classes can be nice exercise in futility. I have to admit that I haven't paid close attention to this post and I have been reading it rather superficially, so it is possible that I missed some piece. But from your original post I don't see any compelling reason why you should switch to classes. Especially if you don't feel comfortable with them and don't really see the point. Main advantage of classes over records is polymorphism. If you don't have the use case for it, then records will do. Also, one small note - you are holding your records in dynamic array, and those are allocated on the heap, not on stack. Only the few bytes of your global record holder would sit on stack. And overall, class based solution would use more memory than record based one. That does not mean that you should not learn more about the classes, but trying to learn on wrong use case will make things harder not easier. You should learn about classes with examples where they really show their advantage and then you will be able to understand them better.
  24. 3 points
    You, Sir, are a scholar and a drinker of fine ales.
  25. 3 points
    Finally the Quality Central issues statuses begin to update. And what do you think? RSP-21645 (Editor tabs do not show icons) - closed. Resolution: Works As Expected 🙁 . Really, that is how they at Embarcadero see it. RSP-21636 (Active editor tab is not highlighted when IDE theming is disabled) - closed. Resolution: Won't Fix. Given this stupid attitude (and obvious intentions to further force the themed IDE despite all its glitches) I highly doubt that I'll renew my subscription when it expires this March. I thank David Millington for personally contacting me but I do not want to further waste my hard earned money for another round of cosmetic IDE changes instead of bug fixing.
×