corneliusdavid

Right. I mentioned that as the only other way that properties could be set before FormCreate was called. To do that of course, he'd have to set a published label or editbox (or some component) at design-time.

I wouldn't say there's anything specifically for 12.3 but check out the extended utils that allow you to modify styles at run-time and also the non-client area enhancements. I haven't seen anything like that the "What's New" sections of recent releases of Delphi.

Very strange. Not sure how that's ever worked--unless you were overriding the constructor or calling BeforeConstruction or AfterConstruction. The values from the DFM are streamed in and set after it's created and before FormCreate is called so that's the only other way values can be set before the event handler is fired but according to the code you showed, that's not how sQuery is being set.

I'm going to correct myself before someone else does: I was thinking that maybe sQuery was being passed in or somehow set before it was created but since it's a private variable of the form being created, it couldn't possible be set before it was created. DUH!

Right there: You are creating the form (which calls FormCreate) right before you set sQuery; therefore, sQuery is blank in FormCreate! Are you sure this was working exactly this way in previous versions of Delphi? Yeah, I was wondering about that.

Is the sub-form auto-created when the application starts? If so, Create is likely being called before you have a chance to set sQuery.

AI is pretty advanced but relies on a large code base from which to learn. Doesn't most COBOL code reside only on ancient government data centers that were developed before the internet--or at least before code was put on any internet-connected devices? Perhaps having AI rewrite it in JavaScript would help shorten the conversion time even further? Of course, it would lengthen the debugging time exponentially...

After much contemplation (and asking Claude AI for advice), I'm proposing a new programming language with roots in Delphi (thus the name) but with some interesting and revolutionary ideas that will take into account concepts never before attempted in software development. Some of these ideas include syntax checking that changes based on the time of day, optimization that improves when builds are automated, and crypto-mining to lessen the cost of the IDE. Some will argue that that reporting compilation errors to social media could hurt the reputation of some programmers but I think it will incentivize them to become better (or at least more careful) programmers. What do you think? Read the full article here.

You'd have to create an issue on the Github repository and wait for someone to fix it--or better yet, clone it, fix it yourself, and create pull request!

Thank you, @havrlisan, for the plug for my book. I wrote that specifically for the Delphi programmer who already has VCL experience and wants to leverage their knowledge to expand to other platforms. I also have Andrea Magni's book and it's an excellent deep-dive into understanding and working with Firemonkey. Be aware that Linux development with Delphi requires at least the Enterprise version and does not officially support Firemonkey (yet).

I sent Tim an email about month ago. It took him a week but he did reply. I imagine the reply would've been quicker if I was a current customer.

I've done that in the past as well. In fact, there's a component in my Github library, CloseApplication, to do that. I don't know the habits or the code on this current project well enough to confidently apply that yet. For example, if I set a 3-hour timeout but someone is still in the office at 7:00 PM and I'm wanting to update at 9:00 PM, then the app could still be open. I like the idea of being able to "Remotely stop applications with user notifications." Now, my only problem is that this old project I've inherited is still in Delphi 7--this App Watcher component is in D12 so I probably can't use it yet.

Yes, and I've done that as well in some situations but I want the users to run the updated version the next day when they come into the office; if they left it running, they'll still be using the old version still in memory. Of course, I could add something that checks every minute or so and prompts to restart the app or something. Or use this--thanks for the link. So many choices!

This looks like a great solution to add to a project I inherited where the users are accustomed to running the app from a network server. I have access to the server to manage the database and update the app but sometimes they leave it running at the end of the day which locks the app from being updated.

That's what I was tempted to do as well and got part 1 done relatively quickly using that method. BUT BEWARE! It's a trap! As soon as you gleefully submit the correct answer and see what you have to do for part 2, your heart sinks because ... Instead, you have to analyze the problem, learn the patterns, then then craft something much more intelligent--in other words, more time than I had.