Farshad Mohajeri

There is no easy receipt for this that I can share here. More components and features will be added as framework advances.

TUniDateTimePicker and TUniDBEdit are already implemented. We do not have a Currency editor yet.

Note: Enabling compression will highly improve load time over DSL lines.

I will log an issue for this. I will add an option to TUniFont so font will always be sent event when it is default font. Logged #1103

Thanks for feedback.

Here is the default CSS for grid rows: .x-grid3-hd-row td, .x-grid3-row td, .x-grid3-summary-row td { font:normal 11px arial, tahoma, helvetica, sans-serif; } In my browser Tahoma is used by default.

Which CSS class did you change ?

Sorry, but I couldn't find where I should look in above images.

State data are not limited to visual controls only. All user variables, Forms, data modules, DataSets, data connections, other non-visual components and etc. all together build a very complex state for current session which can only be kept inside memory. While more memory usage is a disadvantage here, there is a big advantage here in favor of stateful apps. uniGUI apps consume much less CPU and bandwidth usage compared to a stateless application. In a stateless application state info should travel back and forth between server and client. Each time a request is received session should be built using these state info which highly increases CPU and bandwidth usage. In a UniGUI app each Ajax calls send as few data packets as possible. There is no repeated traffic or state data inside an Ajax request packet. I've seen ASP.NET applications with view state streams in magnitude of tens of KB which travels back and forth each time user sends a new request.

Tahoma is the default Font and in order to optimize traffic default values aren't sent to the browser.

Ext JS doesn't have built-in support for RTL but I think there are some extensions for it.

... but not published in DBEdit. It will be published in next build.

It is already there: TUniEdit.Alignmnet

uniGUITypes.pas

You can't change screen cursor but you can change cursor of individual controls.

Scalability is an important aspect of a web server which must be taken seriously. I'll try to explain in detail. An atomic uniGUI app containing a single MainForm only consumes a few KB of memory per session. As developer adds new components to Form and datamodules per-session memory usage starts to increase. uniGUI apps are fully stateful. Each session stays in server memory space as long as that session is active. Once that session is terminated the memory is returned to server memory pool. Each component such as a Button has a shadow in server which stores all the properties and "state" information. Stateful apps are easier to develop, as developers shouldn't take care of handling state info. The price paid here is more memory usage which increases in parallel with number of sessions. Developers must take care of per session memory usage if number of sessions will be more than 100 sessions. If each session consumes one megabyte then 1000 sessions will sum up more than one gigabyte which is not good for a 32-bit server. If Embarcadero delivers a 64-bit Delphi soon then we can hope that the memory barrier will no longer be an issue here. A 64-bit server can use all available server memory so number of sessions may not be no longer an issue. On the contrary stateless apps do not have in memory sessions and server doesn't store a single bit of in-memory state information of any sort. If there are any state information they must be handled by the app itself. There are several techniques to save state information in a stateless environment such as ASP.net and PHP. View state, cookies, db tables, text files and etc are off-server methods used to keep state information. uniGUI apps don't need any of these techniques to save state because current state is already there in server memory. This makes developing uniGUI apps much easier because you can develop apps in classical RAD way without a need to develop extra techniques to keep track of state, but again as stated in above there is a price to pay for this: more memory usage. Memory usage is not the only problem here. Another problem that we may face is OS handles. Here I'm talking about GDI handles which are a limited resource in Windows OS family. uniGUI is designed to have a minimal use of GDI handles where possible but some components can't function without GDI handles. For example a TBitmap uses GDI handles to keep, convert and modify bitmaps. If each session uses lots of GDI handles there is a chance that your app may run out of handles when there are say 1.000 active sessions. This may even happen much sooner than you run out of memory. UniGUI core components will be designed to use as less as handles as possible. We will implement our own TUniImageList instead of default TImageList because TImageList can use lots of handles. However, we can't control handle usage of 3rd party components and other user components. For example almost all Delphi reporting tools claim to be multi-thread ready, but a closer look shows that it is not correct. Many of such tools use some dirty hacks to solve multi-threading issues. A deeper look reveals that such tools extensively use GDI handles to render report pages. This means that they can easily overrun OS handles if there are 100 simultaneous reports being prepared. The only solution for this is to use a report server which runs in a separate process and communicate with uniUGI apps using various inter-process communication methods. Load balancing is another issue. uniGUI apps can be load balanced. To achieve this a specialized load-balancer application is needed. Load balance app will recognize uniGUI web requests and after extracting the session info, request will be redirected to server which is keeping the state for that session. Each request should be redirected to the server which has initiated that particular session. Requests can not wander around different servers as it is possible in a stateless server farm. All these may make load-balancing a bit more complex, but it is achievable. As you can see there is a big difference between developing a uniGUI server which will serve 100 sessions and a uniGUI which will serve thousands of simultaneous sessions. In first case you will simply develop and deploy the app, but for 2nd case you should carefully design the server keeping all above issues in mind.

Yes that's another possibility too.

The required bandwidth can be as low as 256 kb/s. Actually there is no lower limit for it. The lower the bandwidth the longer initial load will take. CPU usage can't raise to 100% just by clicking cells. Can you reproduce it with shipped demos?

Hi, This feature will be implemented in UniURLButton component.

Then there must be specific settings in DevArt which I'm not aware of!

Have you set "ServerModule->AutoCoInitialize->True"?

You may try setting ServerModule->AutoCoInitialize->True

I need more details. Type of Database used. Error codes.

Because string staring by "/" is automatically converted to a valid URL by browser. Browser automatically adds the base url to /mypdf.pdf

You can use: UniSession.Host