Alex7691

On 11/9/2023 at 9:25 AM, Stefan Glienke said:

It better be - I spent quite some time on it. FWIW it was already introduced in 11.3

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,

On 12/23/2023 at 9:04 PM, David Heffernan said:

Ha ha ha. I think we all know the answer to this. 

 

They can't even do menus properly. Even for the standard  windows theme the menus are custom drawn and the Emba code gets it wrong in various mixed dpi scenarios. 

 

When I switched to Delphi 11.3 I'd hoped to avoid having to patch the VCL to suppress its custom drawn menus. Alas that hope was doomed. 

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.

On 12/23/2023 at 9:51 AM, Darian Miller said:

So what happens when you drag your window from a non-High DPI monitor to a High DPI monitor and vice-versa?   Do you get a lag and a bunch of flicker?

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.

On 3/19/2023 at 1:24 AM, David Schwartz said:

 IntraWeb was introduced well over a decade ago and it's still hardly being used

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).

Quote

In the IntraWeb forum, they just want to hide a problem they overlooked with IntraWeb and they want you to use their product.

Given that the application behavior is not only expected but also correct, your statement above is obviously false.

Regards

Quote

ICS has his own AllocateHWnd method that is thread safe. It make use of a critical section to protect the class registration (GetClassInfo and RegisterClass) and then use CreateWindowEx to create the handle. For those interested, look at TIcsWndHandler.AllocateHWnd in unit OverbyteIcsWndControl.

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?

Quote

In the IntraWeb forum, they just want to hide a problem they overlooked with IntraWeb and they want you to use their product.

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

8 hours ago, Lars Fosdal said:

At what point is the instance pointer reference for the string, interface or dyn.array changed? 

 

When are field values in instances not aligned (unless overrides have been added)?

 

https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/lock-statement

Quote

Avoid using the same lock object instance for different shared resources, as it might result in deadlock or lock contention.

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.