Leaderboard

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! 😄

Have you and your coworkers got any experience with Git or Mercurial? If not, I stongly advise against those. They are distributed versioning systems and therefore very different from MSVSS (unless the latter has changed from when I used it) In addition to learn a new VCS you will also have to learn a new concept of VCS. SubVersion more closely resembles the way MSVSS works, so I would suggest using it. Unless of course you have got a need for a distributed VCS, you all already know how to use Git or you want to use Git for other reasons (e.g. it "is the VCS that everybody uses"). I agree with @haentschman: Use TortoiseXxx rather than the integrated IDE support, in this case TortoiseSVN.

Hi... ...how many users? My favorite is GIT. But NOT over the IDE. I use TortoiseGIT. It looks like the explorer with overlay icons. ...and WITHOUT console.

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.

The components you see in the Form Designer are those inside the BPL loaded at design time. As long as you don't re-compile this BPL you will work with the old version of the component. This can be different than the version compiled into your EXE, as long as the new source files are found somewhere in your search path.

Fixed download links: IDEFixPackD103RegDev.7z fastdccD103vDev.7z

Probably because in the second case "[10]" is seen as a set constant by the compiler. It works if you declare a variable with a proper type: var b: boolean; a: array of Integer; r: TMyRecord2; begin try a := [10]; r := r * a; // this line is compiled b := r = a; // this line is not compiled except on E: Exception do Writeln(E.ClassName, ': ', E.Message); end; end.

Hi all, I was trying to use CentOS and finally I managed to install a webbroker module. As it was a kind of a journey to figure our how things work, I put together two articles so others may find them useful: Delphi and CentOS 7 Deploying a WebBroker Apache Module on CentOS 7

I suggest git with GitHub or GitLab. I use Tower.

