Leaderboard

I always liked the concept of splines a lot, and here is now the reason why https://www.youtube.com/watch?v=jvPPXbo87ds This beautifully unveils all hidden secrets about it ( Ok, not all, hopefully more to come ).

That issue basically just says "Give me a 64-bit version because I say so - or else". I would just close it if I were Embarcadero. But I'm sure that migrating to Lazarus will ensure that you don't have to worry about memory limitations anymore. You will have a whole slew of other problems to keep you busy instead. Good luck with that.

I think a 64-bit IDE would help uncover some bugs by throwing more and earlier memory access exceptions leading to a better IDE all around. The 32bit IDE ends up with so much of the address space occupied on large projects that bad memory references are left to cause random problems at random times. Time to at least start work on a 64bit IDE.

1x TButton 5 GDI 100x TButton 5 GDI Someone should be included in this debugging.

In the new Delphi roadmap there is a research area to replace the IDE code editor maybe that will bring us closer to 64 bit IDE. In my opinion a 64 bit IDE would not solve the problems. I am from time to time working on a larger code base without a problem. A badly written pacakge can of course destroy the IDE.

It makes perfect sense to me.

In addition to Rudy's BigNumbers Library previously mentioned by DelphiUdIT, there is the high-precision float library Neslib.MultiPrecision on GitHub which is likely to give you the precision required while retaining better performance. More information here on the implementation and algorithms used.

It would really help if we could down vote issues as well as up vote them

and like, said, if you want "line" breaks, you should be able to define what kindof ( None, Space, CrLf, Lf, Cr, ...). I don't care much about the ugliness of the ''' approach, but would like to see a bit more flexibility here, to define how it shall behave. Maybe as proposal, this would limit the ugliness to an acceptable level: LStr = ''' //Default TBD A one A two A three A four '''; LStr = '''( TMultiLine.Crlf ) // Specific, maybe TMultiLine.None, TMultiLine.Space, TMultiLine.Crlf, TMultiLine.Cr, TMultiLine.lf, TMultiLine.SystemLineBreak A one A two A three A four '''; LStr = '''( TMultiLine.Custom, #0#1#2 ) // or even custom specification A one A two A three A four '''; And how about the desired behavior of leading spaces ?? Another universe. And how about the desired behavior of leading / trailing separators ?? And how about codepage conversion, oh my ?? The whole thing could be a kind of text processor IMHO, maybe like RegEx, to avoid the necessity for later re-structuring. The whole sense is to paste in a format at design time from any source format, which is immediately compiled into the final output. While at runtime you got it handed in the format and structure you intended to have, no more copy or format needed. That would be on my whishlist.

The voting system is to give priority to some issues over others. Priority may be different for all users here. It is counter productive to vote for an issue that has less priority to oneself, as that reduces the chance for issues you prioritize to be implemented.

I just voted If all users here on the forum voted, they believe it would help a lot.

So you don't format your source code with line breaks? - Because the Delphi compiler will ignore them anyway. It's not something I often do, but once in a blue moon I need to have a largish block of text in the source and that's just the way it is. Let's assume that there are reasons for this and that I know what I'm doing.

There is no impact here, but the idea is for everyone to order in "https://quality.embarcadero.com/browse/RSP-42372" like I did

No, it is not derived from CHM. Because CHM is basically Windows only and not cross-platform. Yes. plain HTML5 and based on the regular "sitemap" XML schema. When you create CHM files for a Windows application, you typically use an authoring tool for this and don't craft the HTML in Notepad. Those authoring tools which create CHM files usually create plain HTML5 as well. The example help you see in the demo project was created with Help+Manual, it's plain vanilla HTML5 and Javascript. But not just Help+Manual produces this output, Madcap Flare does, Adobe Robohelp does, you name it. And most authoring tools offer some kind of syntax to use the plain HTML5 output for context-sensitive help. Unfortunately, everyone has their own syntax, there is no established standard. And because of a missing standard, there are no viewer applications, as long as everyone does their own thing. Ziphelp is an attempt and a ready-to-use solution for this dilemma. It is as open as possible, because it is based on the standard sitemap protocol. This is the same sitemap.xml that you use on your website to help Google index it. Ziphelp is basically a legal extension of this protocol. Open for everyone to produce content that includes a Ziphelp sitemap and open for everyone to create an HTML viewer that can read it. To give it a head start, we have created a freely distributable HTML viewer that reads the Ziphelp protocol (https://www.helpandmanual.com/ewriter/). Some people prefer this solution because it's less work for them. But for Delphi developers, I think that a native cross-platform implementation is more appealing. Here, everything is under your control and your application can interactively question the help system if it actually "supports help context number 45327" or if that number is outdated in the UI of your app (and you should clean it up, but at least you don't let your end users run into an 404 error). This interactivity is missing even with CHM files. So, here you go. A free Delphi implementation that supports HTML5 in a zip archive, uncompressed HTML or web-based content. It all works with the same protocol and the same mechanism, on all platforms. You can create this HTML5 help system with our tool Help+Manual, of course. But you don't have to. If you prefer a different authoring tool, go for it.

I immediately understood the new syntax at first glance. The syntax you proposed looked like broken code. Honestly I doubt there is any possible solution to this that would not cause someone to complain, but I am glad they didn't decide to override the function call syntax for this. Personally I am glad we are finally able to move beyond the 255 character limit and have a viable option for pasting in multiline content to be used as a string literal.

If the parser is too complicated by itself, it probably doesn't matter which syntax change is actually chosen.

I for myself have never spent any time on this limitation, because I never had to (and probably never will) write that long string literals. Not only that the style guide is much stricter, it is just way less readable and thus I would never even think of doing that. In addition I would literally slap such code in the face of the developer presenting it to me. So better don't count me in here.

I have a version 10.2 license and I have problems with low memory when compiling a large application. I tested version 11.3 and the problem is the same. When will Embarcadero be ashamed and make a robust 64-Bit IDE? I'm already thinking seriously about Lazarus I already made this post Friends could also do the same thing, who knows, everyone asking for the same thing and giving could speed this up. https://quality.embarcadero.com/browse/RSP-42372