Leaderboard

I am not confused. I am frustrated. I want both. Most of all, I want 64-bit debuggers that understand threads and make it easy and robust to focus debugging on specific threads, and that doesn't suddenly stop breaking on breakpoints or break on "invisible" breakpoints in Indy, or just purely stop responding completely. I'd love to be able to "disable" exception breaks for specific threads and only for those threads. I want the broken HighDPI properly and finally fixed. I want the code generation significantly improved for 64-bit. I want RTL, VCL and FireMonkey to be rock solid and efficient. But - also ... I want Generics constraints for enumerated types so that I can use enumerated type and set type operators. I want proper nullable type support, including the relevant operators. I want ARM support for Windows. I want ARM/Linux support for Raspberry PI. I want the static code analysis capabilities of FixInsight and similar, to be built into the DSP. I want a package manager that really works, unlike GetIt which is just a glorified downloader and installer. I want Swagger support for APIs.

I don't think it should be either or, why can't we have both? Instead if often seems that we have neither.

Back in old times when I was trying lots of soft, I had numerous setup files sometimes named like BWDSQHSetup.exe which I downloaded months ago and I was really glad to see a welcome screen which not only mentioned it will install "MookaWooka Pro" but also contained a few words about what the hell that soft is

Yes, it is called Build Groups: Do you know Build Groups?

It's all find and dandy to come up with all sorts of ideas that we as developers would love to see. But I believe that the reality is that most of the revenues come from corporations who are mostly interested in risk-reduction, not more usable software. I don't believe that EMBT is making most of their revenues from Delphi products because they're being actively used for new product development. Rather, I believe it's coming from corporations that built large apps between 2000 and 2010, and those apps are still producing strong revenues with modest investment in maintenance. These customers have been just running things as-is for the past 10-15 years, and they invest in minor updates to keep them operational. I believe the latest language enhancements are ignored, as are most of the new features. These customers simply keep renewing the maintenance agreements because it's the least-cost thing to do that minimizes their risks in case something unexpected happens. As one of the devs at a place I worked in 2009 liked to say, "We're all here just keeping a comatose patient alive long enough for them to migrate this project over to .NET." During the short time I was there, they missed the first two major milestones for that migration, and the schedule got pushed out by an additional year. The company was REALLY upset when Microsoft announced they were end-of-lifing Windows XP. I mean, these guys were so paranoid of changes to Delphi's math libs that they spent months running a HUGE bunch of regression tests on every new Delphi release looking for deviations in calculations less than 10^-6. Newer releases past D6 failed, and with MS abandoning XP meant it could cost them billions of dollars due to even the tiniest deviations in math calculations. I tried to move them to D2010, but one of their devs built some components that would make most folks here faint due to their total non-conformance with component building guidelines, and they wouldn't build properly under D2010. That's not to say there isn't new development and even innovation going on with Delphi in shops around the world. But it explains why the language itself is at least 10 years behind most contemporary languages; why the most urgent updates to the platform actually track updates that Microsoft, and now Apple, make in their latest hardware and/or software releases; why the run-time technology (like high-DPI stuff) hasn't gotten much attention (because most applications are running on machines barely capable of displaying full HD resolution); and why nothing reflects much concern for anything other than Microsoft, Windows, and making the run-time libs more similar to C# libraries than anything else (IMHO). ********************** If you want to see REAL INNOVATION in this space, take a look at what TMS Software is doing. They've created a more intentional and cohesive extension of the Delphi platform in the past 18 months than EMBT has done since they bought the company from CodeGear. I can't say for sure, but I suspect a larger percentage of their revenues come from developers who have a larger say in their future wants, needs, and desires than your average IT Manager or CIO. They're actually intersted in things that are not tied to Microsoft or Apple and extend into a more homogeneous cross-platform ecosystem that has web development in the center of everything. They are solving difficult multi-platform problems that EMBT should have been working on for 5+ years now if they really cared. And they are not waiting for EMBT to address any of the shortcomings they may encounter. One of their key players, Dr. Holger Flick, has written and published three (3) new books in the past 18 months, with more coming! With TMS tools, you don't even need Delphi to build Delphi apps that run in more platforms than EMBT supports TODAY! (See the screen-shot below) You can build them in Visual Studio Code, and using Lazarus you can even build executables that run natively on Linux machines without having to spend thousands of dollars on an "Enterprise Edition" Delphi license. We don't need more threads trying to lay out a direction that EMBT can take to make Delphi nicer for Developers, because Developers are clearly not EMBT's target market. (I don't know about you, but in the past 15 years, I've been the only person every place I've worked who had my own personal Delphi license to ensure I could keep up with new developments. That's because the production code at most places was a few releases behind the latest Delphi release.) Get invovled with TMS products and see if there's something there worth focusing on. Not their older VCL, FMX, and Intraweb (gawd, is that still around?) libs, but the newer WebCore, FNC, and Business Suite stuff. Their next release of WebCore will let you create web apps that run natively in more platforms than Delphi supports, including Raspberry Pi -- without requiring you to have access to a compiler that generates ARM code. And you won't need to have your dev machine tethered to another dev environment to do cross-compiles. (I know this is going to raise some hackles, so ... I say it's "native" because there's a wrapper that runs as a native app and it allows the code encapsulated inside of it to run within a web browser. There's no hardware that runs javascript in the same way there's nothing that runs java bytecode.) The photo below is a snapshot from a video they posted recently illustrating support for the Raspberry Pi. that shows the platforms WebCore will support in its next release (which will probably be out before EMBT releases their first "bug-fix" update for D11) using either Delphi or VSC as your dev platform. Their strategy does NOT depend on what Microsoft or Apple may or may not do, or what the next release of .NET or iOS might provide. WebCore targets javascript running in the web browser, which is becoming more universal than Windows. I invite all Delphi developers to stop complaining about what EMBT is NOT doing and start cheering on and supporting these guys who are actually INNOVATING around the Delphi language and EXPANDING the Dephi ecosystem -- RAPIDLY! (Buffalo Springfield's song, "For What It's Worth" is echoing in my head...)

