Alex7691

I ran some benchmark applications this week and I found out that the servers built with Delphi 12 are 13-16% faster than the same built with Delphi 10.4. I can't currently pinpoint the exact source of the performance gain but I guess that Move() and others are playing an important part on it. Anyway, very well done! Cheers,

Seems that you are referring to the TMainMenu control. We don't use it in our application. We used the TActionMainMenuBar which renders the menu. Not sure how much code they share and if the same problem affects both, but IIRC, the menu rendered correctly on high DPI monitors and in mixed setups. One thing that's really messed up in TActionMainMenuBar is the customization at runtime via TCustomizeDlg, and it happens all the time regardless of your monitor DPI. I've reported the issue to EMB but no fix so far: https://quality.embarcadero.com/browse/RSP-31714 Other than that we haven't found any major issues so far.

We tested the application in a mixed monitor setup and it behaved in an acceptably manner (built with 10.3.3). I'm not saying that it is perfect. I'm saying that we couldn't find any showstopper issue. But I also found issues with several other applications in the same scenario, including WPF ones. I think MS didn't get it perfect either. As I said, the application has thousands of users around the world and the general feedback has been good. Nobody ever said that "it doesn't look prefessional" because of some minor issue like this.

That's an old post but since I don't come here often, here it goes: David, you are wrong. IntraWeb is not one decade old. IntraWeb was introduced in 1994, as a product, before Delphi 1.0. In the Delphi world it is as "old" as Delphi itself. And IntraWeb's doing fine, for 30 years, thank you. I dare you to name another product/framework that started before IntraWeb and is still around. And, no, DevExpress and TMS were both founded *after* Atozed and IntraWeb. The same argument that you use against IntraWeb is the one that a Python developer uses against your application that you wrote in Delphi: "Hey, nobody uses Delphi anymore!". The Python developer will never get it, simply because he doesn't know it. Cheers

For future readers: IntraWeb support forum is here: https://www.atozed.com/forums/forum-3.html Cheers

@Rollo62 We recently installed Delphi 12 and we are in the process to get the application building with, it which will require some work. We haven't played with Skia4Delphi yet.

This is an rather old thread but I'd like to give my 2c for future readers: I was lead of a team modernizing a huge (300+ forms, 3+ MLOC) Delphi application. The major part of the modernization process was about styling it, using VCL Styles. We used Delphi 10.3 at that time, and then eventually we migrated to Delphi 10.4. It took 3 months and we decided to purchase a 3rd party library (StyleControls) to make the process easier and faster. StyleControls has simliar controls (e.g. buttons) that work better with styles than the standard ones. Besides that, SyleControls have some classes to help styling controls that don't support VCL Styles directly (e.g. the DevExpress grid that we extensively use in our application). Disclosure: I'm not connected to StyleControls company in any way. Regarding VCL code, some hacking was necessary to fix bugs that couldn't be avoided and no workaround was found (mostly runtime patching of VCL classes). We also used the Rodrigo Ruz's VCL Style Utils package, and it also required some tweaking (nothing major though). Repainting of complex forms when resizing can also be problematic. A non-styled VCL form with hundreds of controls will repaint itself very fast and there is very little flicker. The same form when styled will cause a severe and ugly flicker that can't be ignored and we also needed to find ways to reduce or interrupt form refreshing in many scenarios in order to reduce this effect. But basically I disagree with who says that it doesn't look professional, or "not quite there yet". The final result looks nice and professional, although there are things that could be improved and refined. The application has been in production, with thousands of users and the general feedback has always been positive. I think it's totaly worth it.

This is an old thread that was pointed out to me by an IntraWeb user. I'm adding some information for future readers. IntraWeb has it's own ISAPI classes and doesn't rely at all on Delphi's IsapiHTTP.pas (or any other Delphi Web.* namespace unit). Any bug in that area doesn't affect IntraWeb applications. Cheers,

I've just tested his test application (without ICS, but the same issue will definitely happen). There is nothing wrong with IntraWeb. He's using an Indy-based IntraWeb server. He creates a window handle when his application is receiving an incoming request. The Indy HTTP server spawns a worker thread which is freed afterward. The window handle is released when the thread is destroyed. Then he tries to use the same window handle in a subsequent request, from another thread (there is no guarantee that the original thread which created the window handle hasn't been destroyed). This is documented here: https://docs.microsoft.com/en-us/windows/win32/procthread/terminating-a-thread BTW: his example works when using Http.sys-based IntraWeb application (not Indy) because the threads are obtained from a thread pool and recycled, so the windows created in one request will be still valid in a subsequent request (although I don't recommend his way of using it at all). Given that the application behavior is not only expected but also correct, your statement above is obviously false. Regards

I did not mention ICS at all. I'm pointing at his test case application which does not use ICS. This is a standard AllocateHWnd RTL call and it won't work reliably. That's a fact. Once you mention that you patch AllocateHWnd from ICS code, are you 100% sure that your patch doesn't break anything else that IntraWeb relies on? After saying yourself that you know nothing about IntraWeb, this kind of statement is at least curious. Regards

For future readers: AllocateHWnd is not thread safe and should never be used like that in any multi-threaded application (not only IntraWeb servers). I'll have a look at his example out of curiosity, but this code the way it is now is not recommended, not supported and definitely won't work reliably.

Hi Arthur, Indeed, IntraWeb DCUs are built with debug info ON. Mainly because the built-in exception logger (Based on Jedi's JCLDebug code) requires the debug information to create an human readable call stack). Also, not sure how many IW developers add the source code to their build (or add them to the browsing path), but I believe it is a considerable number. The ideal is to have 2 sets of DCUs but it would just explode the size of the setup. We are trying different approaches with the build script and setup program. I will have more information about it soon. Unfortunately, Delphi doesn't have any option to filter out some units or paths from debugger. Personally I have other 3rd party libraries for other projects and it is painful to debug certain applications because of this. Cheers,

Would you mind elaborating why you need it? In general it is not possible to effectively minify HTML content unless it contains heaps of comments. In that case, simple gzip compression for http(s) transmission is as effective as (if not more, i.e. the cost to compress it using gzip is less compared to the cost of minifying it + compressing it and the benefit is almost the same) Cheers

Contention yes, deadlock, no. Actually it is quite the contrary. Deadlocks only occur because more than one lock is used (or one which can't be called recursively, like Windows' SRWLock objects). This document is *really* wrong.