David Schwartz

This is exactly why I've chosen to go with TMS WEB Core as it runs in pretty much any web browser. It does not lock you into any particular hardware or OS version. If you need something specific, you can get a cheap machine and use it to build a REST service that the web app can call directly, or indirectly through your app's main service. There's also Crossover, which is a WINE-based containerized solution for running a Windows app in other environments that looks and runs as a native app. It's ok for one-offs, but publishers will need to see if its cost justifies the results.

There's also the problem that XCode upgrades may be required that cannot be installed without upgrading the OS. I stopped upgrading my MacOS a while back b/c it seemed like each time it would lock me out of apps that cost me a lot to update themselves to continue using -- if that was even an option. I have a 2014 Mac MIni running Mojave b/c there are several 32-bit apps that I use but can't update, and the next OS doesn't support any 32-bit apps. I have another one (2018) that's running Catalina and I won't update it either b/c of other things that break and will be expensive to update -- no free updates for these things. This is the machine I use to do my Delphi work on, inside of a VirtualBox VM, and now I can't even upgrade that to the latest version, although they seem to be supporting older versions pretty well. And with the switch to M-series chips, there's a BUNCH of apps I can no longer upgrade b/c they ALL require the latest version of the OS to run. XCode updates all seem to be tied to a specific version of the OS, and they don't maintain backward compatibility for older versions when they add new features to it. Which is why I'm mainly interested in working with TMS WEB Core to build web apps that run inside of web browsers and are not dependent on hardware or OS issues.

That looks pretty slick.

Aside from that, did you get anything from reading the post? (I don't have a compiler in my head, and I figured if I didn't show the declarations then someone would ding me on that.)

This should definitely be available in Delphi. Maybe in 5 years?

