David Schwartz

I think the problem we're sort of debating here is abstraction levels. The last time I looked at any code required to program a Windows Message Loop was maybe 1993 ... I might have spent one day messing with it and just wanted to throw up. Thus, I was familiar enough with it to recognize what a HUGE accomplishment it was that Delphi was able to totally hide it! That said, it took me a while to get comfortable with Modal vs. Modeless forms and the quirks they have at their edges. Over the years, I've seen so much code where the authors of certain forms were NOT really aware of the differences, which is usually when the app's Architect mandated a specific calling sequence for creating and disposing of forms that was likely an attempt to impose some (misplaced) consistency everywhere in the app. This always leads to some strange contortions in certain places in the code. I'm consistent enough in my own use that I pretty much don't worry about it. It's when I have to deal with code written by several different devs who themselves aren't consistent. I've got other beefs about how forms are managed, or mis-managed, by most Delphi devs, but that's more of a religious debate that nobody ever wins. (It's what inspired my CodeRage 9 talk.) Anyway, it seems reasonable that the normal abstraction levels that we're using to create and interact with forms should reflect a consistent implementation under the hood. I doubt 90% of Dephi programmers have ever seen what's involved in the Win Msg Loop, nor should they need to be aware of it. Except for the quirks that David points out. (Or why, although Forms are normal objects, nobody wants to create or use normal properties to move data in and out of them like every other type of object they'd do that for... but I digress.)

I don't know if it helps, but I gave a talk at CodeRage9 where I covered this topic as part of a larger discussion. Here's a link to the sample files: https://www.dropbox.com/scl/fi/l3026lqvdaqgu9pwbgwey/CodeRage9_code.zip?rlkey=iim76ulqxf7shg2zv4zx155oc&dl=0 You can view it here

I use TMS WEB Core to build web apps in Delphi. They run in the browser, and don't require any knowledge of javascript. I'm also learning how to use Latenode to build proxies to 3rd-party services that I can call from my client app so I don't need to implement them in a dedicated back-end service. It's similar to Zapier and Make, but I think more powerful and generalized.

Really, how ? procedure TMain_form.WebFormClose(Sender: TObject; var Action: TCloseAction); begin Action := caNone; end; Clearly obvious to even the most casual observer, right?

Setting ModalResult can be overridden, as well as Close, in some damned obscure ways. That's all I'm saying. But calling Close after setting ModalResult is completely unnecessary. And if setting ModalResult isn't closing the form, then tossing a call to Close in there may or may not work, or may not do what you expect. This is based on my experience. YMMV.

If it's a TreeView or a ListView, make sure you don't have an OnChange handler wired up -- or if you do, you want to put a flag in it that says: if ignore_this then Exit; And have a var at the top of the implementation section var ignore_this : Boolean; Set it to true before you start your loading up, and false when you finish. Or you could un-hook the OnChange event before you start and replace it when you're finished.

Unless you have a clear understanding of ALL the hidden things that Delphi does, you should NOT DO ANY OF THEM! "Hoping you're right" is not a reliable way of writing code. That Close call might not even be getting executed because the assignment to ModalResult calls a method that has side-effects. One of those side-effects is that the assignment is NOT made and is ignored. I've seen that happen from time to time. It's best to avoid any kind of state-altering logic inside of event handlers, because they can end up causing infinite loops, or triggering other things that you aren't aware of. What you're doing here can alter MULTIPLE states!!! As a result, the DB could be on a different record or even closed when the ShowModal gets control back. Just. Do. One. Thing. At. A. Time.

Actually, it turns out he's a contractor and I think they "parked" him on this project until his contract runs out. I've had that happen a couple of times when the client was obligated to pay the job shop the full amount of the contract and the contractor left (or was kicked-out) and I was hired to fill out the remainder of the term. It's not fun, but they're not expecting much.

It never seems like there is. What is this thing simulating?

Yes, that's what I was thinking, and why I mentioned RoboForm. Thanks. I posted this on Reddit and a guy replied saying he pasted my question into ChatGPT and tweaked the prompt a bit, and it spat out all of the code needed for a Chrome plugin -- he said he tried it and it worked fine. Although, I'm a little skeptical because he changed the description just a tad, and it's not exactly what I asked for. But it was a valid approach. (I'm thinking he tweaked it to make sure I tried it myself and didn't just blindly copy-and-paste, which I know can be rather dangerous.... or maybe ChatGPT changed it.... hmmmmm)

Please don't take this personally, but who in the hell hired you for this role? And WHY??? Like the other guy said, this is a task even highly experienced Delphi experts would be nervous taking on. I mean this in the best way possible: turn around and run away as fast as you can from this project!!! You're extremely likely to get fired long before it's finished, and they'll likely come up with some totally off-the-wall reason -- they can't exactly say it's because you're unqualified, because THEY KNEW THAT ALREADY! You may have learned something from it, but you won't be able to use them as a reference, and all you'll be able to say about it was you made some money and hopefully have all of your limbs still intact. I've got a few jobs like this in my past that I don't talk about ... hired for something I knew nothing about, thrown into the fray, didn't know what I was doing, then confronted by an upper-level manager who I'd never met who yelled at me and threatened to fire me, then did. The whole time I was wondering, "What in the heck am I doing here?" I once talked to a guy who left engineering to be a recruiter. He said he did really well at it, in a very simple way: He'd invite a bunch of mid-level managers to a free lunch and ask them if they had any projects that were behind. They'd all raise their hands and he'd ask how many of them had at least ONE they ran that they didn't think would actually finish on-time or on-budget, and they all raised their hands. Then he asked, "who's going to take the fall for that?" They all got really silent and he didn't say anything for a good minute or so. Then he said, "the CONTRACTOR!" He said he had one of the highest closing rates of anybody at the company using that approach. And I had a few jobs come to mind that seemed to fit that perfectly. And a few more over the following years, only at that point I had learned to recognize it. I don't mind being hired as a "fall guy". The annoying part is, nobody wants to tell you, even though it becomes pretty obvious before long. It's not fun. The worst part is, they usually make up some cock-and-bull story that they tell the recruiting firm that makes you persona non grata with them after that. Maybe I'm naive, but I couldn't imagine that the recruiters weren't in on the gig as well. Ask some questions about the history of the project and see if you can figure out why it has taken them so long to do this. There's definitely some politics involved; maybe the person who kept blocking it finally left, or a new manager came aboard and he wants to get this thing killed ... there's something going on there with this project. You're the wrong person for the job, so why did they hire you? (Maybe I'm totally wrong, and it turns out to be the best job of your life and everything works out great! Time will tell.)

I'm sure most of us here have spent many hours trying to solve this very problem early on in our Delphi years. There are several ways of solving this. None of them are "right" but they all work. Some seem more elegant that others, but that's always a matter of taste. Frames are nice, but they can be a PITA to work with in the IDE vs. at run-time. (Or they used to be, anyway.) Good luck with it.

I don't mean to sound mean or burst your bublle, but I think you're being set up for failure. You're also talking about a year or two of learning. What you're asking about isn't going to be found in a book. You'll learn it by working on a bunch of different systems and applications over time. If you want to learn OOP/OOD, then take a class -- learn Java or Typescript or C#. This is not the right project to learn it on. Find a project that's already up and running, with the latest (or very recent) version of Delphi, that's on Win 10 or 11, and where there are some others there who can mentor you and answer your questions. The fact that they hired someone who knows nothing about Turbo Pascal or Delphi or anything related to the application, rather than an expert with many years of experience with it, tells me they do not expect a good result in a timely manner. I've been working with Delphi since it was released and can practically write it in my sleep. But the last several jobs I've had all began by being told, "DO NOT TOUCH THE CODE! Just READ it and become familiar with the overall design." They typically expected it to take 3-6 months before they'd let somebody new touch anything, and that's in a situation where there were several experienced Delphi people on the project. Then they'd have me write up something where I had to show them exactly what lines of code I was proposing to change, in what order, and how to test that the changes worked and there were no side-effects. I was every bit as much of a "Delphi expert" as they were, and in some cases, even moreso. Still, it takes a LONG TIME to learn how a non-trivial piece of software is designed, even if you're an expert in the language. If you don't know either the language or the design environment, you're a goner. At my last job, after a month they gave me something that their IT Mgr had "analyzed" and concluded it would take a week AT MOST, to simply "migrate" this one Delphi app from WinXP to Win10. It turns out that the details the IT Mgr had given me were completely BOGUS -- he just looked at some activity going on in the file system for 30 minutes and made up some crap about what he thought was going on. He thought he was watching files being processed and inadvertently deleted. What he was actually watching was a bunch of temp files being created and deleted by a DLL. When he tried it in Win10 and watched it run, it did not behave the same way. Well, DUH! The problem was the DLL was V1.0, released initialy when WinXP was released, it did not run correctly on Win10. To add insult to injury, their license prohibited us from using it the way we were -- which the IT MANAGER should have figured out already, but didn't. That's all I managed to learn in the first week. And some VP had the gall to ask "Did you get it migrated yet? Yes or no?" I wanted to say, "What part of 'the DLL won't run on Windows 10' don't you understand?" Basically, the findings I reported made a bunch of people look like fools, and they weren't happy. But all of this "analysis" was done before I was even hired, and nobody bothered to explain any of it to me first. My point is, you're very likely on a fool's errand here. Your employer could hire experts like me or many of us here and we'd come in, and after studying that app for a week or two basically say, "it's impossible to do what you're asking". YOU don't even know what you don't know -- and THEY KNOW THAT! It might be 6 months of struggling to learn Delphi and all that stuff before you finally come to the same conclusion. You're being set up. My experience migrating old apps like this into the current version of Delphi and Windows is ... it might work ... but more than likely it's going to take some signficant rework and testing to find any parts that depend on obsolete Windows APIs, DLLs, and other libs that may be obsolete and cannot be replaced easily. Meaning that while your desire to learn Delphi and OOP and all that stuff might seem applicable, that's not what's going to keep that app from being easily migrated. Yes, it might compile. Most likely, it won't. And if you don't understand how components and libraries work, or if there are any DLLs or Windows APIs that won't work, you've got a LOT more work ahead of you that's got little if anything to do with Delphi programming. That DLL I mentioned that we couldn't use ... the company refused to sell us the latest version, claiming (rightly so) that their license did not support our use-case. They wanted to sell us access to their own online REST service that they estimated would cost $10k-$15k PER MONTH!! Management looked like someone just stuck a pipe up their butts when they heard that! "Oh, it's just a simple migration" they were told. "It's just a few days of work" they were told. "It won't take much effort at all" they were told. I had to find a replacement for that DLL and ended up finding a library written in Delphi, and it cost under $100. Then my boss had to deal with HIS boss arguing about "spending so much on such a basic library" for a week... I hope you can see that NOTHING I've mentioned here has ANYTHING to do with DELPHI, OOP, or any of the stuff you're asking about. It's just that you don't know that, and your bosses think that's the problem that needs to be solved, just like my managers did before they hired me to work there and assigned ME to do that simple little "migration" from WinXP to Win10. Honestly, I wouldn't touch that project with a 10-foot pole. Been there, done that, and there's no nice outcome. Everybody is going to be looking to shift the blame, and it's all going to land in YOUR LAP. If you're a contractor, I'd bail out of there fast. Somebody well above your pay grade f*cked up and they're looking for someone to blame it on.

I’m looking for a tool that lets you hook into a browser window while a web app is running and access the DOM, allowing some AI prompts (eg., ChatGPT) that I've written to execute, maybe via a popup menu. What I need is the ability to simulate an EXPORT and IMPORT process in a web app that doesn't offer it, taking the data from the fields in the current window and letting you save it as, say, a JSON file; as well as letting you open such a JSON file (eg, with edited values) and use the data in it to fill the fields where the data is intended to go. I use RoboForm regularly, which has a way of doing this, but it's mainly for managing login forms like LastPass, 1Password, etc., so it's clearly possible to create such a bridge using a browser plugin. It lets you save and fill forms, but the data is saved to its own internal storage; I need it sent to a JSON file that I can save to disk or pass on to some other app somehow in terms of the EXPORT process. Importing would require opening the JSON file on disk or maybe have it pasted from the clipboard. I don't really care what browser, but Chromium is the most prevelant. Just wondering if anybody here knows of something that might do this. Maybe a debugging tool, or a type of "screen scraping" tool, or just something like RoboForm that does exactly what I want.

Before there was a GUI app like Delphi or VB, there was TurboVision (IIRC) and it was a C++ framework that let you write code that generated a GUI. And around that time there was the Windows SDK that required you to use two different languages to write a GUI-based app for Windows, and neither of them had a GUI. It sucked. It could be argued that both of these approaches embraced console apps that ran GUIs. In fact, before Windows, there were C libraries that let you build GUI apps entirely in code. I used a popular library called Vitamin C. Delphi is sort of a misnomer. It's really two things: an extended version of the Pascal language called Object Pascal; and a GUI-based development environment built with a very innovative (at the time) event-driven library that implemented a bunch of visual controls, called the Visual Control Library, or VCL. Delphi was supposed to be TurboPascal 8 IIRC, but it was released under its code name of "Delphi". Internally, it still uses product numbering relative to the original release of TurboPascal. And you can still compile old versions of TP code with it. So technically speaking, if you don't USE any of the VCL library units, it's just using stdin, stdout, and stderr for I/O, making the resulting app operate as a simple command-line tool. That would be like buying a nice new car and removing the entire shell so it's just the floorboards, A-frame, drive train, engine, and maybe a stool to sit on while using a vise-grip on the steering wheel shaft to turn. It's certainly possible. Do you know of any driving schools that teach that approach to driving? Driving schools could start out teaching everybody how to drive a stick-shift as well, but ... when was the last time you saw a new car with a stick-shift in a dealership? People who learn to drive them usually start off with a pickup or sports car from the 60's or 70's.