Hello World, I just had a pleasant surprise - when I build a certain x64 project of mine, the executable is noticeably smaller under Delphi 11 Alexandria (6.5 MB) than under Delphi 10.4.2 Sydney (7.3 MB). Embarcadero must have done some serious optimizations. (Edit) the project is compiled with {$WEAKLINKRTTI ON}.

Small video showing how to embed any part of (or whole) PDF, PowerPoint, Excel, Word, Outlook, document into report. Document is embedded in vector format and is editable (can be changed in built in HTML Editor). https://s9.gifyu.com/images/rb5bba15035de9053c.gif

Same here. PyScripter Delphi 10.4: 17,302 KB PyScripter Delphi 11: 15,523 KB 10% reduction, not bad. Any idea where this is coming from (generics?) Probably the first Delphi version that produces smaller executables that its predecessor.

You can't really expect a new feature like that to be implemented in under 3 years.. /s

There is a possibility to build from command line: https://docwiki.embarcadero.com/RADStudio/Sydney/en/Building_a_Project_Using_an_MSBuild_Command

The previous code I posted was based on Marco's Sydney book comments about changing event assignments at runtime. I think the OP is wanting to use reference. Here is further example procedure TForm30.Button1Click(Sender: TObject); var A: Double; ptrA: PDouble; ptrB: PDouble; ppB: PDouble; pC: PDouble; F, pF: TForm; refF: Tform; begin new(ptrB); //http://rvelthuis.de/articles/articles-pointers.html ptrB^ := 2.02; //initialize value in new instance location ppB := ptrB; // second PDouble get address of first PDouble; Showmessage(ppB^.tostring); A:= 1.01; ptrA := @A; // PDouble given address of double named A showmessage(ptrA^.tostring); pC := ptrB; // Use reference to store pB value; ptrB^ := ptrA^; //overwrite pB with ptrA value ptrA^ := pC^; //overwrite ptrA data showmessage(ptrA^.tostring); // Delphi hides the explicit details of above in VCL // but accessing the properties of components can be done with above. F := TForm.create(self); pF := F; // pF is reference no create needed! pF.Caption := 'EZ PZ'; refF := pF; // refF is a reference refF.Show; Dispose(ptrB); //manual dispose //pF.free; commenting out allows new form each button click! end;

Microsoft: Word, Excel, PowerPoint, etc.

I may have one in the next day or so. That is likely to be a completely different issue. Does it happen on other iPhone models? Can you provide code that reproduces the problem? I have access to an iPhone 13 that I can test on. iOS 15.0 SDK comes with Xcode 13 (not earlier versions). I'm not sure if you can switch back to Xcode 12.5.1 and still build against iOS 15.0 SDK The issue we've been discussing affects Delphi 11 and earlier.

If one is an expert in a certain area, go help FreePascal/Lazarus because you know for years now you don't see and as such can't expect much new from Delphi anymore. Heck, TMS web uses their pas2js translator... you can go and help get the Lazarus IDE finally a stable docked view and low level experts can improve their debugger 😉