Perhaps I'm beating a dead horse here, but I'm going to go out on a limb and guess you're fairly new to the programming game, based on this statement. Please allow me to fill in some blanks for you. An "INI file" has a particular structure to it, and it's not dependent on the filename or its extension. Whomever wrote your code originally decided to use the INI file format to store the data, and also decided to use a .cfg extension on the filename. These are totally arbitrary choices. Back when INI files were first used, they did all tend to have .ini file extensions, but it's unnecessary. DOS introduced the use of "standard" file extensions and INI files were one such standard usage. Windows followed suit, as it as built on top of DOS. (CP/M probably also used INI files.) Today, most people would choose a JSON file structure for a config file format. It would NOT be named .json nor .ini, but .cfg could very well be used. Linux employs a LOT of config files, and they may be .config (NOT 'xyz.config' but just .config), xyz.conf, or even xyz.cf. Some are in a loose INI format, some are CSV, some are JSON, and many are whatever format the author decided to use. My point here is that you're thinking that a "configuration file" is always going to use some standard format -- that's simply not the case. There's no standard way to interpret a file with a .cfg extension. But most files with a .ini extension are very likely to use the INI file format. Putting JSON data in a file with a .ini extension would be deceptive. And I'd say most files that contain JSON data do not use a .json file extension; it's just not a common practice. (When DOS came along, file extensions were not used very much in other environments other than as 'hints' of sorts. But DOS used them to make it easier to know what a given file contained. So a .INI file always employed an INI file format; likewise, files with .txt, .doc, .ws, .wp, .obj, .lib, .exe, .com, and other extensions all had the same types of contents and could be opened with a specific tool. But .tmp is one that's used for any kind of temporary file, regardless of what the format of data in them might be.) Linux does not make any assumptions about what format the data in a file might be based on given its file extension. Mac is based on Unix, and does not care either. On the other hand, Windows itself does. People who write apps with Delphi ... not always. So use the file extension as a guide towards what the internal file format might be, but don't bet your life on it.

Sorry, you're quite confused here. On the TPageControl / TRzPageControl, the "pages" are TTabSheet types. They are NOT TPanel types. That's why TTabSheet.Enabled turns the tabs on and off -- it's to hide/show the TABSHEET (including its TAB). Not what's on it. You can drop a TPanel / TRzPanel on a tabsheet and then set it's Enabled property to get the desired effect without all the other rigamarole. Be sure to set the panel's Alignment to Client so it fill the entire tabsheet. Iterating over a TPageControl / TRzPageControl lets you access the Pages array property, which is an array of TTabSheet. I don't think that's what you want. From a more global perspective, there are typically two or three different forms I recommend for handling CRUD actions on DB records: one is for entering NEW record data; one is for VIEWING / EDITING an existing record's data; and a third one is to confirm DELETING a record. I won't go into detail here as to why, but after you've dealt with this a few hundred times, you'll understand why. Yes, you can only use ONE form, but the amount of logic needed to handle all three cases can get crazy. (If you just need to work with one single record, then you can do all of the CRUD stuff on one form. But when you introduce computed fields, lookup fields, child records listed on the form, and other common stuff, you will quickly find yourself going nuts trying to get everything to work on one single form for all possible cases. For me, it's easier to just make two or three distinct forms. The Delete can be a simple confirmation dialog. And record viewing / retrieval can be done with the Edit form, just make the fields read-only for viewing and enable them for editing when the user enables Edit mode.)

This is an interesting example. Off-by-one errors are extremely common, especially when you first start programming. Over time, you learn to prevent them. Considering Delphi: Given this declaration: var ary[10] : char; str[10] : string; One might be tempted to write: for var i := 0 to 10 do ary[ i ] := ''; and similarly for var i := 0 to 10 do str[ i ] := ''; The first loop would blow up when i = 10, and the second would blow up when i = 0. And the compiler would fail to flag either as a possible problem. A smarter programmer might write: for var i := Min(ary) to Max(ary) do ary[ i ] := ''; for var i := Min(str) to Max(str) do str[ i ] := ''; But the safest way is to use this syntax (when it makes sense): for var ch in ary do xyz(ch); for var ch in str do xyz(ch); There are other variations that can attract off-by-one errors (while ... do, repeat ... until, etc.) that the compiler is helpless to do anything about. What's needed is a syntactical way to totally AVOID such off-by-one errors in the first place. Well, the for ... in syntax is the safest, but it's not valid in some use cases -- like if you want to initialize the contents of the array, because it yields a value, not an index. Some languages have the ability to let you say "foreach ..." or "for ... each ...", but that's still a decade away from showing up in Delphi, if it ever will. So we're left to use far less efficient libraries to provide these common-sense solutions, or just go bare-knuckle and let the cards fall where they may. There are plenty of ways to make the language "safer" in many such respects, but if nobody is willing to actually make the compiler changes needed then it's a wasted discussion.

Sorry, but while GC might address SOME issues, it's hardly a panacea. There's a memory manager you can link into Delphi that lets you turn on things that scan for stuff and flag things that turn up, both in real-time and when the program quits. There are syntactically correct expressions that Delphi will compile without any hints or warnings that are deadly. Most of them are hangovers from old TurboPascal days that haven't been addressed, mostly because the code they allowed is not used today.

Uh, no, it's the TSA that PREVENTS you from carrying weapons onto planes! TSA is there to PROTECT PEOPLE FROM THEIR OWN STUPID IDEAS. One of them that some people make is, "the only SAFE plane is one where EVERYBODY is armed!" In the computing field, that would be like saying, "We don't need the language or compiler to protect us from bad coding practices because ... WE KNOW WHAT WE'RE DOING! Code reviews and compiler checks (both compile-time and run-time) are like the TSA of software dev teams. Yet in my experience, they're all talk and no walk -- that is to say, I may have participated in two or three code reviews in the past 20 years, only because they were mandatory for some reason or other. We had agile demos every sprint, but NOBODY ever looked at the code. (One project I worked on briefly was required by the client to do regular code reviews as part of their Agile process. But most of the time was spent listening to a lecture by someone followed by people commenting on the funky variable names and how the code itself was structured. There was no effort to look at the code's logic itself. I don't consider these "code reviews" since they never uncovered anything meaningful. Like, what if TSA never found any guns even when they were planted? That has happened at some airports, to be sure.) As I've mentioned elsewhere, at one place I worked, I found over 100 instances of bugs in the code of a large software product that stemmed from 8 erroneous coding patterns that were spread throughout the code using a copy-and-paste coding practice employed by the original programmer. I wrote up a paper documenting them and sent it to the team and my management team. Then I set up a code review meeting to discuss my findings in detail and Management cancelled it with a note saying we were too busy working on a deadline to get distracted with this "nonsense". I tried everything I could think of, and was eventually kicked to the curb because they just didn't want anybody to know about this crappy code. And these guys claimed they were totally committed to climbing this latter of ISO 900x, CMMI, and other high-level certifications to show they had it on the ball.) And, oh, BTW, these errors were all due to memory faults that were mostly "invisible" to not just the compiler, but human readers. They had been in the code for over a decade at that point, causing all sorts of weird and unpredictable errors to show up. Their extensive test suites were unable to detect them. Exactly the things we're talking about here. Where's TSA when you need them? Programmers all like to think we're smart and are capable of writing great code that "breaks the rules" SAFELY -- even those considered "unsafe". The problem isn't now, but what might happen later on down the road? How many incidents turned up when compilers switched from 16-bit code to 32-bit code, and hand optimizations using pointers broke? Ditto for 32-bit to 64-bit code. How many people have the presence of mind to add conditional compiler statements there -- WHEN THEY WROTE THE CODE -- that raise a compiler warning when something they DID think of actually breaks the code LATER? Better yet, how many things did they NOT think of? The older and more experienced you are, the more likely you are to think of more situations to be guarded against, right? But that's just one set of eyes. How many people actually DO participate in regular code reviews and DO look at stuff like this?

I think you're missing the point of this thread -- which, BTW, I did not start. This has nothing to do with me. If you like waving sharp knives and axes around when people are saying, "Hey! That's DANGEROUS!" why are you lashing out at THEM and calling THEM names? This isn't MY fight! As an aside, do you have any idea how many thousands of GUNS are taken off of people at TSA checkpoints at airports around the country? I suspect you'd call people who defend the need for TSA checkpoints ignorant and arrogant as well.

I'm pointing at something that I think might be interesting to you and you're upset at my fingers being crooked.

It wasn't. It's just a general attitude that I find quite pervasive in the programming community. Maybe because details of the trial are irrelevant to the offer itself? When you click the link for a trial DL on most sites, it usually goes to a page where all of the TRIAL details are listed, which are sometimes (but not always) different from the MAIN OFFER. If you put them on the MAIN OFFER PAGE then people will often get the two confused and a confused mind does nothing. A lot of times, the trial offer can vary by switching out the trial DL page rather than the main sales page.

Any Delphi book from D2010 and later will help you learn the language and develop basic UI skills. And they pretty much all teach the same bad habits to simplify showing how to build forms. There are also tons of videos on YT and other sites, some of which are step-by-step tutorials, as well as lots on specific topics. Don't forget the annual CodeRage virtual conferences that CodeGear and then Embarcadero have hosted over the years. There are always a few presentations for beginners as well as lots of interesting niche topics.

I imagine you prefer visiting projects on GitHub that have no documentation at all and require you to read the code to figure out exactly what they do. But, hey, they're free, so what's a few hours of your time worth, right? And of course, besides being free everything on GitHub works perfectly and they've got terrific support, saving you even more time! FWIW, I found this tool in 2010, and the author has been regularly updating it ever since. To his credit, he charges a very modest annual fee rather than saying "free updates for life", which usually means he'll be out of business within 2-3 years. I'd encourage you to 'click the link' on most WP plugins to see how few of them have been around since 2010, and how many have NOT been updated in the past year or three. Sorry, but I don't understand why so many programmers are allergic to paying for the same stuff that they themselves get paid to do without regard for how or where those funds come from -- usually from sales of the software they write. But who's counting...