corneliusdavid

@Dave Nottage, thanks for the clarification. It's been the rule of thumb I've used for the little bits of Apple dev I've done but I didn't consider older versions of Delphi or CE.

Always use the most recent version of XCode.

For me, I use AI with Delphi sparingly. But in two cases, it's helped quite a bit: 1) recalling seldom-used functions when I can't remember the right keyword but can describe the problem; and 2) writing unit tests. For web stuff, yes, it's great! The overall consensus, though is that it's not replacing our jobs any time soon: Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity

I've got Claude Code installed on WSL2 (Claude helped me get there--it was quite a chore) but probably won't be using it much for Delphi. I support some web sites using the Hugo static generator so plan on getting my feet wet with that.

There are no server settings to set--it's a client-only action and uses whatever MAPI-enabled email client you have installed. If Outlook, then yes, it uses Outlook. On my system, I use eM Client, so a quick sample app pulled up a new email message using that program.

That was my impression, too.

You can create a CGI application as a VCL Program that listens for web requests as if it was running under IIS--makes it very easy to debug (see attached image). Maybe this will help: https://github.com/corneliusdavid/AutoGetIt

This will help get you started on writing components.

I was going to say that this often indicates RAD Server is not yet started but you said the version page shows correctly, so your guess that it's a port configuration is a next guess. I've only used RAD Server on Windows; when I run RSConsole.exe (a windows program in the RAD Server folder, it wants to start the server on a port other than the public one, i.e. 8080 instead of 80 or 443. That's so you can isolate the console for secure management, like only within your local network. All this should be configured in the emsserver.ini file, including (as @Uwe Raabe said) the location of the database.

Try exiting Delphi, removing temp files like .dsk, .ddp, .dcu, and others, then restart Delphi and do a build-all. I've found that helps the source/debug line alignments. As for the function value return warning--I dunno!

Well, that's a different problem. I assume you've restarted Delphi?

I was re-reading your original post and I've encountered this before with a perfectly fine package that has all source. If this is the first time you've compiled/installed a custom package in this instance of Delphi, first check the Package Output Directory (in Tools > Options > Language > Delphi > Library), then make sure that path is listed in your Library Path (same options page):

Are you trying to install a Design-time package that relies on a XE2-compiled runtime package? That won't work, of course. What are are the required the packages of this Delphi project? Can you share the DPK of the package you're compiling/installing?

I've found it to be helpful as well in many situations. Just this morning, I was updating an old Delphi XE program that needed to get a list of available drives and forgot what the procedure was called. Sure, I could've looked it up but Claude reminded me of GetLogicalDriveStrings much quicker. Earlier this week, I wanted to try out Claude Code on my Windows machine. I learned it required Linux and didn't work on my currently installed WSL version 1. (The web-based) Claude helped me figure out which version of WSL I had, install WSL 2, then even though it was installed, WSL 1 was still the default so it helped me change that. Then, I had to go through a similar process with nodejs and npm. I learned several new "wsl" commands and got it up and running. It would've taken me many hours hunting down forums and blog posts to put all those pieces together--I probably would've given up. It's not great at writing whole programs or untangling a huge library of code but it can sure save time in many instances.

Perhaps this was a re-type error but that line with "{$IFNDEF GELATI" is missing the closing curly brace: {$IFNDEF GELATI} // <-- need to close with } Otherwise, it's dimming/not-dimming as I would expect. If GELATI is not defined, then code in a "{$IFNDEF GELATI}" would execute and therefore not be dimmed--because {$IFNDEF} = if the symbol is NOT DEFINED.

OK, that makes sense. You're using TPageProducers, right? So the HTML in each of those page producers could have something like this: <#HEADER> <body> <h1>Page Title</h1> <p>Content ...</p> </body> <#FOOTER> And the OnHTMLTag event of the page producer would replace the #HEADER and #FOOTER with your header and footer content. Then, instead of making a procedural call to the WebAction or making an HTTP Get call, just get the result of the TPageProducer.Content and you'll end up with the same thing.

I cannot fathom why you would want to do that. Regardless of why it's not working (your original question), calling an HTTP Get to the server from which you're running in seems like such a waste of execution time: it has to package a request string, call out to the internet, figure out the address is local, look for a server listening at that address, then send the request to the server. The server, then, has to parse the request, figure out which action will handle the request, and call the appropriate procedure which then packages a response string, sends it back to the caller which finally returns to your calling procedure. Why not just call the procedure you need directly?? You already know what is supposed to happen, which method you want to handle it and what parameters it needs. Maybe I'm missing something but the more I think about it, the more puzzled I am. That's probably for the best. That may be true--IIS may be just as confused about getting a request from itself as I am about the concept! Me too, but I don't think this one needs to be understood--just avoided!

Is your ISAPI DLL multi-threaded? Here's what I think is happening: the web server is handling an action (indexAction) and before it's finished and can return the result, you're trying to call another action on the same server by making a Get request out to the internet and back to the localhost. But since the server is still trying to get a response to the first request and if your ISAPI server is single-threaded, it can't process the second request until the first request is finished; therefore, it's probably timing out and returning blank. Instead of making another HTTP request, why not just call the desired action directly? And by "call the action directly" I making make a procedural call within your code--not an external HTTP request which goes out to the internet and back to the current server. Why would you do that, anyway? Now, you said it worked when built under D5/D7? Perhaps that was an earlier version of Indy that had a bug or there was some other setting different. Or I'm way off in my understanding of what's really going on.

No--just simple INI-file style entries. It has good documentation and comes with several examples. Here are some InnoSetup Examples I added.

Whether through VPN or direct IP to server, it's still a long internet distance for transferring large datasets resulting in serious lag.

By cheapest, I mean that they didn't want to use RDP and the only other way to get everyone to use a central program/database from various geographical locations would be to rearchitect the program as a web app. Examples would be to rip out all the local database calls and replace them with REST calls and write a new webserver app to serve up those REST calls or convert the app to a true web app, perhaps by using UniGUI. But I also said "quickest" and even though expense was a factor, the database had already been moved and we didn't have the time (months) to rewrite everything because users were losing productivity every day. So why weren't these decisions considered ahead of time? The company was sold and people suddenly brought on board. I have a full-time job and had been keeping this program in maintenance mode as a side gig for several years, so had to make adjustments quickly. Yeah, I was a little worried about price and you do have to work through the sales people but every situation is different so they listen to what you need first; and while they have a standard policy of a minimum of 50 users, they worked with us to lower that for our situation and gave us a bid which the company for which I was contracting, accepted right away. The cost is per-user, with an annual contract; I think it came out to a little under $2,000 a year for the company's small user group. With 30 users, it'll probably be at least 3 times that. They will give you a 30-day trial and even extend it if you need. They're easy to work with and are not pushy. By the way, their tech support is great. They walked through the installation and configuration with me; later, we had a couple of problems with a web certificate which they explained and got us back up quickly.

I support an old application written in Delphi XE where the client doesn't want to spend a lot to majorly upgrade but the users live in various parts of North America and used the app on their local Windows machines to access the central database. This worked OK (not great) when they were all on the west coast but when users were added from an eastern province in Canada, the additional distance made accessing data unbearably slow. So we looked for a different solution. The quickest and cheapest way was to add Thinfinity VirtualUI to the Delphi code and set up a server where the Delphi app could access the data locally and all users use the app through a web browser--with very minimal changes to the code (still Delph XE VCL!). It works great and everyone is happy.

InnoSetup

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.