Leaderboard

TL;DR Your discontent IMO has nothing to do with the topic and only sabotages the OPs attempt at a discussion.

I found a bug in Gnugettext and I thought I would let you know and ask your opinion about my fix. Gnugettext does not translate Action linked properties. It does that by calling a function ObjectHasAssignedAction and in TGnuGettextInstance.TranslateProperties there is the following code: if ObjectHasAssignedAction(AnObject, PropList, Count) then Continue; The problem is that if an object has an assigned Action property no property of that object gets translated action-linked or not. I got bitten by this since there was an action in PyScripter used in different menus, and in one of them I had overwritten the Caption, so the Caption of that item was in the dfm file and the default.po, but it did not get translated. The solution I am trying with success is to remove the above code in TranslateProperties and instead added a check as to whether the property is stored (IsStoredProp😞 if ((currentcm=nil) or (not currentcm.PropertiesToIgnore.Find(UPropName,i))) and (not TP_IgnoreList.Find(Name+'.'+UPropName,i)) and IsStoredProp(AnObject, PropInfo) and (not ObjectPropertyIgnoreList.Find(UPropName,i)) then begin TranslateProperty (AnObject,PropInfo,TodoList,TextDomain); I did check that action-linked properties are not translated multiple times (IsStoredProp returns False). The above also appears to speeds up the translation. But I do wonder whether the above fix has any obvious drawbacks. @dummzeuch Any thoughts?

Hi John The new Android requirements from November also include a requirement to support SDK 30 (as well as the new billing APIs). To avoid having to upgrade to Delphi 11 just as it was launched (generally a little hit-and-miss) I looked into supporting the new requirements for Delphi 10.4 instead. Unfortunately I hit a brick wall with the SDK 30 update. Too many internal components of Delphi 10.4 don't work properly with SDK 30, so it wasn't feasible. The billing API support was fairly straightforward as it could be bolted into 10.4, but without SDK 30 support it wouldn't be allowed onto the Play Store anyway. Best to upgrade to Delphi 11 - it seems pretty solid and a good upgrade so far.

I have a helper for this kind of stuff (in real the helper contains some more methods : ) : TMyFieldHelper = class helper for TField public function AsIntegerDef(const ADefault : integer) : integer; end; function TMyFieldHelper.AsIntegerDef(const ADefault: integer): integer; begin Result := ADefault; try if (not Self.IsNull) then Result := Self.AsInteger; except {TODO -oOwner -cGeneral : check which to swallow ... } // swallow any exception end; end;

Hello there! Nowadays we have a huge amount of cross-platform frameworks for mobile and enterprise development. Some of them are popular, some of them are well-known, all of them have their pros and cons. In this episode let's discuss architecture for Flutter, FireMonkey and Xamarin frameworks.

This is a link to a section on this site where you can download a free copy of Marco's book: https://en.delphipraxis.net/topic/4418-object-pascal-handbook-delphi-104-sydney-edition-marco-cantù-2020-571pg/

Instead of hijacking this thread with yet another off-topic wall of text about why Embarcadero sucks and Delphi is doomed, maybe you could start your own thread? This was in reponse to the OP who posted a bunch of suggestions for delphi from a Developer's perspective. There have been tons of such posts here and elsewhere over the past decade, some quite eloquent and some more debatable. This discussion forum is dominated by DEVELOPERS, like you and I. We have our perspectives, we love Delphi and we all pretty much would LOVE to see it continue to grow and expand and get better. But after all of the proposals, submissions through official channels, and every conceivable attempt at begging, prodding, and encouraging Embt to do different things, it has become painfully obivous that ... they just are not interested. They don't "suck". They are operating in the best interests of their SHAREHOLDERS. We are DEVELOPERS -- NOT SHAREHOLDERS! SHAREHOLDERS want PROFITS while we DEVELOPERS want MORE FEATURES! Any overlap is mostly coincidence, driven primarily by Microsoft and Apple. Not us Developers. The CUSTOMERS paying the bills want LOW-RISK INVESTMENTS. Everywhere I've worked in the past 10+ years has had one thing in common: they only want me to touch code that HAS TO BE CHANGED. They don't want me to use NEW FEATURES. They don't want REFACTORING. They don't want the code "cleaned-up". A couple changed their policies that require every line that shows up as changed in the change logs must relate back to a specific trouble ticket. "Refactoring" for its own sake was not allowed. They DO want: simple, straightforward changes that use existing coding patterns and language features found in D7-era code (around when the apps were built) so it looks and behaves the same as all the rest of their code. The last place I worked, most of the core code they used in production had not been touched since 2007. I was told on my first day, "DO NOT TOUCH ANY OF THE CODE WITHOUT MY APPROVAL!" I found and documented several bugs, and was told point-blank, "you must be wrong, this code has not changed in over a decade; there are no bugs in it." Except it went from running in Win XP to Win 7 to Win 10, and now it does weird and unexpected stuff sometimes that I captured on camera. They didn't want to hear about it. I asked one Dept head (at a State Agency) why they don't rebuild their code in the latest version of Delphi using more contemporary stuff. His answer: Because their State's CTO basically said, "All new software development will be done in C#/.NET." Period. End of story. Seems their Legislature authorized a 10-year agreeement with Microsoft to provide them with everything they'd need, and that was that. I've heard similar things from multiple places I've worked, both public and private. This is NOT MY OPINION! I personally don't think Embt "sucks". I personally don't think Delphi is "doomed". I think Delphi's evolution is being dictated by two things: (1) SHAREHOLDERS who are only interested in profits; and (2) CUSTOMERS who are interested in REDUCING RISKS IN EXISTING PRODUCTION CODE. I love Delphi. I love the Developer community. And I don't see Embt's focus on Delphi changing any time soon to make it more aligned with that of Developers other than coincidentally. For example, I've seen dozens of proposals for language extensions, many of which would be useful to most Delphi Deverlopers on an almost daily basis. But the only two that were added to D11 ... I've never ever seen discussed. I was honestly totally surprized when inline 'var' declarations appeared in the language. That's a marginally useful feature to me, and not one I would have ever expected to see added. But its introduction broke a bunch of far more useful things in the IDE. They would have been better off not introducing it until everything in the IDE worked properly with it. D11 reportedly hasn't fixed anything that was in D10.4.2. The last place I worked, we were asked after D10.3 came out if there was anything added to the language that might justify the risk of upgrading everything. Inline vars were all there was, and the consensus was that they did not justify anything, especially because they broke a lot of stuff in the IDE. Unfortunately, the company went ahead and paid the maintenance fee anyway. Why? Because the cost of NOT paying was more risky and costly. Yet we're still waiting for MANY VERY USEFUL ADDITIONS to the language! This is how the game has been rigged: customers (companies) will continue to pay their maintenance fees whether they use what's been added or not. And SHAREHOLDERS LOVE THAT! Developers ... not so much.

YES IT DOES! It allocatess space on the stack for a POINTER (assuming it's inside of a method). When you say this: vObj_Instance := TClass_Type.Create(...); it allocates a chunk of memory from the heap, sets vObj_Instance to point to it, then calls the constructor with an implicit pointer argument to that chunk of memory and initializes it based on the code in the chain of constructors that get called. If TClass_Type is defined as a RECORD, then it would allocate enough space on the stack to fit the entire record, and you would not need to allocate space for it from the heap. In C/C++ this would be written as: TClass_Type * vObj_Instance; // allocates space for a typed POINTER // this is the constructor call equivalent to what happens in Delphi vObj_Instance = new TClass_type(...); This is more clear, showing that it's a POINTER type. In Dephi, the call to allocate space from the heap (by 'new' in C++) is always IMPLED.

Made sample here: https://github.com/viniciusfbb/skia4delphi/issues/12#issuecomment-933528854 Result:

I stay away from rebasing. It just feels like a dirty approach. Perhaps I just need to do it more often but I probably won't use it unless I'm forced to. I started out with a 'sneaker net' version control system as we didn't have a network. A couple times per day I would copy a few source files to a floppy, walk down the hall and hand it to the one other developer to copy to his machine (or he did it with me.) We would merge changes manually. (We split up tasks to specifically keep merging to a minimum.) After months of this, we finally put in a network and shared files from a single location and used MultiEdit to modify the source. It managed the read only lock on the file to prevent two people from accessing the same file. We kept up with file locks with VSS for about a decade and then moved to SVN for the next decade. Large project, built over 20 years with millions lines of source with 10 or more Delphi developers each committing multiple times per day. We kept merges to an absoulte minimum and were quite successful. For a long time, I directly managed the workflow and kept the merging to a minimum based on task assignment. I think it's kinda rediculous to even contemplate 5 people editing the same DFM and attempting to merge UI changes (but sometimes it did have to happen.) Most UI conflicts were basically minimized outside of the VCS. I'll follow whatever the workflow is of the next company, and may hit you up on advice on rebasing if they follow that approach!

Merge conflicts happen whether or not the team is using branches or all developing on a single branch. If there are never any conflicts then it doesn't make much difference if you use branches or not. If there are conflicts then they can be a massive problem on long lived branches. But if there are no branches then they are also a massive problem. Often developments are in flux. Devs try something. Realise it was the wrong idea. Try something else, and so on. If this happens without branches then everyone has to deal with the conflicts over and over again. That's more work. Well managed branches make this easier. There never are magic bullet solutions for tough problems like this. You have to keep an open mind and do what works best for their teams.

Main issue with branches are merge conflicts. They tend to get worse with time because more code is added and there is potentially more conflict. So naturally, if you have short lived branches there is less possibility for conflicts to emerge. Also continuous delivery focuses on making small incremental changes (which is not always possible) so making small features that don't span across too much code (files) tend to be easily mergeable. Having said that, the lifetime alone actually means nothing. Nor the number of branches. First, you can easily shoot yourself in the foot with the branch old just a few hours, if you change some "hard" to merge file - think something like dproj file. On iOS, macOS that would be storyboards - you don't even need multiple developers to make a mess. So for some types of files, you will need to have specific instructions about who and how can change them without causing issues. Next, it is not how long branch lives, but whether you keep it up to date with other development. If you have branch and you merge it after a year, of course there will be trouble, but not because the branch is year old, but because you didn't keep it up. The most important rule is don't merge, rebase and rebase often. Not only that keeps history cleaner, but you will also have less conflicts - most of the time there will be none or they will be simple to resolve. And of course, in larger teams there has to be some coordination between what is done and when. It makes no sense to start some large refactoring in one part of the code few days before another large refactoring in overlapping area of the code is finished. It is better to wait than waste time on merging.

Well, this guy definitely pushed me read up more on this stuff, I just couldn't listen and follow his graphics at the same time. The good thing is that being single developer on a project that you can not only decide which branching model you use, if any, but you can combine and switch as needed. But using Git flow model, It would be really nice if Delphi IDE could give a little more info about the current working branch, as it has so many branches. Pretty cool when you can refer to your product as legendary and write it on your blog about Git branching models: https://www.gitkraken.com/learn/git/best-practices/git-branch-strategy