What’s been suggested in the first post can already be done to some extent with tms web.

I don't have installers, but I think there's nothing wrong with that. It's not like you have to introduce your program, the user has already decided to install. The welcome page they use for their example makes no sense, because it provides absolutely no information. Same like "Setup has now finished" you sometimes see. By the way: Compare with this totally stripped down MSIX install experience on Windows:

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.

Thats sounds miserable and demoralising. I have seen some of that, but not much.

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;

I haven't followed this way but another way for Action Caption and also for Combobox items and so on. The issue is that translations work one time, when contents are in English (starting language) to any other language (for eg: EN to IT) because they are initially copied from DFM to object fields. When I try to switch EN to IT and then to CZ for objects which don't recover data from DFM translations obviously doesn't work. But there is a solution that I use: TPageProjectWorkFrame = class(TFrame) ... private procedure ReTranslateEvent(Sender: TObject); ... end; uses gnugettext, ... osGNUGetTextUtils; constructor TPageProjectWorkFrame.Create(AOwner: TComponent); begin inherited; ... // links object/event to translate manager and re-translate GNURetranslateManager.Add(Self, ReTranslateEvent); GNURetranslateManager.ReTranslate; end; destructor TPageProjectWorkFrame.Destroy; begin // unlinks object/event from translate manager GNURetranslateManager.Remove(Self, ReTranslateEvent); ... end; procedure TPageProjectWorkFrame.ReTranslateEvent(Sender: TObject); begin AnalysisAction.Caption := _('ANALYSIS'); BackAction.Caption := _('BACK'); CoordinatesModeAction.Caption := _('WCS MODE') HomingAAction.Caption := _('HOMING A'); HomingAction.Caption := _('HOMING'); HomingAllAction.Caption := _('HOMING ALL'); HomingBAction.Caption := _('HOMING B'); HomingCAction.Caption := _('HOMING C'); HomingXAction.Caption := _('HOMING X'); HomingYAction.Caption := _('HOMING Y'); HomingZAction.Caption := _('HOMING Z'); JogAction.Caption := _('JOG'); MacroAction.Caption := _('MACRO'); ShowWork3DAction.Caption := _('WORK 3D'); ShowWorkSimulateAction.Caption := _('SIMULATE'); end; The GNURetranslateManager is a singleton object which call registered objects RetranslateEvent every time a language change. GNURetranslateManager call internally TranslateComponents (first call) or ReTranslateComponents (next call) automatically for all objects which starts always from DFM english texts (as Label, Panels, etc). Usually I keep Actions Caption empty in the designer (but not necessary) and when RetranslateEvent is called I add _('xxx') with original English language to translate. This automatically update linked action objects. It works perfectly with Frame and Forms (VCL, never tried FMX applications). osGNUGetTextUtils.pas

The latest version of Indy 10 (https://github.com/IndySockets/Indy/) supports back to C++Builder 5, and can officially use OpenSSL DLLs up to 1.0.2u (for OpenSSL 1.1.x+, use this WIP code). TLS 1.2 has been available in OpenSSL since 1.0.1, and Indy 10 has supported TLS 1.2 for a long time. OpenSSL DLLs are available at https://github.com/IndySockets/OpenSSL-Binaries (https://indy.fulgan.com/SSL/ is retired). If you are getting errors from Indy's standard TIdSSLIOHandlerSocketOpenSSL component when it tries to load the DLLs, then you are likely using DLLs that are not compatible with your version of Indy. You can call Indy's WhichFailedToLoad() function in the IdSSLOpenSSLHeaders unit to find out why the DLLs are failing to load.

Well... intf procedure DoXPlatformStuff impl procedure DoXPlatformStuff {$ifdef windows} do lots of Windows stuff {$endif} {$ifdef lunix} do lots of Linux stuff {$endif} {$ifdef macos} do lots of MacOS stuff {$endif} ... repeat for all 100 platforms FPC supports and do it for EVERY platform-specific function Compare with includes: intf procedure DoXPlatformStuff impl {$ifdef windows} {$I 'dowindows.inc'} {$endif} {$ifdef lunix} {$I 'dolinux.inc'} {$endif} {$ifdef macos} {$I 'domacos.inc'} {$endif} ... repeat for all 100 platforms FPC supports

This was likely advised by an ill C-er to spread the C-style madness over another languages. AFAIK no language uses this mechanism besides C which kinda alludes. Yes and it makes source examining a real nighmare. Alas, there's no better option to avoid code duplication.