Leaderboard

It's true that the 64 bit Windows debugger is a disaster zone. But I just debug with the 32 bit debugger. You can have a project with both 32 and 64 bit targets. You can then ship just the 64 bit if you prefer. But you can still use the 32 bit debugger during development, because it's the one that is actually useful.

In that case, the code is not that difficult, as a Delphi developer you have to be able to do this for 99,9% on your own. So make your own code in Delphi, see if it works, if it doesn't, then post that Delphi code here for reviewing/tips/improvements.

True, but nobody should be using that type anyway. I speak as a developer of mathematical software.

Just for fun, read this article by W. Kahan and J.D. Darcy about the usefulness of extra precision. "How Java’s Floating-Point Hurts Everyone Everywhere" https://people.eecs.berkeley.edu/~wkahan/JAVAhurt.pdf

The question was about 32bit Delphi. The modern Intel/AMD FPUs still have the 80bit mode, and if the FPU would not be in hardware, then in system emulation. Your earlier advice ("nobody should") did not care about the precision drop to 64bit float and developers who need more precision. That's why I mentioned the possible need for alternatives (large-precision libraries). A developer of mathematical software should know this ...

Carriages also once were the fastest way to travel - yet nobody today complains that he can't go onto the highway with one. On topic: If the 64bit Delphi compiler(s) (and significant parts of the RTL) would not be even worse than the 32bit compilers and the debugging experience would not be an absolute nightmare I would switch instantly - it's proven that even though a 64bit application might use a bit more memory because the pointers are double the size due to architectural differences it simply can perform better. Simply having more registers is already a huge gain.

Too bad it's the implicit default type in many places - be it float literals or parameter types.

Jeez ... has it been 10 months already? OMG! There's an idea that came to me in 1995 that was not technically feasible until 2015, but it was missing a couple of key pieces. The last piece was out of reach until this past February. My challenge for the past 18 months or so has been getting the needed funding and pulling together a team to build it. I have not succeeded yet. A lot of startups are created by a bunch of friends who either live at home or work together and spend their free time on it, so they don't need much capital. Once they have an MVP, they can get funding. Steve Jobs famously said about the iPad (that was almost universally panned by every corner of the tech world): "Sometimes people don't know what they want until you show it to them." The iPad created an entirely new hardware segment: the "tablet computer". What all the pundits seem to have missed was that it was hardly a "new concept". Every Star Trek fan has been seeing them in the hands of every version of that show since it launched. We've simply been waiting for one to appear in real life, and Jobs finally did that. That's what I've got: something nobody understands and doesn't know they want. So my plan is to build it, then put it into the hands of ~40 people who all have at least 1000 raving fans they can encourage to try it out. The capital raising hasn't been fun. I'm mostly looking forward to building a team and then getting this idea out of my head and into the world. THAT WILL BE A LOT OF FUN! In case anybody is curious, I plan to use Delphi with TMS WebCore to buidl a web app, and then maybe create native apps using their Miletus technology.

c# - 32-bit OpenFileDialog --> 64-bit System32? - Stack Overflow tl;dr not possible

We have made the "SetSystemText" function below, to replace the hardcoded dialog strings. It works on all platforms including iOS and Android (thought we have had problems with only a partial implementation in MacOS in previous Delphi versions - not sure if it has been fully implemented yet). It is a part of our own language handling class, but the idea is that fLines is a list of text lines loaded from a language file, where the ID is defined by a constant. Just replace this with your own source of translations. The "LoadLangFromStrings" procedure is in FMX.Types. procedure tProgStr.SetSystemText; var lStrList: TStringList; begin //Load list of translations for use everywhere the "Translate" function is used in Delphi. lStrList := TStringList.Create; lStrList.AddPair(SMsgDlgInformation, fLines[cStrInformation]); lStrList.AddPair(SMsgDlgError, fLines[cStrError]); lStrList.AddPair(SMsgDlgConfirm, fLines[cStrConfirmation]); lStrList.AddPair(SMsgDlgWarning, fLines[cStrConfirmation]); //<- We don't have the "Warning" text translated lStrList.AddPair(SMsgDlgYes, fLines[cStrYes]); lStrList.AddPair(SMsgDlgNo, fLines[cStrNo]); lStrList.AddPair(SMsgDlgCancel, fLines[cStrCancel]); lStrList.AddPair(SMsgDlgClose, fLines[cStrClose]); lStrList.AddPair(SMsgDlgOK, fLines[cStrOk]); lStrList.AddPair(SMsgDlgHelp, fLines[cStrHelp]); lStrList.AddPair(SMsgDlgHelpHelp, fLines[cStrHelp]); LoadLangFromStrings(lStrList); lStrList.Free; end;

