David Schwartz

There are also the functions in StrUtuils like IndexText/Str and ContainsText/Str

This looks like the same stuff everybody above is saying is too error-prone and therefore should be totally avoided. Most code I write seems to be what I call "plumbing code" -- moving data back and forth between object A to object B -- and it's boring, repetative, and very mechanical. ChatGPT has done a great job writing examples of code like this for me. But like all coders, it's not 100% accurate 100% of the time. Earlier commenters in this thread assert we shouldn't be using it at all if it needs to have it's work constantly checked, and just crank the same mundane code out ourselves. I find this type of coding neither fun or creative. But thanks for pointing out an article that basically reinforces what I said earlier. It's sad that so many people expect 100% perfection before they'll even consider anything like this.

You probably don't need the class name in front. and isn't this form also acceptable: myString.IsNullOrWhiteSpace

Object-Oriented Programming involves three distinct things: Polymorphism, Inheritance, and Encapsulation. It seems you are not grounded in these yet. (Don't feel bad, none of us knew how to walk or talk when we were born, either. There's stuff in life that just needs to be learned. 🙂 ) You didn't show the declaration for the TBaseSkillPanel class, so it's unclear if you're inheriting from something else or not. I could guess it's several things, but I'll not go there. It's either declared like this: TBaseSkillPanel = class or like this: TBaseSkillPanel = class( TForm ) -- or something other than TForm The first one is a standalone class (which in Delphi's world is really implied as saying = class(TObject) ), while the second one is derived from some other class. This is what inheritance refers to -- you're extending the base class by adding more stuff to it and giving that new combined class a different name If you're inheriting from TForm or some other subclass that defines PanelResize, then it needs to have the virtual or dynamic attribute on its declaration to allow you to then say override but it's not required. In this case, the error suggests that there either is NOT a PanelResize method in the base class, or it is not tagged with a virtual or dynamic attribute, meaning the override is misplaced -- in fact, it doesn't belong there. The flip side of this would be where the base class DOES specify virtual and the derived class does NOT specify override on a method with the same name and signature. In this case, the compiler would warn you that the "method in the derived class hides the method of the same name in the base class". Sometimes you want that, in which case instead of override, you need to specify reintroduce to avoid the warning. (This is quite common when you want to use the same method name in the derived class but change its signature, usually by adding more parameters. It's most commonly encountered on constructor Create... methods.) I suspect you think that adding methods in a derived class requires you to include the override attribute. It's only needed if there's a method in the base class with the same name and signature that has virtual or dynamic specified. That's not correct thinking. Also, the use of virtual or dynamic (although dynamic is very rarely used) signifies the possibiity of polymorphism, which is an aspect of inheritance that gives you some rather magical abilities. I suggest you learn about these three topics; they'll help you understand and organize your code much better. They are fundamental to ALL aspects of object-oriented programming, which Delphi embraces quite extensively.

New technology always comes with a lot of "noise". If you're not willing to tolerate that "noise", then you can just stand by and wait while others master the underlying technology while simultaneously figuring out how to reduce the "noise level".

If you're building a web app that needs to save data in a back-end DB, I'm curious about the trade-offs between buiding your own DB using MySQL, MariaDB, SQL Server, etc., versus going with a 3rd-party solution like AirTable, DreamFactory, or something similar. (Suggestions for such services are welcome.) EDIT: I stumblled onto this and they've got a bunch of 3rd-party services that they work with. (I'm pointing it out as a source of info; I don't know anything about the vendor.) https://retool.com/integrations/ Honestly, over the past 20 years or so, I've worked on plenty of apps that rely on back-end DBs of various flavors (namely SQL Server, MySQL, Oracle, and PostgreSQL), but they've all been managed by an IT Dept. In theory, there's not much required. But it seems every one has had one or two major melt-downs per year. I like to focus on what I'm best at and leave other stuff like this to people who understand it more than I do.

Time-to-market is my primary driver right now. I can integrate a 3rd-party API in a day or two. Reinventing what they've already built is just not a luxury I can afford at the moment.

I found one that's great for saving files of various kinds: https://www.filestack.com/

