03-29-2018, 07:54 PM
I have seen your previous posts about "code modal" over the years with a hope that something new was available.
I will point out that UniGui does have a built in ShowModal on any "TUniForm". I have no technical information how it works, aside from the fact that it does allocate a thread for each modal form until the modal form is "completed". From the developers point of view it works just like the VCL (code modal as you say).
In anticipation of the feedback to this, I will say I totally understand and agree that "burning" threads waiting for the modal response to return is not "scalable". HOWEVER, a quick google search indicates that Widows server allows at least 10,000 threads per process. In my application, there will be 100 concurrent users max. Even if I am wrong by a factor of 10, and there are 1000 users concurrently one day, they would all have to be waiting on many modal dialogs each at the same time to worry about a thread limit on a single server. Of course, in that case I would simply load balance and alleviate the issue.
There is no way that we will ever get close burning out the # of threads. I understand if I was writing GMail in intraweb, with expectation of 10,000,000 concurrent users it would be stupid to do this. But for my app, the convenience of having "code modal" far outweights the performance issues.
You always have to design your system for your intended use. If my app did have 10000x the users that it does now, I would have to design it totally differently, and the modal threads would be the least of my issues.
While I understand the purist approach of it not being a good idea because it won't scale to a huge volume, the pragmatic approach of having the convenience of a proper "code modal" would be very helpful under a wide variety of circumstances and applications.
I will point out that UniGui does have a built in ShowModal on any "TUniForm". I have no technical information how it works, aside from the fact that it does allocate a thread for each modal form until the modal form is "completed". From the developers point of view it works just like the VCL (code modal as you say).
In anticipation of the feedback to this, I will say I totally understand and agree that "burning" threads waiting for the modal response to return is not "scalable". HOWEVER, a quick google search indicates that Widows server allows at least 10,000 threads per process. In my application, there will be 100 concurrent users max. Even if I am wrong by a factor of 10, and there are 1000 users concurrently one day, they would all have to be waiting on many modal dialogs each at the same time to worry about a thread limit on a single server. Of course, in that case I would simply load balance and alleviate the issue.
There is no way that we will ever get close burning out the # of threads. I understand if I was writing GMail in intraweb, with expectation of 10,000,000 concurrent users it would be stupid to do this. But for my app, the convenience of having "code modal" far outweights the performance issues.
You always have to design your system for your intended use. If my app did have 10000x the users that it does now, I would have to design it totally differently, and the modal threads would be the least of my issues.
While I understand the purist approach of it not being a good idea because it won't scale to a huge volume, the pragmatic approach of having the convenience of a proper "code modal" would be very helpful under a wide variety of circumstances and applications.