To me quite the opposite, just the release we needed. Quality updates should come more frequently IMHO. -Tee-

Known issue, at least for "date_sent". You need to use "report_date" instead. See SMS messages date_sent on Android with Delphi XE5 always returns 0? on StackOverflow. Not sure if there is a similar workaround for "status".

In the webinar Q&A Marco Cantu was confirming that this update is binary compatible to the last version and that this was deeply tested before release. But to be honest, I would never trust such information, no matter how deeply this was tested, only because of saving a few extra clicks and re-builds of BPL's and DCU's. I usually re-build everything after every update and had no "hard-to-find", "mystical" problems and crashes ever since, at least under Windows platform.

{$IF Declared(RTLVersion111)} {$IF Declared(RTLVersion112)}

I have another approach: type TSplitter = class(Vcl.ExtCtrls.TSplitter) private FInMoveSplitter: Boolean; FSibling: TSplitter; protected procedure WndProc(var Message: TMessage); override; public procedure MoveSplitter(var aMsg: TMessage); property Sibling: TSplitter read FSibling write FSibling; end; procedure TSplitter.MoveSplitter(var aMsg: TMessage); begin FInMoveSplitter := True; try Perform(aMsg.Msg, aMsg.WParam, aMsg.LParam); finally FInMoveSplitter := False; end; end; procedure TSplitter.WndProc(var Message: TMessage); begin if (Message.Msg >= WM_MOUSEFIRST) and (Message.Msg <= WM_MOUSELAST) and not FInMoveSplitter and (Sibling <> nil) then Sibling.MoveSplitter(Message); inherited WndProc(Message); end; Linking is a two liner: Splitter2.Sibling := Splitter3; Splitter3.Sibling := Splitter2;

Simply move the logic into another procedure that you can pass the Sender into, eg: procedure TForm1.MoveOtherSplitterImpl(Sender: TSplitter; var aMsg: TMessage); begin if (fMovingControl = nil) or (fMovingControl = Sender) then case aMsg.Msg of WM_MOUSEFIRST..WM_MOUSELAST: begin fMovingControl := Sender; try if Sender = Splitter1 then Splitter2.Perform(aMsg.Msg, aMsg.WParam, aMsg.LParam) else if Sender = Splitter2 then Splitter1.Perform(aMsg.Msg, aMsg.WParam, aMsg.LParam); finally fMovingControl := nil; end; end; end; end; end; procedure TForm1.MoveOtherSplitter(var aMsg: TMessage); begin MoveOtherSplitterImpl(Splitter1, aMsg); fOriginalWindowProc(aMsg); end; procedure TForm1.MoveOtherSplitter2(var aMsg: TMessage); begin MoveOtherSplitterImpl(Splitter2, aMsg); fOriginalWindowProc2(aMsg); end; If you really want something more generic, then you should link the two Splitters together, such as by their Tag properties, eg: procedure TForm1.FormCreate(Sender: TObject); begin Splitter1.Tag := NativeInt(Splitter2); fOriginalWindowProc := Splitter1.WindowProc; Splitter1.WindowProc := MoveOtherSplitter; Splitter2.Tag := NativeInt(Splitter1); fOriginalWindowProc2 := Splitter2.WindowProc; Splitter2.WindowProc := MoveOtherSplitter2; end; procedure TForm1.MoveOtherSplitterImpl(Sender: TSplitter; var aMsg: TMessage); begin if (fMovingControl = nil) or (fMovingControl = Sender) then case aMsg.Msg of WM_MOUSEFIRST..WM_MOUSELAST: begin fMovingControl := Sender; try TSplitter(Sender.Tag).Perform(aMsg.Msg, aMsg.WParam, aMsg.LParam); finally fMovingControl := nil; end; end; end; end; end; procedure TForm1.MoveOtherSplitter(var aMsg: TMessage); begin MoveOtherSplitterImpl(Splitter1, aMsg); fOriginalWindowProc(aMsg); end; procedure TForm1.MoveOtherSplitter2(var aMsg: TMessage); begin MoveOtherSplitterImpl(Splitter2, aMsg); fOriginalWindowProc2(aMsg); end;

hahaha This is the reason i switch back to my lovely delphi 5. two things are missing for delphi 5 the first is the generic librabry which is not problem because you can has mystringlist.addobject() and problem is solved and the second is the Json support which is also no problem because you can parse it manual. Someone must tell to this programmers to install delphi 3,4,5 and see the interface. when you want to write code you do not want funcy images to display OR they sould put an option to Remove all this BS themes they add. is like OS those days they change them images and they resel something as new. One more reason to switch to Lazarus for Moblile development. Delphi Sucks any more. No Good.