Delphi has always maintained a strong commitment to backward compatibility, so pretty much ANY book you find will be useful for learning Delphi. At its core, Delphi is basically Pascal with classes added to it. So you can use pretty much any Pascal book as well, at least for the basics. Pascal was created to help teach programming, and books written for that purpose are far more informative about the language features than any book on Delphi is going to be. (It doesn't help that Pascal hasn't been used to teach programming for 20 years or so now, so basic Pascal books haven't been written in ages. And unless you want to learn Modula, you won't find anything that gets into "Pascal with classes". Dephi's "Object Pascal" is still with us today, but was never widely taught in schools.) So classes add another level of abstraction to basic Pascal. Related to this is Delphi's Run-Time Library, or RTL. But Pascal's UI never went past readln and writeln that worked on terminals of the era. Today they still work inside of a command shell window, and many people use them to demonstrate simple programs. 🙂 The real "magic" that Dephi brought us was Forms! To learn about forms, you have to dive into the Visual Control Library, or VCL, and that's a very specific set of abstractions that let you build GUI-based apps in Windows. Over time, a lot of stuff in the VCL has been moved over to the RTL and expanded upon. And in the past several releases, a ton of things have been hijacked from C# and added to Delphi's libs as "Helper Classes". You're not going to find much of anything that describes them other than just diving into the source code for the RTL and parts of the VCL. Maybe the Help files, although over the years, Dephi's "help" files haven't been particularly "helpful" for newer and more complex topics. From there, you'll get into specific types of classes that are more domain specific, and that's going to be where most books start to diverge. A lot of them will go into DB-specific stuff, and early books talk about things that are pretty much obsolete today -- eg., BDE and frameworks that pre-date the current FireDAC (FD) classes. But a book on Graphics or Games will focus more on using TCanvas and display-specific parts of the VCL as well as mouse, keyboard, and timer events. In other words, as you get into books about more specialized problem domains, they'll focus on different topics. That's where I'd draw the line between "basic" and "advanced" topics. If you're interested in Games, then a book that goes into detail on working with MS SQL Server isn't going to teach you much. A lot of us who've been working with Delphi since D1 have a large collection of books we've acquired over the years, and most of them are still useful, believe it or not. If you want to learn about creating components, there were some books written way back in the 90's that are still ideal for learning the basics, and they're hard to come by as well. A good gauge to use is perhaps the most commonly used thing in all of Delphi -- the basic TStringlist. It has been around forever. It gets a new method or two added here and there, and today it's far more useful and extensive than what it was back in the first release of Delphi. In fact, you could probably write an entire book on ONLY applications of TStringlist. For instance, one thing not many people know is that it can be used to read and write CSV files, and even let you access fields in each record. As you can see from Marco's book, as huge as it is, it could easily be TWICE the size if it included both details on things that have been around forever as well as on newer features. That's why the older books can be valueable -- they get into details on topics that nobody covers today simply to avoid making the books "too big". The topics are just as valid today as they were way back, but a book that included them would be a couple thousand pages long! Besides, you can only learn so much by reading books. I've learned far more over the years by reading code written by others than from books. Other programmers will invariably combine things in ways that you'll never see in books, because books just touch on isolated topics, while programs are more complex combinations of many different things and many levels of abstraction. Learning from books is more of a top-down process, while learning PRACTICAL topics is more of a middle-out process. If you want to challenge yourself to the limit, find something written in another OOP language you're famliar with, like C++, and try rewriting it in Delphi. That will force you to learn more nooks and crannies of the Delphi ecosystem than you'll ever get from any book!

I believe the difference here is whether you're using VCL -- which is ONLY Windows -- or FMX -- of which Windows is ONE OF MANY target platforms that can be selected. That is, with Windows, you can use EITHER VCL or FMX.

As Stano said ... there's always StrToInt( Combobox1.Text )

Since the same field value (a numerical string) is being used in both places, all this code is doing is saving you a StrToInt conversion later one, and it's not necessary. It makes me think ... who in their right mind would put a bunch of numbers into a ComboBox? I'm guessing you have oversimplified your example. But perhaps not. Assuming not, and given that the ComboBox just has a bunch of numerical strings in it, you just need to say, "Combobox1.Text.AsInteger" to get its numerical VALUE ... when you need it. Why waste memory by doing the conversion earlier and sticking it into the Obect's array? Besides, the values in Objects are NOT Pointers, they're references to TObject instances. So you should cast them to TObjects, not Pointers. That still doesn't make much sense to me. Doesn't the basic TComboBox allow Names and Values to be specified? Or is that just the Raize version? Because that's what I'd use. (If not, then I'd use name=value pairs and a custom OnShow method to only display the Name part and then extract the Value part in the OnSelect handler.)

Again, I think most of you are missing the point. In any workplace scenario, most code written by inexperienced programmers is checked by more experienced programmers. Also, just because the code passes unit tests doesn't mean it's "accepetable" code, although I'm sure there are organiations that would disagree with that. The point is ... ChatGPT seems to generate code somewhat on par with newbie programmers. There's a LOT of useful code it generates, and some that's wrong. It may not compile right off the bat, but that doesn't mean it's 100% useless. I can't speak for anybody else here, but while I know that there are lots of eyeballs on code posted to SO, most of it is short and STILL isn't something that can simply be copy-and-pasted into anything without spending time reviewing it and making it "fit in" with your existing code. That seems to be the "ideal" that everybody is holding up and saying, "Well, when it's as good at programming as I am, then I'll consider it worthwhile." I'd say, well bubba ... when it's THAT good, you and I will be out of work. There are plenty of things on SO where nobody offered up good solutions that ChatGPT can at least help with. Looking for stuff on SO is like going on a Treasure Hunt, and what you get is often no better than what you can get directly from ChatGPT. The thing is, ChatGPT is not just FASTER, but it will invariably get better over time. I've hired supposedly "experienced" devs over the years to write relatively small and highly-specific code units for me, and the quality of their code they sent me was mostly pretty low. Most, I'm assuming, couldn't even solve the problem I gave them b/c they just disappeared after a while. There's also a problem I encounter a lot on SO (among other places) where I'll ask for a solution to X and end up with a bunch of suggestions to redefine my problem to solve Y instead because they don't understand X. At least ChatGPT answers the question without trying to redefine things! And know-it-alls on SO frequently downvote QUESTIONS they don't like and argue about whether they should even be asked. In fact, I find that MOST Delphi questions submitted lately all have negative upvotes ON THE QUESTION ITSELF. This just screams out, "Don't post stupid questions here!" ChatGPT is far less judgmental in that respect, which I think is a Good Thing.

I'm sorry, but I really don't know what you're going on about. Historically speaking, Borland/Inprise/Codegear/Embt have always maintained a POV where they provide basic components and leave the door open for 3rd-parties to add fancier and more embellished components to the landscape. The thing you're pointing at really is that the Delphi landscape has been abandoned by most 3rd-party providers. Many of them just closed their doors, and many are making components for C#/.NET instead because the market is two or three orders of magnitude larger than for Delphi components. Follow the money and you'll see where the investments are being made. All of this needs to be taken against a backdrop where the entire industry has become far too fragmented, supporting too many different and incompatible platforms: Windows, MacOS, iOS, Android, Linux, and a bunch of smaller ones. VCL itself ONLY works in Windows while the entire world has shifted to a "mobile-first" development imperative, meaning iOS and/or Android. VCL doesn't get you there. So the MARKET has gone in a different direction entirely! Delphi has FMX to address this, but ... IntraWeb was introduced well over a decade ago and it's still hardly being used. I played with FMX in Windows, and I didn't like it. Everywhere I worked was 100% Windows, so I saw no need to waste my time with FMX. Microsoft creates standards mostly by buying up companies and then announcing their solution is the Next Big Thing. They do that pretty much every year or two, and as a developer who lives and breathes what Microsoft says, you'll need to keep shelling out more and more money to buy the SDK for their Next Big Thing, helping fund their ability to buy something else next year. You also have to abandon the time you've invested learning the last umpteen platforms they bought and shoved down everybody's throats, and learn yet another one that's not compatible with any of the previous ones. And don't forget that every 5-7 years they introduce a new version of Windows that deprecates older features that cause older software to break. (Apple has been doing that a lot more lately as well, and it's very expensive to keep up with all of the software they keep breaking.) From my catbird's seat, the future ahead is WEB APPS. And, sorry to say, neither VCL nor FMX will be useful on those shores. Honestly, I can pound stuff out in VCL incredibly fast. But it's really at the end of its life. There are tons of companies maintaining old Delphi apps written in D7 using VCL and fancy components like DevEx grids and whatnot. They're loathe to upgrade them at all, except on the fringes and where changes in laws require them to fix some things. Over the last decade, I can't think of anything that has been added to the Delphi language or the VCL that would add any real value to these old apps build in the D7 era. At least the newer versions of Delphi let you continue matintaining them without anything breaking, unlike most Microsoft tools that pay very little heed to backward compatibility. Give it up! Your comments make me think if the image of the guy standing in Tianamin Square in China trying to stop a brigade of tanks. While I totally agree with your general sentiments, this isn't about the VCL or Embt -- Windows Desktop apps are simply not where companies are investing in new software development efforts, and they haven't been for years. Like I said, follow the money and you'll see where the market is heading. Windows apps ain't it. Whether the future is being driven by mobile apps or web apps or AR/VR or AI or thought control ... NONE of that is reachable by VCL! The VCL is for WINDOWS DESKTOP APPS ONLY! And that is NEVER going to change. The VCL the last general store on a once vibrant Route 66 that has been bypassed by a bigger, faster freeway taking people to other places.

So basically, ChatGPT and similar tools are the computer programming equivalent of Fox Entertainment Network? It seems to work fine for Fox! It has made lots of people very rich telling lies, and the people who are lied to have no problem defending them with their lives. Sadly, there are programmers who cannot tell the difference any more than people who can't tell that pretty much everything talked about on Fox is a lie. This only seems to argue for better and more disciplined unit testing -- unless you're working at an organization that will throw out the tests (votes?) if they don't give the results they want.

I personally don't care. My experience is that most programmers tend to be fairly blunt about stuff anyway, which is how my mind works. But what you're saying points to the Achilles heel in ChatGPT which is that it's egoless, and there's really nobody to blame. So you can cuss and fume and say whatever you want, and nobody is going to care. Over the years, people have used the Bible to support just about every side of every moral issue known to man, and there have been more people slaughtered in the name of "god" over disputes springing from the various interpretations of it than perhaps anything else in history. Nobody knows the true authors, and whomever they were they lived 2000 years ago and certainly aren't around to defend how their words are abused today! What's going to keep that from happening with material generated by AI things like ChatGPT? I've worked with interns over the years, and on a good day they're marginally better than ChatGPT at writing code. For demos and samples, that's fine, but most of the code "isn't ready for prime time", as they say. That doesn't mean it's not instructive. For me, the greatest value I've seen in ChatGPT so far is that it can generate code and transform it (reliably) in ways that's beyond the ability of editors and regex expressions and would otherwise require some rather expert programming to implement. Said another way, it's good at generating what I call "plumbing" code, sort of what ETL covers. It also seems useful for getting a bunch of code that's reasonably useful for implementing an algorithm -- it may not be 100%, but it might take less time to get there than starting completely from scratch. (Of course, that's a matter of personal opinion, but it's a valid use-case.)

I'm curious if anybody has done much interfacing with a DB via a REST API, and can share their insights and "best practices" that might differ from a locally-accessible DB server. I'm building a web app and I want my back-end service to talk with a DB hosted on a remote machine. I see the back-end service scaling up at a different rate than the DB and I want to keep the two independent for a while. My only experience is with DB servers that are hosted locally, either on the same machine or on a machine in a LAN that's on the same IP subnet and behind a firewall. Initially I need to save user-specific state data, as well as some canned audio and video files that are used from time to time. The links to the media files can be sent out directly since they're not protected, but the user-specific data need to be protected. My biggest concern is how to handle versioning of the DB, although being a web app going through my back-end service, there's really only one "user" accessing this DB, which is my back-end service. So what's the best way to handle adding new fields and especially new tables once it's in production? Are there other concerns that would need to be addressed?

thanks. I'm working with TMS XData and a bit of Aurelius, and Sphinx can handle all of the auth stuff if I want to build it myself. The back-end DB is irrelevant, as Aurelius can connect to pretty much anything.

You said: I do not. I'm looking for basic principles that rise above implementation issues. I didn't find anything there that was relevant to what I'm looking for, but I appreciate that they seem to ring a bell for you.

Y'all seem to have missed the point -- this is what people are using StackOverflow for most of the time, and most of that code isn't any better than what ChatGPT produces. The biggest difference is there are a bunch of smartypants mods on SO who are constantly flagging crappy code, correcting obvious errors, and making tons of commentary about the code, the poster, and each other's comments. It's interesting how this thread looks so similar to a typical SO post.

The problem isn't the source of the information. It's how the information is being used and framed / portrayed. Anybody who has been following what's going on with the defamation suits from Dominion and Smartmatic against Fox, their management team, and their on-air lying sacks of sh*t, can see how the people running Fox are clearly targeting viewers who have such flawed critical thinking skills that they'll fall for anything the talking heads on Fox say as long as it fits a particular pattern of communication or point of view. I have a friend who's retired, and all he watches on TV is Fox. I called him to ask if he'd make me a small loan for a few days and he said "sure, but I need to get cash." I said, "Why? What's wrong with Zelle?" He said, "Haven't you heard? The IRS is coming after anybody who uses payment things like Zelle for sending more than $600 to ANYBODY! I don't want to deal with the IRS over a stupid loan like this!" I thought, "Oh, boy, I guess this is the latest crock of BS that Fox is scaring people about this week..." He's on Social Security and doesn't even file a tax return because he doesn't earn enough, and yet he's worried about getting audited by the IRS because of nonsense Fox is blathering on about this week to make Biden look bad. It's pretty hard to deal with people who can't even break down the most simple things they hear or read in the media as they may or may not apply to them! Now we've got ChatGPT that is, in all likelihood, far more accurate and less biased than Fox, and yet people are up in arms over the mistakes it seems to be making. Sure, I've found several. But Dominion and Smartmatic are very likely to get default judgments against Fox to the tune of nearly $4 billion for the mountain of evidence their lawsuit discovery processes have shown that Fox exec and talking heads have engaged in a steady practice of telling lies to their viewers in order to boost their ratings and profits. Period. And the people who make the most noise about ChatGPTs errors probably don't even realize Fox is FAR less reliable and truthful -- nor will they even accept that as a possibility. There was a book published in 1976 by Joseph Wesienbaum called "Computer Power and Human Reason". He was the founder of MIT's AI Lab. At one point in the book, he said he was asked by a reporter something like this: "What is it that humans can do that judges, psychologists, and other experts can do that computers cannot do?" His response was, "the question is what we as humans should allow or not allow computers to do that humans do." I have not found that particular quote, but here are some others I found onilne: https://www.goodreads.com/author/quotes/496834.Joseph_Weizenbaum

Ya know ... it's easy to dismiss things that it does as mistakes or just stuff it makes up, but to me they represent inferences that point to other things to look into. This is actually something I can personally relate to, as a lot of things I say get dismissed as nonsense. A lot of them turn out to be pretty damned accurate later on... I chalk this up to Asperger's. Not sure if it's a blessing or a curse. Anyway I asked ChatGPT to show the code for that non-existent TListDataSet and ... if you've got a paid account, it might generate an entire unit. With the free account, it kept quitting about half-way through the code.

honestly, not having seen or heard of this TListDataSet, I couldn't really tell what it was doing there. TDataSets have a specific interface, much of which is navigational in nature. TLists have some navigation, and the nature of CRUD operations are different. So you'd need an adapter to make them behave more like TDataSets. The one component I'm familiar with is more direct.

in what respect? I mean ... what kind of use-case are you thinking of? I asked about this because I've got a bunch of JSON data (array of records) that I'm stuffing into objects added to a TList, and it seems the only way to get something I need is to use a DB-aware control to view them. So I need to get them into a dataset so they can be viewed. Then the whole thing gets thrown away. So the choice is to go from JSON --> TDataSet or TList<T> --> TDataSet, both of which are dependent on the same issues: How much time do you want to spend writing code that speeds this up by less than a second? It's a little funny to me that all of this great technology we have at our fingertips is all rooted in stuff designed back in the 90's to support Client/Server database technology while today a large amount of our work centers around data shipped between servers as JSON packets, that's either parsed and used immediately or stuffed into classes, and is mostly transient and never intended to be put into any kind of structured DB. There are even plenty of NO-SQL DBs available today to help manage this data. Yet the most useful visual components are all driven off of TDataSets that are intended to be connected to databases. DevEx grids are incredible, but last I saw, they're totally driven off of TDataSets and are useless for JSON data and lists of objects.

HEHE ... I do know of something similar. I did ask this: Where is TListDataSet found? TListDataSet is part of the Data.DB unit in Delphi. It should be available in all recent versions of Delphi. Note that TListDataSet is not a visual component, so you won't find it in the component palette. You'll need to create it in code, like this: uses Data.DB; var MyListDataSet: TListDataSet; begin MyListDataSet := TListDataSet.Create(nil); try // Use the TListDataSet here... finally MyListDataSet.Free; end; end; Once you've created the TListDataSet, you can use it like a regular TDataSet. ----------------------------------------------------------------- It seems to know a lot about something that doesn't exist. It makes me wonder how much proprietary / restricted / unpublished data this thing was trained with.