GitKraken is not free for commercial use though. I like using SourceTree (after the 2.x disaster in 3.x it's usable again).

That's what this forum is for.

Just switched from Visual Sourcesafe to GitHub. Best decision ever! We use Git Kraken as git visual interface. It softens the learning curve a lot and it’s the best tool we found to visually manage git.

Have a look to Microsofts Team Foundation Server: https://en.wikipedia.org/wiki/Team_Foundation_Server

I myself favor Mercurial (hg), but that is just another flavor for the DVCS concept. And we are only two and a half developers. Considering Microsoft themselves favor git over VSS (which they have never used seriously themselves) or TSF, that speaks volumes. Subversion is nice and all, but just can't keep up with the young folks anymore. Why learn to move a two horse carriage, when you could be learning to drive a Model S? So if you consider moving to a different VCS, make the move count. There is not that much to learn anyway. And most of it you'll learn when you need it. Just look at one of the hundreds of VSS->DVCS tutorials and go for it. Best of all, they both are free. Even if you setup an apache server to host a central repository, still free for any amount of users. Edith actually wanted to add Joel Spolskys very cool hginit.com which is a very nice introduction to Mercurial, but it is down for some reason. So instead you get Joels 2010 blog entry on how he took on DVCS after years of Subversion: https://www.joelonsoftware.com/2010/03/17/distributed-version-control-is-here-to-stay-baby/ Examples: https://edmundv.home.xs4all.nl/blog/2014/02/08/migrate-sourcesafe-to-mercurial/ https://www.perforce.com/blog/migrating-visual-sourcesafe-mercurial https://accu.org/index.php/journals/1828

Perfect for GIT... But you have to know that you have to learn a lot to use it wisely. Tutorials: https://www.youtube.com/channel/UCO251AKqx8iSssbN66eECLA

You, Sir, are a scholar and a drinker of fine ales.

In another post you showed something that's got some kind of TProject thing. You said it's a rather large structure. From what you showed, I'm guessing that you're also not allocating your records from the heap using new() because that would require you to call free() or whatever it's called. (I rarely use records, sorry.) So you've got arrays of huge records sitting in the global namespace and you're wondering why various debugging tool sare having trouble working. Have you considered that they're optimized to work with smaller chunks of things allocated from the heap at run-time? What percentage of your records are allocated from the heap? And where are all of these structures being loaded up? From a database? An INI file? Or just stuff collected at run-time? Where does it go when the program shuts down? To me, OOP is simply a way of organizing things at the source code level to make everything easier to manage. What you end up with (should be) very clear and organized. (I've seen designs that are far from it, but that's the general goal.) There are some constructs in source code that have zero impact on memory and/or execution time, so source code often appears somewhat bloated compared to non-OOP code, although a lot of it has no impact on anything. (Properties that refer to fields directly rather than via setter/getter methods, for example.) What most people focus on are the handful of things that are invisible at the source code level that DO have an impact on memory and/or execution time. This is penny-wise and pound-foolish most of the time. In your case, you just don't seem to see the value of having a tackle box to keep your tackle in rather than a toolbox, and prefer to put into whatever random bags and boxes you have around. And you put your snacks and first aid stuff into the same random bags and boxes. You're confused because a "tackle box" would seem to be derived from a "box". So what? So you seem to prefer a less organized solution instead. Or maybe a toolbox with woodworking tools, or another one with auto mechanic tools. Or maybe a matchbox with matches in it. You are pretending that these are all the same types of containers, that their contents have no particularly differentiating factors, and it's fine to put them into whatever bag or box or bottle is handy. Just don't put matches or tools into something that may get wet. Do you put gasoline into a container that isn't designed to hold liquids? Or flammable liquids? Wait, those are properties that belong to containers. But you're just using random bags, boxes, and bottles. Without having differentiating properties, any of them will do for any purpose. That's what you're saying. You could use a zip-lock baggie for your tackle and put your soda into a matchbox. What you don't realize is THAT approach means MORE CODE is needed to sift through all of the conflicting properties that should be IMPLICIT in the CONTAINERS they're in. Do you really enjoy writing all of that code? Do you realize how much of it is needed? I imagine not. A tackle box is a box; a matchbox is a box; a toolbox is a box. And you refuse to use any of them because you think the fact that they're all "boxes" and share a few common properties is ... confusing? Would you put a liquid in a box? Well, if it has a property like "can_hold_liquid" that's set to true. I have only one question for you: if you don't want to organize things in such an intuitive way, how are you managing all of this now? I guarantee you it is NOT invisible! It's just part of the mess that your code has to deal with. You don't put fishing tackle in a matchbox. But if they're each just a "box" then you need code added to each one that is intended to insure that what you put there is acceptable. Polymorphism is only confusing when you THINK you only have one kind of box in this case. Since everything is just a "box", you've probably got lines and lines of Assert statements or nested if...then...else clauses checking to see if stuff is safe to add and update. The reason is that by using properly designed classes, the COMPILER tells you when you try adding the wrong objects to things. You know the old saying: "when your only tool is a hammer, everything looks like a nail"? When you aren't using classes, your only tool might as well be a hammer, because every piece of code you write needs to check to see if the thing really IS a nail or not. Simple question for you: how much of your source code is doing nothing but checking to be sure the parameters being passed are of the correct type and/or within a legal range? If you switch to an OOP design, 99% of that code will disappear because the compiler will catch it. And I promise you that all of that extra code and complexity is increasing your maintenance overhead and technical debt considerably.

Fine for Global vars as long as you don't need to finalize. At that point just change to a class. Pretty sure you don't actually want Global Instance data.. more like a snack without the preparation and cleanup 🙂 //MMWIN:CLASSCOPY unit _MM_Copy_Buffer_; interface type TGlobal = record class var Id : Integer; RecName : string; Values : TArray<TValue>; class constructor Create; private class function GetNewProperty: Integer; static; class procedure SetNewProperty(const Value: Integer); static; public class property NewProperty: Integer read GetNewProperty write SetNewProperty; end; implementation class constructor TGlobal.Create; begin inherited; // TODO -cMM: TGlobal.Create default body inserted end; class function TGlobal.GetNewProperty: Integer; begin // TODO -cMM: TGlobal.GetNewProperty default body inserted Result := ; end; class procedure TGlobal.SetNewProperty(const Value: Integer); begin // TODO -cMM: TGlobal.SetNewProperty default body inserted end; end.

Hold on turning your records into object until they introduce automatic construction and destruction in Delphi. If then, you still want to turn it into an object, then do so. Otherwise, records may be the more ligthweight choice with easier (stack based, and soon automatic) memory management, especially well suited for short-living objects.

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.

It's unclear what your point is other than to formulate an excuse not to use classes. I mean, you're going through a lot of gyrations simply to avoid using classes. I think Uwe did you a disservice by simply wrapping your existing mess inside of a class. It would be far simpler to just convert it to a class directly so you could see the difference. Your PrepareGlobalRec method IS your constructor, so claiming you don't need "create" is baseless. constructor SomeName; <-- This is for doing exactly what Preparexxxx is doing! The name is irrelevant You probably will also need a destructor to avoid memory leaks, although if the lifetime of these vars is the same as the application, then they'll be freed when the program quits. I'm not sure why you think you need 100's of global vars other than this is just how you've been doing things for years. This is how VB structures things. There are generally very few global vars needed in properly designed Delphi apps. What you'd probably want to do is put them inside of a DataModule or Form and access them from there. Do you NEED TO? No, of course not. Nor do you need to use records or arrays for anything either, just lots and lots of variables. Either you're going to use OOP principles to build your software or you're not. It's up to you. You don't need to ask anybody here for permission to build something using pre-OOP practices. Sure, you CAN ... but why?

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.

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.

This bug has already been reported before but since QP is not responding right now I cannot look for it.

This is probably caused by smart linking. In smaller projects you do not use classes, that can call GetProductInfo, that is why they have been eliminated entirely. And once no one references GetProductInfo, it can be eliminated too.